Comment installer un certificat SSL sur Nginx

Ce guide vous accompagne dans l’installation d’un certificat SSL sur Nginx — du téléchargement des fichiers à l’optimisation des paramètres TLS et au dépannage des erreurs courantes. Il fonctionne avec des certificats de GetHTTPS, Certbot ou toute autre source.

Si vous n’avez pas encore de certificat, obtenez-en un gratuitement en 5 minutes.

Prérequis

• Nginx installé et servant votre site en HTTP (port 80)
• Accès root/sudo au serveur
• Fichiers de certificat — vous en avez besoin de deux :
  • fullchain.pem — votre certificat + chaîne intermédiaire (combinés)
  • privkey.pem — votre clé privée

Quel fichier est lequel ? GetHTTPS vous donne quatre fichiers. Nginx a besoin de fullchain.pem (pas cert.pem) et privkey.pem. Utiliser cert.pem seul cause des erreurs de « chaîne incomplète » car les navigateurs ne peuvent pas vérifier le chemin de confiance. Formats de certificats expliqués →

Étape 1 : Télécharger les fichiers de certificat sur le serveur

Copiez les fichiers dans un répertoire sécurisé :

# Créer le répertoire
sudo mkdir -p /etc/ssl/gethttps

# Copier les fichiers (de votre machine locale vers le serveur)
sudo cp fullchain.pem /etc/ssl/gethttps/
sudo cp privkey.pem /etc/ssl/gethttps/

# Restreindre les permissions de la clé privée — seul root devrait pouvoir la lire
sudo chmod 600 /etc/ssl/gethttps/privkey.pem
sudo chmod 644 /etc/ssl/gethttps/fullchain.pem
sudo chown root:root /etc/ssl/gethttps/*

En cas de transfert via SCP :

scp fullchain.pem privkey.pem user@your-server:/tmp/
# Puis sur le serveur :
sudo mv /tmp/fullchain.pem /tmp/privkey.pem /etc/ssl/gethttps/

Étape 2 : Configurer le bloc serveur HTTPS

Éditez la configuration Nginx de votre site. Le fichier se trouve généralement à :

• /etc/nginx/sites-available/yourdomain.conf (Debian/Ubuntu)
• /etc/nginx/conf.d/yourdomain.conf (CentOS/RHEL)

Configuration complète recommandée :

# Bloc serveur HTTPS
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com www.example.com;

    # ─── Fichiers de certificat ──────────────────
    ssl_certificate     /etc/ssl/gethttps/fullchain.pem;
    ssl_certificate_key /etc/ssl/gethttps/privkey.pem;

    # ─── Protocole TLS et chiffrement ────────────
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    # ─── Cache de session (performance) ──────────
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # ─── OCSP stapling (vérification rapide) ─────
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # ─── En-têtes de sécurité ────────────────────
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;

    # ─── Votre site ─────────────────────────────
    root /var/www/html;
    index index.html;

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

# Bloc de redirection HTTP
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Ce que fait chaque section :

Étape 3 : Tester la configuration

Testez toujours avant de recharger :

sudo nginx -t

Sortie attendue :

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Si le test échoue, Nginx vous indique le numéro de ligne exact avec l’erreur. Erreurs courantes :

• Faute de frappe dans le chemin du fichier (ssl_certifcate au lieu de ssl_certificate)
• Le fichier n’existe pas au chemin spécifié
• Points-virgules manquants

Étape 4 : Recharger Nginx

sudo systemctl reload nginx

Utilisez reload, pas restart. Reload applique la nouvelle configuration aux nouvelles connexions sans couper les connexions existantes — zéro interruption de service.

Étape 5 : Vérifier le certificat

Vérification navigateur

Visitez https://yourdomain.com. Cliquez sur l’icône du cadenas pour confirmer :

• Émis par : « Let’s Encrypt » (ou votre CA)
• Valide : dates de début et de fin
• Domaine : correspond à votre URL

Vérification en ligne de commande

# Détails complets du certificat
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# Vérifier que la chaîne complète est présente
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null \
  | grep -E 'Verify return code|depth='

Attendu : Verify return code: 0 (ok) et plusieurs niveaux de profondeur (votre certificat + intermédiaire).

Vérification en ligne

Utilisez le SSL Labs Server Test pour un rapport complet. Il vérifie :

• Validité de la chaîne de certificats
• Support des protocoles (devrait montrer TLS 1.2 + 1.3 uniquement)
• Force des suites de chiffrement
• Vulnérabilités connues (BEAST, POODLE, Heartbleed)
• Configuration HSTS

Objectif : Note A ou A+.

Comment renouveler

Quand votre certificat approche de l’expiration (jour 60 sur 90 pour Let’s Encrypt) :

1. Obtenez un nouveau certificat depuis GetHTTPS (ou votre outil de renouvellement)
2. Remplacez les fichiers :

   sudo cp new-fullchain.pem /etc/ssl/gethttps/fullchain.pem
   sudo cp new-privkey.pem /etc/ssl/gethttps/privkey.pem

3. Rechargez Nginx :

   sudo systemctl reload nginx

Pas besoin de redémarrer. Nginx prend en compte les nouveaux fichiers au rechargement. Guide de renouvellement complet →

Vous voulez un renouvellement automatique ? Installez Certbot pour un renouvellement automatisé : sudo certbot --nginx -d example.com. Il gère tout, y compris la configuration Nginx.

Dépannage

« SSL: error:0B080074:x509 certificate routines »

Cause : Vous utilisez cert.pem au lieu de fullchain.pem.

Correction : Changez ssl_certificate pour pointer vers fullchain.pem, qui inclut à la fois votre certificat et la chaîne de confiance intermédiaire :

ssl_certificate /etc/ssl/gethttps/fullchain.pem;  # PAS cert.pem

« cannot load certificate key »

Cause : Les permissions du fichier de clé privée sont incorrectes, le fichier est corrompu, ou la clé ne correspond pas au certificat.

Correction :

# Vérifier les permissions (devrait être 600)
ls -la /etc/ssl/gethttps/privkey.pem

# Vérifier que la clé est valide
sudo openssl ec -in /etc/ssl/gethttps/privkey.pem -check  # Pour ECDSA
sudo openssl rsa -in /etc/ssl/gethttps/privkey.pem -check  # Pour RSA

# Vérifier que la clé correspond au certificat
sudo openssl x509 -noout -modulus -in /etc/ssl/gethttps/fullchain.pem | md5sum
sudo openssl rsa -noout -modulus -in /etc/ssl/gethttps/privkey.pem | md5sum
# Les deux hashes DOIVENT correspondre

« nginx: [emerg] bind() to 0.0.0.0:443 failed »

Cause : Le port 443 est déjà utilisé par un autre processus.

Correction :

# Trouver ce qui utilise le port 443
sudo ss -tlnp | grep 443

# Généralement : une autre instance Nginx ou Apache
sudo systemctl stop apache2  # Si Apache est en cours d'exécution
sudo systemctl reload nginx

HTTPS fonctionne mais le navigateur affiche « Non sécurisé »

Cause : Contenu mixte — votre page charge des images, scripts ou CSS via http://.

Correction : Ouvrez DevTools (F12) → Console → cherchez les avertissements « Mixed Content ». Mettez à jour toutes les URLs de ressources pour utiliser https:// ou des chemins relatifs.

« ERR_SSL_VERSION_OR_CIPHER_MISMATCH »

Cause : Le client ne prend pas en charge les versions TLS ou les chiffrements proposés par votre serveur.

Correction : Assurez-vous que votre configuration inclut TLS 1.2 (pas seulement 1.3) :

ssl_protocols TLSv1.2 TLSv1.3;  # PAS seulement TLSv1.3

Le certificat apparaît comme « Non fiable » malgré des fichiers corrects

Cause : La chaîne de certificats est incomplète — fullchain.pem ne contient pas le certificat intermédiaire, ou le fichier est dans le mauvais ordre.

Correction : Reconstruisez fullchain.pem en concaténant votre certificat + l’intermédiaire :

cat cert.pem chain.pem > fullchain.pem

L’ordre est important : votre certificat en premier, puis l’intermédiaire.

Questions fréquentes

Ai-je besoin de fichiers de configuration séparés pour HTTP et HTTPS ?

Non. Mettez les deux blocs server (port 80 et 443) dans le même fichier. Le bloc HTTP existe uniquement pour rediriger vers HTTPS.

Dois-je utiliser ssl on; ?

Non. ssl on; est obsolète. Utilisez listen 443 ssl; à la place — le paramètre ssl dans la directive listen est l’approche moderne.

Quelle est la différence entre reload et restart ?

reload applique élégamment la nouvelle configuration aux nouvelles connexions sans couper les connexions existantes. restart arrête et redémarre le processus, coupant brièvement toutes les connexions. Utilisez toujours reload pour les changements de certificat.

Puis-je servir plusieurs domaines avec des certificats différents ?

Oui. Utilisez des blocs server séparés avec des directives server_name, ssl_certificate et ssl_certificate_key différentes. Nginx utilise SNI (Server Name Indication) pour servir le bon certificat en fonction du nom d’hôte demandé.

Nginx prend-il en charge les certificats ECDSA/ECC ?

Oui. Nginx gère les certificats ECDSA exactement comme RSA — mêmes directives, même format de fichier. GetHTTPS génère par défaut ECDSA P-256 (clés plus petites, négociations plus rapides).

Comment activer HTTP/2 ?

Ajoutez http2 à la directive listen : listen 443 ssl http2;. C’est déjà inclus dans la configuration recommandée ci-dessus. HTTP/2 nécessite HTTPS — il ne peut pas être utilisé via du HTTP non chiffré.