112 votes

Configuration correcte d'un serveur nginx "par défaut" pour https

J'ai plusieurs serveurs fonctionnant sur la même machine, certains avec http uniquement, d'autres avec http et https. Plusieurs blocs de serveurs sont définis dans des fichiers séparés qui sont inclus dans le fichier de configuration principal.

J'ai mis en place un serveur "par défaut" pour http qui servira une "page de maintenance" générique aux requêtes qui ne correspondent à aucun des autres noms de serveur dans les autres fichiers de configuration. Le serveur http par défaut fonctionne comme prévu, il utilise le nom de serveur "_" et apparaît en premier dans la liste des inclusions (car j'ai observé qu'en cas de doublons de noms de serveur entre serveurs, celui qui apparaît en premier est utilisé). Cela fonctionne parfaitement.

Je m'attendrais à un blocage identique du serveur (en remplaçant simplement "listen 80 default_server" par "listen 443 default_server" et aussi au lieu de servir la page "return 444") mais ce n'est pas le cas. Au lieu de cela, il semble que le nouveau serveur https par défaut récupère toutes les connexions https entrantes et les fait échouer, bien que les autres blocs de serveurs aient des noms de serveurs plus appropriés pour les requêtes entrantes. En supprimant le nouveau serveur https par défaut, le comportement semi-correct sera rétabli : les sites web avec https se chargeront tous correctement ; mais les sites web sans https seront tous dirigés vers le premier serveur https dans les fichiers include (qui, selon la documentation, si aucun "default_server" n'apparaît, alors le premier bloc serveur à apparaître sera "default").

Ma question est donc la suivante : quelle est la manière correcte de définir un "serveur par défaut" dans nginx pour les connexions ssl ? Comment se fait-il que lorsque je définis explicitement un "serveur par défaut", il devient gourmand et s'empare de toutes les connexions alors que lorsque je laisse implicitement nginx décider du "serveur par défaut", il fonctionne comme je m'y attendais (avec le serveur incorrect défini comme serveur par défaut et les autres serveurs réels se comportant correctement) ?

Voici mes "serveurs par défaut". Http fonctionne sans casser les autres serveurs. Https casse les autres serveurs et consomme tout.

server {
    listen 443 ssl default_server;
    server_name _;

    access_log /var/log/nginx/maintenance.access.log;
    error_log /var/log/nginx/maintenance.error.log error;

    return 444;
}

server {
    listen *:80 default_server;
    server_name _;
    charset utf-8;

    access_log /var/log/nginx/maintenance.access.log;
    error_log /var/log/nginx/maintenance.error.log error;

    root /home/path/to/templates;

    location / {
        return 503;
    }

    error_page 503 @maintenance;

    location @maintenance {
        rewrite ^(.*)$ /maintenance.html break;
    }
}

L'un d'entre vous voit-il ce qui pourrait clocher ici ?

5voto

Leonard Lee Points 1

À tous ceux qui ont perdu autant de cheveux que moi à cause de cela (j'ai passé presque toute la journée sur ce sujet aujourd'hui). J'ai presque tout essayé, et la chose qui a fait que ça a finalement fonctionné correctement était cette ligne stupide :

ssl_session_tickets off;

S'appuyer sur Si ce n'est pas le cas, Dans la réponse de l'auteur, mon exemple de travail est le suivant :

server {
    listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;
    server_name _;

    ssl_certificate /etc/nginx/ssl/nginx.crt;
    ssl_certificate_key /etc/nginx/ssl/nginx.key;
    ssl_session_tickets off;

    return 404;
}

Je n'ai aucune idée de la raison pour laquelle cela était nécessaire, le seul principe que j'en ai tiré est que nginx se comporte très bizarrement quand on ne lui donne pas ce qu'il veut.

1 votes

Vous êtes une légende.

0 votes

La valeur par défaut est de 5min, je suppose qu'un peu de patience aurait fait l'affaire aussi :-)

2voto

Michael Hampton Points 232226

Si vous voulez être absolument sûr, utilisez des adresses IP distinctes pour les hôtes qui ne doivent pas répondre sur HTTPS et ceux qui doivent le faire. Cela résout également le problème de l'avertissement du navigateur "certificat invalide".

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X