Configuration Nginx SSL/TLS en pratique : du certificat HTTPS au durcissement A+

L’alerte de monitoring a retenti soudainement. En ouvrant le téléphone : certificat expiré — un certificat gratuit de 90 jours, complètement oublié. L’avertissement rouge « Non sécurisé » du navigateur flottait comme un drapeau moqueur sur la page d’accueil du blog.

Après cet incident, j’ai passé une semaine à maîtriser la configuration Nginx SSL/TLS de bout en bout. De F à A+ sur SSL Labs, du renouvellement manuel à l’automatisation complète, des performances qui traînent à un handshake sous 100 ms.

HTTPS, ce n’est pas seulement un cadenas dans la barre d’adresse. Google a clairement indiqué que HTTPS est un facteur de classement. Bien configuré, le trafic organique peut progresser de 15 à 20 %. Surtout, cela bloque l’écoute en man-in-the-middle. Sans HTTPS, c’est comme crier son code bancaire en public.

Cet article vous guide pour configurer Nginx HTTPS de zéro : demande de certificat Let’s Encrypt, durcissement TLS 1.3, modèle SSL Labs A+, et renouvellement automatique pour la production. Toutes les configurations sont prêtes à copier-coller.

Chapitre 1 : bases HTTPS et choix du type de certificat

1.1 Pourquoi chaque site a besoin de HTTPS

HTTP transmet en clair : chaque page visitée, chaque formulaire soumis circule nu sur le réseau. Le WiFi public du café, la sortie réseau de l’entreprise, l’équipement de l’opérateur — n’importe quel nœud intermédiaire peut voir ce que vous envoyez.

HTTPS ajoute une couche TLS entre HTTP et TCP. Les données sont chiffrées avant l’envoi et déchiffrées à l’arrivée ; l’espion ne voit qu’un flot illisible.

TLS ne se limite pas au chiffrement. Il fournit aussi l’authentification — garantir que vous accédez au vrai example.com, pas à un site de phishing après hijack DNS. D’où l’avertissement rouge du navigateur sur certificat expiré ou domaine non concordant : « ce site n’est peut-être pas celui qu’il prétend être ».

1.2 Les trois types de certificats SSL : DV, OV, EV

Les certificats se classent selon le niveau de vérification :

Pour la plupart des projets personnels et petites équipes, un certificat DV suffit largement. Le DV gratuit Let’s Encrypt, valable 90 jours, est aussi fiable dans les navigateurs qu’un DV payant. Le seul « inconvénient » : renouveler tous les 90 jours — mais avec l’automatisation, ce n’est plus un problème.

OV et EV se distinguent surtout par l’affichage dans la barre d’adresse. EV affichait le nom de l’entreprise (ex. « Banque industrielle et commerciale de Chine »), mais les navigateurs réduisent de plus en plus cette emphase ; Chrome n’affiche plus par défaut le nom EV. Avec des prix OV/EV souvent élevés, le rapport qualité-prix est faible.

1.3 Let’s Encrypt : le meilleur choix gratuit

Let’s Encrypt est une autorité de certification à but non lucratif opérée par l’ISRG (Internet Security Research Group). Avantages principaux :

• Entièrement gratuit : certificats DV gratuits à vie
• Automatisation : émission et renouvellement via le protocole ACME
• Confiance large : tous les navigateurs et OS majeurs
• Validité 90 jours : certificats courts plus sûrs, incitent à l’automatisation

Inconvénients : uniquement DV, pas d’OV/EV ; certificat wildcard nécessite une validation DNS (un peu plus lourd). Pour 99 % des projets personnels et sites de taille moyenne, ces limites ne comptent pas.

Nous utiliserons Certbot — client officiel Let’s Encrypt — pour demander le certificat.

Chapitre 2 : demande de certificat Let’s Encrypt en pratique

2.1 Installer Certbot

L’installation varie selon l’OS. Sous Ubuntu, c’est le plus simple :

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

# Ubuntu 20.04+ / Debian 10+
sudo apt update
sudo apt install certbot python3-certbot-nginx

Sous CentOS/RHEL, activer d’abord le dépôt EPEL :

# CentOS 8 / RHEL 8
sudo dnf install epel-release
sudo dnf install certbot python3-certbot-nginx

Après installation, certbot --version vérifie la version. Ensuite, demander le certificat.

2.2 Demander un certificat

Certbot propose plusieurs modes de validation ; les plus courants sont standalone et webroot. Si Nginx tourne déjà, privilégiez webroot :

# Mode webroot : site déjà en ligne
sudo certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com

-w indique la racine web, -d le domaine. Une seule commande peut couvrir plusieurs domaines.

Si Nginx n’est pas démarré ou pour un serveur de test temporaire, mode standalone :

# Mode standalone : occupe temporairement le port 80
sudo certbot certonly --standalone -d example.com -d www.example.com

Certbot lance un serveur HTTP temporaire, puis le ferme après validation. Le port 80 doit être libre ; si Nginx tourne, arrêtez-le d’abord.

Une option plus simple : le plugin Nginx de Certbot modifie la config automatiquement :

# Mode auto : Certbot modifie la config Nginx
sudo certbot --nginx -d example.com -d www.example.com

Cette commande demande le certificat, modifie Nginx et configure la redirection HTTPS. Pratique pour débuter ; en production, configurez manuellement pour un contrôle fin des paramètres SSL.

2.3 Structure des fichiers certificat

Après succès, les fichiers sont dans /etc/letsencrypt/live/example.com/ :

/etc/letsencrypt/live/example.com/
├── cert.pem        # Certificat du domaine
├── chain.pem       # Chaîne intermédiaire
├── fullchain.pem   # Chaîne complète (cert + chain)
└── privkey.pem     # Clé privée

Nginx utilise deux fichiers : fullchain.pem (ssl_certificate) et privkey.pem (ssl_certificate_key). privkey.pem est sensible, permissions 600 — ne jamais le divulguer.

Chapitre 3 : configuration SSL de base Nginx

3.1 Configuration HTTPS minimale

Avec le certificat en place, configurez HTTPS dans Nginx. Version la plus simple :

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

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Autres réglages...
    root /var/www/example.com;
    index index.html;
}

HTTPS fonctionne, mais le score reste autour de D. Problème : pas de version TLS explicite ; par défaut TLS 1.0 et 1.1 — obsolètes et dangereux.

3.2 Redirection HTTP vers HTTPS

Configurer HTTPS ne suffit pas : les utilisateurs peuvent arriver en HTTP. Redirigez tout le trafic HTTP vers HTTPS :

server {
    listen 80;
    server_name example.com www.example.com;

    # Redirection permanente vers HTTPS
    return 301 https://$server_name$request_uri;
}

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

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Autres réglages...
}

return 301 est une redirection permanente, mise en cache par le navigateur. La prochaine fois qu’un utilisateur tape http://, le navigateur ira directement en https://, sans requête supplémentaire.

3.3 Erreur de configuration fréquente

Beaucoup ajoutent http2 dans listen 443 ssl http2;. Depuis Nginx 1.25.1, HTTP/2 passe par la directive http2 :

# Nouvelle syntaxe Nginx 1.25.1+
server {
    listen 443 ssl;
    http2 on;  # Directive http2 séparée
    server_name example.com;

    # ...
}

Sur une version récente, préférez cette syntaxe pour éviter les avertissements. nginx -v vérifie la version.

Chapitre 4 : durcissement sécurité TLS 1.3

4.1 Choix de la version TLS

Quatre versions TLS : 1.0, 1.1, 1.2, 1.3. Les versions 1.0 et 1.1 sont obsolètes ; tous les navigateurs majeurs les ont abandonnées en 2020.

L’avantage clé de TLS 1.3 : handshake de 2-RTT (aller-retour) à 1-RTT, latence théoriquement divisée par deux. En pratique, le handshake TLS 1.3 peut rester sous 100 ms.

Dans Nginx, ssl_protocols fixe les versions :

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

ssl_protocols TLSv1.2 TLSv1.3;

Ne pas n’activer que TLS 1.3. En 2026, presque tous les navigateurs le supportent, mais certains clients HTTP anciens (outils API, appareils embarqués) peuvent ne pas le faire. Garder TLS 1.2 comme repli est plus prudent.

4.2 Configuration Cipher Suite

La Cipher Suite (suite de chiffrement) définit algorithme, échange de clés et MAC. Un mauvais choix rend HTTPS inefficace.

Liste recommandée TLS 1.3 en 2026 :

ssl_protocols TLSv1.2 TLSv1.3;

# Cipher TLS 1.3 (Nginx utilise la liste OpenSSL par défaut)
# Cette ligne peut être omise
ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

# Cipher TLS 1.2 (rétrocompatibilité)
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;

# Priorité aux cipher du serveur
ssl_prefer_server_ciphers on;

Points clés :

• ECDHE : échange de clés courbe elliptique, plus sûr et rapide que RSA
• AES-GCM : chiffrement authentifié, plus sûr que CBC
• CHACHA20-POLY1305 : meilleures perfs mobile sans accélération AES matérielle

En cas de doute, Mozilla SSL Configuration Generator : https://ssl-config.mozilla.org/

4.3 HSTS : forcer l’accès HTTPS

HSTS (HTTP Strict Transport Security) indique au navigateur : « ce site n’accepte que HTTPS ». Même si l’utilisateur tape http://, le navigateur redirige localement vers https://, sans requête réseau supplémentaire.

# En-tête HSTS
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Paramètres :

• max-age=31536000 : validité 1 an (en secondes)
• includeSubDomains : inclut tous les sous-domaines
• preload : inscription à la HSTS Preload List (soumission sur hstspreload.org)

Attention : une fois HSTS activé, le navigateur met en cache longtemps. Si vous devez encore tester en HTTP, n’ajoutez pas preload ou réduisez max-age.

Chapitre 5 : optimisation des performances SSL

5.1 SSL Session Cache

Chaque handshake TLS implique échange de clés et vérification de certificat. Session Cache permet au client de réutiliser une session pendant un certain temps, sans handshake complet.

# Configuration Session Cache
ssl_session_cache shared:SSL:10m;  # Cache 10 Mo, ~40 000 sessions
ssl_session_timeout 1d;            # Validité session 1 jour
ssl_session_tickets off;           # Désactiver Session Ticket (plus sûr)

shared:SSL:10m : cache 10 Mo partagé entre workers. ~4 000 sessions par Mo, 10 Mo suffisent pour un site moyen.

ssl_session_tickets off pour la sécurité : Session Ticket nécessite une clé serveur ; si elle fuit, un attaquant peut déchiffrer l’historique. Désactivé = plus sûr, mais charge serveur accrue — adapté aux exigences élevées.

5.2 OCSP Stapling

Pour vérifier un certificat, le navigateur interroge l’OCSP de l’AC. Cela ajoute une requête réseau et expose les sites visités.

OCSP Stapling : le serveur interroge l’OCSP à la place du navigateur, met en cache le résultat et l’envoie avec la réponse. Confidentialité et latence réduites.

# Configuration OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

resolver définit le serveur DNS pour résoudre le domaine du serveur OCSP. 8.8.8.8 et 8.8.4.4 de Google sont courants.

Test avec OpenSSL :

openssl s_client -connect example.com:443 -status < /dev/null 2>&1 | grep -A 17 "OCSP response"

Si vous voyez « OCSP Response Status: successful », OCSP Stapling fonctionne.

5.3 Réglage ssl_buffer_size

ssl_buffer_size contrôle la taille des enregistrements TLS. Par défaut 16 Ko — trop pour les petites réponses (API), augmente le TTFB (time to first byte).

Pour API ou blog à petites réponses :

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

ssl_buffer_size 4k;  # Adapté aux petites réponses

Pour serveur de gros fichiers, gardez 16 Ko par défaut ou montez à 32 Ko.

Chapitre 6 : renouvellement automatique des certificats

6.1 Commande de renouvellement Certbot

Les certificats Let’s Encrypt durent 90 jours ; renouvellement obligatoire. Certbot fournit renew :

# Test de renouvellement (sans renouveler réellement)
sudo certbot renew --dry-run

# Renouvellement effectif
sudo certbot renew

renew vérifie toutes les dates d’expiration ; seuls les certificats avec moins de 30 jours restants sont renouvelés. Vous pouvez lancer la commande quotidiennement sans gaspiller le quota de débit Let’s Encrypt.

6.2 Tâche planifiée crontab

La méthode la plus fiable : crontab pour le renouvellement automatique :

# Éditer le crontab root
sudo crontab -e

Ajoutez ces deux lignes :

# Vérification à 3h00 et 15h00 chaque jour
0 3 * * * /usr/bin/certbot renew --quiet --post-hook "systemctl reload nginx"
0 15 * * * /usr/bin/certbot renew --quiet --post-hook "systemctl reload nginx"

--quiet mode silencieux. --post-hook "systemctl reload nginx" recharge Nginx après renouvellement réussi.

Pourquoi deux fois par jour ? Les échecs occasionnels (DNS temporaire) arrivent ; plus de vérifications améliorent le taux de succès.

6.3 Test de renouvellement et dépannage

En cas d’échec, Certbot journalise dans /var/log/letsencrypt/letsencrypt.log. Problèmes fréquents :

1. Port occupé : standalone exige le port 80 libre
2. Échec DNS : vérifier que le domaine pointe vers le serveur
3. Limite de débit : Let’s Encrypt autorise 5 demandes identiques par semaine ; utilisez --dry-run pour les tests
4. Permissions : Certbot doit lire/écrire /etc/letsencrypt/

Flux de test complet :

# 1. dry-run d'abord
sudo certbot renew --dry-run

# 2. Si dry-run OK, renouvellement réel
sudo certbot renew

# 3. Vérifier la validité
sudo certbot certificates

# 4. Recharger Nginx
sudo systemctl reload nginx

Modèle de configuration complet

Modèle Nginx SSL prêt pour la production, score SSL Labs A+ :

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

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

    # Certificats
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Versions TLS
    ssl_protocols TLSv1.2 TLSv1.3;

    # Cipher Suite
    ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256: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_prefer_server_ciphers on;

    # En-têtes de sécurité
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    add_header X-Frame-Options SAMEORIGIN always;
    add_header X-Content-Type-Options nosniff always;
    add_header X-XSS-Protection "1; mode=block" always;

    # Session Cache
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # Optimisation performance
    ssl_buffer_size 4k;

    # Site
    root /var/www/example.com;
    index index.html index.htm;

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

Après configuration, testez sur SSL Labs : https://www.ssllabs.com/ssltest/

Conclusion

Configurer HTTPS est accessible — quelques lignes suffisent pour démarrer. Atteindre A+ sur SSL Labs tout en équilibrant performance et compatibilité exige de comprendre versions TLS, Cipher Suite, Session Cache et OCSP Stapling.

Points clés :

1. Certificat : Let’s Encrypt gratuit, Certbot pour l’automatisation
2. Versions TLS : TLS 1.2 + 1.3, désactiver 1.0 et 1.1
3. Cipher Suite : priorité ECDHE et AES-GCM, CHACHA20 en complément
4. HSTS : forcer HTTPS, réduire les redirections
5. Performance : Session Cache et OCSP Stapling indispensables
6. Renouvellement auto : crontab en double, rechargement Nginx après renouvellement

Copiez le modèle ci-dessus dans votre config Nginx, adaptez domaine et chemins de certificats, et c’est prêt. Testez ensuite sur SSL Labs — dites-moi en commentaire votre score, je parie sur A+.