L’attrait est réel, et il cache une checklist
L’argument de Caddy est réellement bon : pointez un domaine vers le serveur, nommez-le dans un Caddyfile, et vous obtenez un certificat TLS valide qui se renouvelle seul tant que le serveur tourne. Pas de cron à retenir, pas de renouvellement oublié jusqu’à ce que le site vire au rouge dans un navigateur trois mois plus tard. Pour la plupart des gens, la plupart du temps, ça marche tout seul.
Mais « ça marche tout seul » décrit le chemin heureux, ça ne l’explique pas. Le HTTPS automatique est automatique parce que Caddy exécute un challenge ACME contre Let’s Encrypt à votre place — et ce challenge a des préconditions. Quand il échoue, il échoue assez silencieusement pour qu’on accuse Caddy de ce que le DNS a fait. Cet article porte donc sur la partie que la ligne unique escamote : ce qui doit être vrai avant l’émission du certificat, et comment prouver chacune de ces choses plutôt que de l’espérer.
Avant le premier paquet : lire la machine et les ports
Un gestionnaire de certificats qui veut les ports 80 et 443 n’ira pas loin si quelque chose les tient déjà. La reconnaissance n’est pas une formalité — c’est la différence entre une installation propre et un service qui refuse de démarrer sur une erreur de bind cryptique.
- Caddy est-il déjà là ?
command -v caddy && caddy version. Si oui, vous configurez une installation existante, vous n’en posez pas une neuve — et vous ne devez pas écraser unCaddyfilequi marche. - Qui détient 80 et 443 ?
ss -tlnH 'sport = :80' 'sport = :443'. Un nginx ou un Apache d’une expérience passée tenant ces ports est la raison numéro un pour laquelle Caddy ne peut pas se lier. Le challenge HTTP d’ACME a besoin du port 80 joignable ; le challenge TLS-ALPN a besoin du 443. Si un autre démon les tient, décidez qui termine le TLS avant d’aller plus loin. - Le DNS résout-il déjà vers cette machine ? Le HTTPS automatique prouve que vous contrôlez le domaine en étant joint à son adresse. Si l’enregistrement
A/AAAAne pointe pas encore ici, l’émission échouera quelle que soit la justesse de la config.
1. Installer depuis le dépôt officiel, pas un binaire égaré
Sur Debian et Ubuntu, Caddy vient d’un dépôt Cloudsmith officiel : on importe la clé de signature et on ajoute la source à /etc/apt/sources.list.d/caddy-stable.list avant un ordinaire apt-get install -y caddy. La raison d’utiliser le dépôt plutôt que de déposer un binaire téléchargé dans /usr/local/bin est sans gloire mais décisive : le paquet apporte une vraie unité systemd, un utilisateur de service, et le chemin de config que le reste du monde attend. Un binaire posé à la main marche jusqu’au redémarrage, où l’on découvre que rien ne le lance.
La preuve que cette étape a marché est une chaîne de version de caddy version — pas le fait qu’apt soit sorti à zéro. Un fait concret, vérifiable par une machine, qu’un humain ou un modèle peut lire sans deviner.
2. Le Caddyfile : où un domaine devient un certificat
Toute la raison pour laquelle Caddy paraît magique, c’est la forme de sa config. Un site HTTPS fonctionnel peut tenir en un domaine, une accolade, et quoi servir :
example.com { respond "OK" }
Ce bloc est le déclencheur du HTTPS automatique. Parce que vous avez nommé un vrai domaine — pas :80, pas localhost — Caddy sait qu’il doit obtenir un certificat pour lui et servir en 443, en redirigeant le HTTP clair vers lui. Remplacez respond par un reverse_proxy 127.0.0.1:3000 et vous avez un proxy qui termine le TLS devant une application en loopback, ce que la plupart veulent réellement.
La règle qui domine la syntaxe : ne jamais écraser un Caddyfile existant sans le sauvegarder d’abord. Un cp Caddyfile Caddyfile.bak ne coûte rien et fait la différence entre une erreur que vous annulez en une commande et un après-midi à reconstruire un routage de mémoire. Et si aucun domaine n’est encore disponible, servez sur :80 sans TLS délibérément, plutôt que de nommer un domaine qui ne résout pas et de regarder l’émission échouer en boucle.
3. Valider avant de recharger — toujours
C’est l’habitude qui prévient la plupart des pannes Caddy auto-infligées, et c’est une commande : caddy validate --config /etc/caddy/Caddyfile. Elle parse le fichier entier et répond si Caddy l’accepterait — avant de demander au serveur en marche d’y basculer. Une réponse Valid configuration est le feu vert ; tout le reste signifie que vous n’avez pas encore changé ce que le monde extérieur voit, ce qui est exactement la propriété voulue d’une étape échouée.
Ensuite systemctl reload caddy, qui applique la nouvelle config sans coupure et confirmez que systemctl is-active caddy renvoie toujours active. Rechargez, ne redémarrez jamais à l’aveugle contre un fichier non validé : un restart qui ne parse pas laisse le site à terre pour une faute de frappe.
4. Le certificat : le prouver, pas le supposer
C’est ici que le HTTPS automatique gagne ou perd votre confiance. Deux faits décident du succès du challenge, et les deux sont hors de Caddy :
- Le DNS doit pointer vers cette machine, et les ports 80/443 doivent être joignables depuis l’Internet public. Let’s Encrypt atteint votre domaine pour le vérifier. Un pare-feu qui jette le 80, un security group cloud qui n’a jamais ouvert le 443, un enregistrement pointant encore l’ancien hôte — chacun transforme « automatique » en boucle de retry silencieuse.
- Les rate limits sont réels et implacables. Une série d’émissions échouées pour le même domaine et vous êtes bloqué pour des heures. C’est pourquoi on corrige le DNS et le pare-feu d’abord, et pourquoi le comportement staging de Caddy existe — pour exercer le chemin sans dépenser le quota réel.
La vérification qui compte est un vrai handshake TLS depuis l’extérieur, une fois le DNS résolu — un curl -sI https://example.com renvoyant un certificat émis par Caddy, pas la page par défaut de la distribution ni un placeholder auto-signé. Le renouvellement que vous n’avez pas à configurer est tout l’intérêt : Caddy renouvelle en arrière-plan, bien avant l’expiration, tant que le service tourne.
Ce que Caddy ne fait pas pour vous
Terminer le TLS ne fait rien pour la sécurité de l’application derrière — une app vulnérable derrière un certificat parfait reste une app vulnérable. Le HTTPS automatique n’est pas un pare-feu ; il ouvre les ports mêmes dont il a besoin et ne sécurise rien d’autre. Il ne peut pas faire apparaître un certificat pour un domaine qui ne résout pas vers la machine, et il ne rattrapera pas un security group cloud que vous avez oublié d’ouvrir. Et le TLS on-demand — émettre des certificats pour des noms d’hôtes arbitraires à mesure que les requêtes arrivent — est puissant et piégeux à parts égales : sans un ask endpoint qui dit quels hôtes sont autorisés, il tentera volontiers d’émettre pour n’importe quoi pointé vers vous, droit dans un rate limit. La commodité n’est pas une posture de sécurité.
La vérification qui prouve que le HTTPS est réel
Dans l’ordre : caddy version pour le binaire ; caddy validate --config /etc/caddy/Caddyfile renvoyant Valid configuration ; systemctl is-active caddy à active et is-enabled pour survivre à un redémarrage ; ss -tlpn confirmant que Caddy — et seulement Caddy — tient 80 et 443 ; et, une fois le DNS résolu, un vrai handshake HTTPS externe contre le domaine. Prouvez le certificat depuis l’extérieur de la machine, car c’est le seul point de vue qui correspond à celui de vos utilisateurs.
Ce que Servor apporte là-dedans
Servor livre Caddy comme une recette — parmi 150+ playbooks vérifiés — et la forme d’une recette est exactement ce dont une tâche pilotée par ACME a besoin. Ce n’est pas un script figé tiré à l’aveugle : elle commence par la reconnaissance, en lisant si Caddy est déjà installé, si 80 et 443 sont libres, et si une config existe, pour que le run s’adapte à un serveur réel plutôt que d’en supposer un vide. Un modèle bon marché le pilote, et chaque étape qu’il propose porte sa propre vérification — le caddy validate, le is-active, la chaîne de version — si bien que le succès est prouvé, pas affirmé. Le playbook est idempotent : un Caddy existant est vérifié et rapporté plutôt que réinstallé, et il n’écrasera pas votre Caddyfile sans sauvegarde. Si aucun domaine n’est fourni, il sert sur :80 sans TLS plutôt que d’échouer à l’émission.
Le modèle d’exécution est le même que celui qui gouverne le copilote. Chaque commande est signée dans votre navigateur avec une clé dérivée de votre clé de vault, relayée verbatim, et vérifiée par l’agent sur la machine avant de s’exécuter — la recette Caddy ne plie aucune règle zero-knowledge. L’agent atteint le plan de contrôle via une connexion sortante, si bien qu’ouvrir 80 et 443 au monde ne touche jamais votre chemin d’administration.
Si vous préférez le chemin certbot contre un nginx ou un Apache existant, c’est aussi une recette ; les arbitrages entre un reverse proxy et son TLS font l’objet de l’article sur le reverse-proxy nginx, et la discipline derrière la boucle approuver-signer-vérifier est dans l’article Plan-Execute-Verify. Parcourez le reste du catalogue de recettes, ou lisez comment la partie opérationnelle s’articule dans notre guide d’exploitation des serveurs.