Die meisten Administratoren haben sich in den letzten Jahren an den Komfort beim Ausstellen von TLS-Zertifikaten für ihre Server gewöhnt. Die Zertifikate kommen automatisch, sind kostenfrei und lassen sich mit wenig Aufwand erneuern. Dank Let's Encrypt ist die verschlüsselte HTTP-Kommunikation heute der Standard.

Eine kürzlich durchgeführte Änderung zwingt jetzt aber viele zum Umdenken. Seit Anfang 2026 stellt Let's Encrypt keine Zertifikate zur Clientauthentifizierung mehr aus. Der Hintergrund ist eine von Google durchgesetzte Policy-Änderung, dass innerhalb derselben PKI vertrauenswürdige TLS-Zertifikate nicht mehr für beide Zwecke – also Client- und Serverauthentifizierung – ausgestellt werden dürfen. Let's Encrypt hat folgerichtig entschieden [1], nur noch Zertifikate für die Serverauthentifikation auszugeben. Am 13. Mai wird das ACME-Profil "tlsclient", das der Ausstellung von Clientzertifikaten dient, endgültig entfernt.

Wenn Sie nur Webserver auf Ihren Servern betreiben, ist der Wechsel für Sie unproblematisch und Sie dürften vermutlich gar nichts davon mitbekommen. Sichern Sie jedoch auch interne Strukturen mit Zertifikaten von Let's Encrypt ab, wird das für Sie spätestens mit Ablauf der Zertifikate nach drei Monaten ein Problem. Das betrifft alle Strukturen, die Zertifikate für die gegenseitige Authentifizierung von Systemen verwenden, etwa zwei API-Server, ein Kubernetes-Cluster oder ein OpenVPN-Server mit Clientzertifikaten für die Benutzer.

Die naheliegende Lösung, einfach nur wieder eine eigene interne Certificate Authority (CA) zu betreiben, wie schon vor Let's Encrypt, sollte nicht der bevorzugte Weg sein. Denn damit steigt der Aufwand, der mit dem Erneuern der Zertifikate einhergeht, wieder deutlich, was dann erneut zu schier endlos laufenden Zertifikaten führt – zurück ins Zertifikat-Mittelalter. Um genau das zu verhindern, soll die neue CA bestenfalls genau so viel Komfort bieten, wie von Let's Encrypt bekannt.

Moderne Infrastrukturen erfordern moderne Sicherheitskonzepte, dazu gehören eben auch kurze Zertifikatlaufzeiten und automatische Aktualisierung der Zertifikate. Zusätzlich können Sie die Regeln zur Verifizierung selbst bestimmen und müssen sich nicht mehr an vorgegebene Rate-Limits halten.

Das Konzept ist erstaunlich einfach: Sie betreiben eine eigene CA, die eben auch ACME als Protokoll zur Ausstellung von Zertifikaten unterstützt. Die Server (und auch Clients) in Ihrem Netzwerk sprechen mit dieser CA genauso, wie sie auch mit Let's Encrypt sprechen würden. Der Unterschied besteht nur darin, dass die Vertrauenskette intern aufgebaut wird, also alle Geräte Ihrer Root-CA vertrauen müssen.

Für die Umsetzung verwenden wir die Step CA von Smallstep [2]. Step CA kombiniert die PKI direkt mit einem integrierten ACME-Server und ermöglicht so den Aufbau des eigenen Let's-Encrypt-Dienstes. Glücklicherweise hat Smallstep die Installation des Dienstes mittels Docker sehr einfach gestaltet. Mit dem folgenden Kommando starten Sie den Dienst auf Ihrer Maschine. Ersetzen Sie localhost mit dem Namen, mit dem Ihre Maschine im Netzwerk erreichbar ist. Für lokale Testzwecke können Sie natürlich "localhost" stehen lassen:

Notieren Sie sich aus der Ausgabe den SHA256-Fingerprint Ihrer CA und den Benutzernamen und das Passwort für die Administration der CA. Diese werden nur einmalig beim Start angezeigt, bei Verlust müssen Sie eine neue CA aufsetzen.

Nach dem Start öffnen Sie die URL "https://localhost:9000" und fragen zum Beispiel unter "https://localhost:9000/roots.pem" das Wurzelzertifikat ab. Wenn Sie dieses auf dem System oder in Ihrem Browser installieren, müssen Sie die Warnung beim Zugriff nicht mehr wegklicken.

Um den ACME-Betrieb zu testen, rufen Sie "https://localhost:9000/acme/acme/directory" auf. Wenn die Verbindung aufgebaut wird und Sie eine JSON-Datei mit Links zu den Endpunkten sehen, ist Ihre eigene Let's-Encrypt-Instanz schon einsatzbereit.

Natürlich möchten wir jetzt auch das erste Zertifikat für unseren Dienst ausstellen. Dafür muss der ACME-Server über das Netzwerk auf Port 9000 erreichbar sein, und im Gegenzug der Server, für den wir das Zertifikat ausstellen möchten, auf Port 80 ebenfalls. Wenn Sie weiterhin nur lokal testen möchten, müssen Sie dann Ihren Hostnamen noch in die Hostdatei des ACME-Servers eintragen. Dafür können Sie zunächst den Namen des Containers herausfinden und dann mit

auf die Shell im Container zugreifen. Dort verwenden Sie ifconfig oder route, um die Adresse des Hostsystems herauszufinden, und vim, um die Datei "/etc/hosts" entsprechend zu bearbeiten. Nun verwenden wir den klassischen certbot und geben einfach beim Aufruf unseren eigenen Server als Backend an. Speichern Sie das oben bereits abgefragte Root-Zertifikat der CA als "roots.pem" ab und geben Sie es in der Kommandozeile dann mit an. Für unser Setup nutzen wir:

Sie werden feststellen, dass das Zertifikat, das Sie jetzt erhalten haben, nur 24 Stunden gültig ist – dies ist der Standardwert für die Laufzeit der Step CA. Um diese auf die Let's Encrypt üblichen 90 Tage (entspricht 2160 Stunden) festzulegen, müssen Sie die Konfiguration Ihrer CA anpassen. Im Ordner "./step/config/" finden Sie die Datei "ca.json". Dort fügen Sie diese Zeilen ein:

Nach der Änderung starten Sie den Container neu und stellen sich ein weiteres Zertifikat aus. Vergessen Sie im Zweifel nicht, die "/etc/hosts"-Datei noch einmal anzupassen. Die Meldung von certbot zeigt nun eine entsprechende Laufzeit von 90 Tagen an.

Für die automatische Aktualisierung müssen Sie im Grunde gar nichts anders machen, als Sie es auch bei Let's Encrypt schon gemacht haben. Mit certbot renew aktualisieren Sie einfach die Zertifikate. Das ist wie gewohnt als Cronjob oder auch über Systemd-Timer möglich. Sie können die Zertifikate sogar mit einem klassischen Let's-Encrypt-Zertifikat auf demselben Server laufen lassen, die Einstellungen des Backends werden nämlich für jedes Zertifikat separat gespeichert. Glücklicherweise liefert Step CA die Zertifikate derzeit mit den Extended-Key-Usage-(EKU)-Einstellungen für TLS-Client- und TLS-Server-Authentifikation aus. Das war ein Grund, warum wir eine Alternative zu Let's Encrypt erwogen haben. Das müssten Sie auch nur dann ändern, wenn die Entwickler diese Standardeinstellung zukünftig ändern sollten, oder wenn Sie selbst explizit den Zweck festlegen möchten. Die EKU lässt sich dann über sogenannte Zertifikat-Templates konfigurieren, so stellen Sie etwa auch Zertifikate für digitale Signaturen aus. Mit den Vorlagen sind zudem weitere Einstellungen an Ihren Zertifikaten möglich, etwa um auch Intermediate-Zertifikate auszustellen.

Aufgrund der Abschaffung von TLS-Clientzertifikaten durch Let's Encrypt stehen manche Admins vor altbekannten Problemen. Mit Step CA stellt Ihnen der Security-Tipp in diesem Monat eine Art selbst gehostetes Let's Encrypt vor und bereitet die CA für den produktiven Einsatz mit Ihnen vor. Auch wenn Step CA technisch relativ einfach aufzusetzen ist, müssen Sie den Dienst natürlich wie eine kritische Infrastruktur in Ihrem Unternehmen behandeln. Server und Clients authentifizieren sich mit den ausgestellten Zertifikaten gegenseitig und ein Angreifer mit Zugriff auf die CA erhielte weitreichende Möglichkeiten in Ihrem Netzwerk.

Natürlich sollten Sie die CA aus diesem Grund auch in Ihrer Backupstrategie berücksichtigen, das Root-Zertifikat bestenfalls aus dem Container lösen und offline speichern. Das bereits installierte Intermediate-Zertifikat übernimmt ja die Signatur der neuen Zertifikate. So verhindern Sie hoffentlich das notwendige Ausrollen eines neuen Root-CA-Zertifikats, was ja doch einen gewissen Aufwand in größeren Infrastrukturen verursacht.