Nginx HTTPS avec Certbot - Guide Complet et Automatisé

Passer un site Nginx en HTTPS proprement, ce n’est pas seulement “mettre un certificat”. Il faut valider le domaine, servir le bon vhost, gérer la redirection HTTP vers HTTPS, puis renouveler sans interruption. Avec Certbot, je vise un flux simple: peu d’intervention manuelle, des contrôles clairs, et une configuration que je peux refaire en production sans stress.

Ce que Certbot fait réellement avec Nginx

Je vois souvent une confusion simple: Certbot n’est pas un “plugin SSL” au sens passif du terme. C’est un client ACME, c’est-à-dire un outil qui prouve que vous contrôlez un domaine, récupère un certificat auprès d’une autorité de certification publique, puis l’installe ou prépare son installation. Avec Nginx, le mode le plus pratique peut aussi modifier la configuration pour activer HTTPS automatiquement.

Le point important, côté exploitation, est que Certbot fonctionne très bien quand le site existe déjà en HTTP et répond sur le port 80. C’est ce que la documentation officielle recommande pour les modes --nginx et --webroot. Si votre contrainte réseau empêche cette ouverture, vous basculez plutôt sur une validation DNS.

Je résume la logique ainsi: Certbot gère le cycle de vie, Nginx sert le trafic. Le premier demande et renouvelle; le second présente le certificat à vos visiteurs et applique la redirection. Cette séparation aide à comprendre pourquoi une erreur de vhost, de DNS ou de pare-feu peut bloquer l’obtention du certificat alors que Nginx lui-même fonctionne parfaitement.

Cette distinction posée, la vraie question devient celle de la préparation du serveur: si le socle n’est pas propre, l’automatisation ne rattrape rien.

Préparer le serveur pour un premier certificat propre

Avant de lancer la moindre commande, je vérifie toujours cinq choses: le nom de domaine pointe vers la bonne IP, le site répond déjà en HTTP, les ports 80 et 443 sont ouverts, la configuration Nginx est valide, et j’ai une copie de sauvegarde du vhost concerné. Cette étape paraît banale, mais elle élimine la majorité des incidents “ça marche en local mais pas chez l’autorité de validation”.

• Vérifiez les enregistrements A et AAAA du domaine principal et de ses alias.
• Assurez-vous qu’un server_name cohérent est présent dans le bloc Nginx concerné.
• Laissez le port 80 accessible pendant la validation initiale.
• Testez la configuration avec nginx -t avant et après toute modification.
• Conservez une copie du fichier de configuration si vous intervenez sur un serveur déjà en production.

J’insiste sur le port 80 parce que c’est le détail qui piège le plus souvent les déploiements propres. Certbot peut aussi travailler avec d’autres méthodes, mais le mode classique avec Nginx s’appuie généralement sur une validation HTTP-01, donc sur une requête externe reçue par le serveur.

Quand tout cela est en place, l’émission devient une opération courte. Sur un site simple, le vrai gain n’est pas la vitesse de la commande, mais le fait de pouvoir refaire exactement la même opération plus tard sans improviser.

Choisir le bon mode entre automatisation et contrôle

Tout le monde n’a pas le même niveau de confort avec une configuration Nginx qui bouge toute seule. Dans un contexte DevOps, je préfère arbitrer entre vitesse, lisibilité et maîtrise du changement. Le bon mode n’est pas le plus “intelligent” sur le papier, c’est celui qui s’intègre le mieux à votre manière de livrer.

La règle que j’applique est simple: si le site est classique, je prends le mode le plus direct; si la configuration est déjà très structurée, je garde davantage la main. Dans les deux cas, l’objectif reste le même: éviter qu’un certificat devienne une exception à traiter à la main à chaque renouvellement.

Une fois le mode choisi, il reste à brancher le certificat sans casser le trafic existant.

Mettre HTTPS en place sans casser le trafic

Le flux le plus courant ressemble à ceci: j’exécute Certbot, je laisse le plugin Nginx créer ou ajuster les blocs nécessaires, puis je vérifie immédiatement la syntaxe et la redirection. Sur un domaine unique, la commande de départ reste souvent très proche de sudo certbot --nginx -d exemple.fr -d www.exemple.fr.

Ensuite, je contrôle trois points: le certificat a bien été posé, la clé privée reste protégée sur le serveur, et la configuration HTTPS pointe vers les bons fichiers. Nginx s’attend à des directives comme ssl_certificate et ssl_certificate_key; dans les déploiements Certbot, on retrouve très souvent les chemins sous /etc/letsencrypt/live/....

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

server {
    listen 443 ssl;
    server_name exemple.fr www.exemple.fr;

    ssl_certificate     /etc/letsencrypt/live/exemple.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/exemple.fr/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

Je trouve utile de garder cette structure en tête, même quand Certbot modifie la configuration à ma place. Elle montre bien le rôle de chaque bloc: le port 80 redirige, le port 443 termine TLS, et l’application reste derrière le proxy inverse. Pour un backend Node.js, un service NoSQL ou une API métier, c’est exactement ce qu’on veut: sécuriser l’accès sans réécrire l’architecture.

Une fois le HTTPS en service, la vraie discipline commence: s’assurer qu’il ne tombera pas silencieusement dans 60 jours.

Automatiser le renouvellement sans mauvaise surprise

Sur le papier, le sujet paraît trivial. En pratique, c’est là que beaucoup de serveurs deviennent fragiles. La documentation de l’autorité de certification indique encore des certificats par défaut valables 90 jours, avec une recommandation de renouvellement à 60 jours, et une transition progressive vers des durées plus courtes. Je ne considère donc plus le renouvellement comme une tâche secondaire: c’est une partie du service, au même titre que le déploiement.

Ma vérification standard est toujours la même: sudo certbot renew --dry-run. Si ce test passe, je fais ensuite un contrôle Nginx avec sudo nginx -t, puis un rechargement propre avec sudo systemctl reload nginx. Le rechargement suffit dans la grande majorité des cas; il n’y a pas besoin d’un redémarrage brutal.

Quand l’installation ne pose pas déjà un mécanisme automatique, je le planifie via un timer systemd ou une tâche cron. L’idée n’est pas de renouveler “au plus vite”, mais de renouveler de façon régulière et décalée, pour éviter les pics inutiles et laisser de la marge si une validation échoue un jour donné.

Je conseille aussi d’intégrer un contrôle externe simple, par exemple une alerte qui vérifie la date d’expiration ou une surveillance de l’état HTTPS depuis l’extérieur. Le renouvellement automatique est fiable, mais une alerte de secours reste un filet de sécurité utile, surtout sur des sites qui portent du trafic métier.

Quand ce cycle est propre, la plupart des incidents restants viennent d’erreurs de configuration, pas de Certbot lui-même.

Les erreurs qui coûtent le plus de temps

Les problèmes que je vois revenir sont rarement spectaculaires. Ils viennent plutôt d’un détail mal aligné entre DNS, Nginx et le pare-feu. La bonne nouvelle, c’est qu’ils se diagnostiquent vite quand on sait où regarder.

• Le domaine ne pointe pas vers la bonne machine : vérifiez l’IP publique réelle, y compris pour le record AAAA si vous avez de l’IPv6.
• Le port 80 est bloqué : la validation HTTP échoue avant même de toucher à TLS.
• Le mauvais server_name répond : Nginx sert un autre vhost que celui prévu pour la validation.
• La configuration n’a pas été rechargée : le certificat est posé, mais le service utilise encore l’ancienne version.
• Le mode standalone entre en conflit : Nginx occupe déjà le port 80, donc Certbot ne peut pas lancer son serveur temporaire.
• HSTS est activé trop tôt : si le renouvellement n’est pas encore validé de bout en bout, vous compliquez le retour arrière.

Je recommande aussi de rester prudent avec les modifications manuelles sous /etc/letsencrypt. Les fichiers de renouvellement existent pour être relus par Certbot, pas pour devenir une zone d’expérimentation. Si vous devez changer la logique de validation ou le chemin d’un webroot, testez d’abord avec un renouvellement à blanc.

Et si votre besoin dépasse un simple domaine de site web, le choix du challenge change lui aussi.

Quand il faut sortir du cas classique

Le cas “un site, un domaine, un Nginx simple” couvre beaucoup de déploiements, mais pas tous. Si vous devez émettre un wildcard, si le port 80 ne peut pas être exposé, ou si vos certificats doivent s’intégrer à une plateforme déjà très orchestrée, je préfère réfléchir au challenge avant de réfléchir au plugin.

Le cas le plus courant ici est le DNS-01. Il évite les connexions entrantes pour la validation et devient très utile dans les environnements fermés ou les architectures où Nginx n’est qu’une brique parmi d’autres. Le prix à payer, c’est l’automatisation du DNS: sans API ou sans intégration, vous retombez dans le manuel, ce qui annule une bonne partie de l’intérêt.

Ce que je garde en tête pour un Nginx durable en 2026

Pour un serveur stable, je privilégie une approche très simple: validation claire, certificat installé sans ambiguïté, redirection nette vers HTTPS, puis renouvellement testé avant la mise en production. C’est ce qui donne un système lisible pour l’équipe et robuste quand on doit intervenir vite.

• Je documente le mode choisi, surtout si j’ai utilisé certonly ou une validation DNS.
• Je teste toujours le renouvellement avec --dry-run avant de considérer le sujet comme clos.
• Je n’active pas des durcissements comme HSTS trop tôt, tant que le cycle de renouvellement n’est pas prouvé.
• Je conserve une sauvegarde du vhost et des fichiers Certbot avant toute modification sensible.
• Si le parc client le permet, je laisse l’outil choisir une clé moderne plutôt que de figer un vieux réflexe RSA sans raison.

Si je devais résumer la méthode, je dirais que le bon usage de Certbot avec Nginx consiste moins à “obtenir un certificat” qu’à installer une routine d’exploitation fiable. Une fois cette routine en place, HTTPS cesse d’être un sujet de crise et redevient ce qu’il doit être: une couche de sécurité qui fonctionne en arrière-plan.