TLS-Zertifikate automatisieren, bevor die kurzen Laufzeiten dich einholen

Solange ein Zertifikat ein Jahr oder länger galt, war der Kalendereintrag ein akzeptables Verfahren. Jemand hat einmal im Jahr einen CSR erzeugt, die Datei per Ticket bei der CA eingereicht, das Ergebnis auf die Webserver kopiert und neu geladen. Mit 200 Tagen wird daraus ein halbjährlicher Pflichttermin, mit 47 Tagen ein Vorgang, der etwa achtmal im Jahr auf jedem betroffenen System ansteht. Bei zwanzig Hostnamen, verteilt auf Reverse Proxies, Mailserver, interne Portale und ein paar Appliances, ist das keine Fleißaufgabe mehr, sondern ein Ausfallrisiko.

In der Praxis scheitert es selten am Ausstellen selbst. Es scheitert daran, dass niemand vollständig weiß, wo überall Zertifikate liegen. Das gleiche Zertifikat steckt in /etc/nginx/ssl, im Java-Keystore der Anwendung, im HAProxy-PEM mit angehängtem Private Key, im Postfix und in der Firmware eines Load Balancers, der sich nur über eine Weboberfläche befüllen lässt. Die Erneuerung läuft dann durch, aber der Dienst hält das alte Zertifikat weiter im Speicher, weil der Reload fehlt.

Typische Fehler sind schnell aufgezählt: certbot renew läuft, aber der deploy-hook wurde nie geschrieben. Die HTTP-01-Challenge bricht, weil ein Redirect von HTTP auf HTTPS auch /.well-known/acme-challenge/ erfasst. Die DNS-01-Challenge scheitert an einem API-Token mit zu weiten Rechten oder an einer zu hohen TTL. Der Cronjob läuft als falscher Benutzer und darf den Private Key nicht lesen. Und das Monitoring meldet den Ablauf erst, wenn die Nutzer schon anrufen.