Comment installer un certificat SSL sur NGINX

Ce guide vous montre comment installer un certificat SSL/TLS sur NGINX. Il couvre la partie qui pose le plus de difficultés : construire la chaîne de certificats correcte (« fullchain ») requise par NGINX, faire pointer les bonnes directives vers les bons fichiers, tester la configuration avant de la recharger, et ajouter une redirection propre de HTTP vers HTTPS afin que chaque visiteur arrive sur la version sécurisée de votre site.

Générer un code CSR pour NGINX

Si vous avez déjà généré votre CSR et que vous disposez des fichiers du certificat émis, passez directement à Installer un certificat SSL sur NGINX.

Avant qu’une autorité de certification puisse émettre votre certificat, vous devez soumettre un CSR (Certificate Signing Request) : un petit bloc de texte contenant les informations de votre domaine et une clé publique, associé à une clé privée conservée sur le serveur. Vous avez deux options :

• Générer le CSR automatiquement avec notre Générateur de CSR. L’outil renvoie à la fois le CSR et la clé privée correspondante, que vous téléversez ensuite sur le serveur.
• Générer le CSR directement sur le serveur avec OpenSSL en suivant notre tutoriel sur comment générer un CSR sur NGINX. La clé privée reste sur le serveur.

Ouvrez le fichier .csr obtenu dans un éditeur de texte ; le bloc de texte qu’il contient (y compris les lignes —–BEGIN CERTIFICATE REQUEST—– et —–END CERTIFICATE REQUEST—–) est ce que vous devez coller dans le formulaire de demande SSL lors du paiement. Si vous souhaitez vérifier le contenu du CSR avant de le soumettre, collez-le dans notre décodeur de CSR.

Installer un certificat SSL sur NGINX

Une fois que l’autorité de certification a émis le certificat, vous recevrez généralement :

• Votre certificat principal (serveur), généralement un fichier .crt nommé d’après votre domaine.
• Les certificats intermédiaires (et parfois racine), soit sous forme de fichiers .crt distincts, soit regroupés dans un seul fichier .ca-bundle.
• La clé privée (un fichier .key) qui a été générée en même temps que votre CSR.

NGINX a besoin que le certificat du serveur et la chaîne intermédiaire soient combinés en un seul fichier (le « fullchain »), désigné par ssl_certificate ; la clé privée est indiquée séparément par ssl_certificate_key. Omettre la chaîne est l’erreur d’installation la plus courante : le certificat semble correct dans un navigateur de bureau mais échoue sur Android, dans les clients API, et sur des outils comme notre SSL Checker.

Étape 1 : Combiner les certificats en un seul fichier

L’ordre des certificats dans le fichier combiné est important. Votre certificat de serveur vient en premier, puis chaque intermédiaire de l’autorité émettrice jusqu’à la racine, la racine étant placée en dernier (ou omise, car les navigateurs font déjà confiance aux racines de leur propre magasin intégré) :

• Votre certificat principal pour le nom de domaine.
• Certificat(s) intermédiaire(s).
• Certificat racine (facultatif).

Vous pouvez créer le fichier fullchain manuellement dans un éditeur de texte (en collant chaque bloc PEM dans l’ordre), ou avec une seule commande cat. Si vous avez reçu des fichiers intermédiaires et racine séparés, exécutez :

cat your_domain.crt intermediate.crt root.crt > ssl-bundle.crt

Si les intermédiaires et la racine sont déjà dans un seul fichier .ca-bundle, exécutez :

cat example_com.crt example_com.ca-bundle > ssl-bundle.crt

Remplacez les noms de fichiers par les vôtres. Déplacez le fichier combiné (et la clé privée, si elle ne s’y trouve pas déjà) vers le répertoire SSL de votre serveur, par exemple /etc/ssl/ ou /etc/nginx/ssl/. Conservez le fichier de clé lisible uniquement par root :

sudo chmod 600 /etc/ssl/your_domain.key
sudo chown root:root /etc/ssl/your_domain.key

Étape 2 : Modifier le fichier de configuration NGINX

Ouvrez le fichier de configuration NGINX de votre site. Sur Debian et Ubuntu, il se trouve dans /etc/nginx/sites-available/ (avec un lien symbolique dans sites-enabled/) ; sur RHEL, CentOS, AlmaLinux et Rocky Linux, il se trouve dans /etc/nginx/conf.d/. Ajoutez ou modifiez le bloc server qui écoute sur le port 443 afin qu’il pointe vers le fichier fullchain et la clé privée :

server {
    listen 443 ssl;
    http2 on;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/ssl-bundle.crt;
    ssl_certificate_key /etc/ssl/your_domain.key;

    # Modern TLS only
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

    ssl_session_timeout 1d;
    ssl_session_cache shared:NginxSSL:10m;
    ssl_session_tickets off;

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Quelques remarques sur les directives ci-dessus :

• listen 443 ssl; active TLS sur le port 443. L’ancienne directive ssl on; a été supprimée dans NGINX 1.25 et ne doit plus apparaître dans les configurations modernes.
• http2 on; active HTTP/2 en tant que directive à part entière (NGINX 1.25.1 et versions ultérieures). Les configurations plus anciennes utilisaient listen 443 ssl http2;, qui fonctionne encore mais est obsolète.
• ssl_protocols TLSv1.2 TLSv1.3; désactive les protocoles obsolètes TLS 1.0 et 1.1. À partir de NGINX 1.27.3, c’est également le comportement par défaut si vous omettez la directive, mais la définir explicitement reste le choix le plus clair et le plus adapté aux audits.
• La liste de chiffrements correspond au profil « intermediate » de Mozilla et fonctionne avec tous les clients récents. Si vous n’avez besoin que de clients TLS 1.3, vous pouvez supprimer entièrement ssl_ciphers.

Étape 3 : Rediriger HTTP vers HTTPS

Ajoutez un bloc server distinct sur le port 80 qui redirige de façon permanente chaque requête vers HTTPS, afin que les visiteurs arrivant en HTTP simple soient dirigés vers l’URL sécurisée :

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Utiliser return 301 est plus rapide et plus sûr qu’une règle rewrite basée sur une expression régulière, et c’est la méthode que NGINX recommande lui-même.

Étape 4 : Tester la configuration et recharger NGINX

Validez toujours la configuration avant de la recharger, afin qu’une faute de frappe ne puisse pas rendre le service indisponible :

sudo nginx -t

Vous devriez voir syntax is ok et test is successful. Si une erreur est signalée, le message indique le fichier et le numéro de ligne concernés ; corrigez-la puis relancez le test. Une fois le test réussi, rechargez NGINX afin qu’il prenne en compte la nouvelle configuration sans interrompre les connexions existantes :

sudo systemctl reload nginx

Sur les systèmes ne disposant pas de systemd, utilisez plutôt le signal de rechargement propre à NGINX :

sudo nginx -s reload

Préférez reload à restart : un reload relit la configuration sans fermer les connexions actives, tandis qu’un restart les interrompt.

Étape 5 (facultative) : Activer l’agrafage OCSP (OCSP stapling)

L’agrafage OCSP permet à NGINX de fournir un statut de révocation récent et signé en même temps que le certificat, afin que les clients n’aient pas à contacter l’autorité de certification à chaque négociation. Ajoutez ce qui suit dans votre bloc server HTTPS :

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/ssl-bundle.crt;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

Rechargez à nouveau NGINX avec sudo systemctl reload nginx. L’agrafage est une étape de durcissement modeste mais utile, et la plupart des certificats modernes le prennent en charge nativement.

Vérifier l’installation

Ouvrez votre site en https:// dans un navigateur et vérifiez que le cadenas est fermé et que le certificat correspond à votre domaine. Effectuez ensuite une analyse plus approfondie avec notre SSL Checker pour obtenir un rapport instantané sur le certificat, la chaîne, ainsi que les protocoles et chiffrements proposés par votre serveur. Un résultat au vert signifie que les clients de toutes les principales plateformes feront confiance au certificat, y compris les clients mobiles et API.

Questions fréquentes