ACME jenseits des Webservers: Zertifikatsautomatisierung für interne Dienste und mTLS

Die Verkürzung öffentlicher TLS-Laufzeiten auf perspektivisch 47 Tage hat ein Bewusstsein dafür geschaffen, dass manuelle Erneuerung nicht mehr skaliert. Was dabei oft übersehen wird: Im Inneren eines Unternehmens stecken meist deutlich mehr Zertifikate als an der nach außen sichtbaren Kante. Service-zu-Service-Kommunikation, mTLS in einem Service-Mesh, interne APIs und Datenbankverbindungen leben alle von Zertifikaten, und diese folgen anderen Mustern als das öffentliche Web.

Warum „intern" nicht „einfacher" heißt

Am öffentlichen Webserver ist die Lage übersichtlich: eine Handvoll Domains, eine öffentliche CA, ein klar definierter Validierungsweg. Im Inneren kehrt sich das Verhältnis um. Hier gibt es oft hunderte oder tausende kurzlebiger Endpunkte, die dynamisch entstehen und vergehen, etwa wenn ein Orchestrator neue Container startet. Eine interne CA stellt für sie Zertifikate aus, die niemand öffentlich sieht, die aber genauso ablaufen, sich genauso erneuern müssen und im Fehlerfall genauso einen Dienst lahmlegen.

Der Unterschied zur öffentlichen Welt ist also nicht geringere Bedeutung, sondern höhere Frequenz und Dynamik. Bei mTLS, wo sich beide Seiten gegenseitig mit einem Zertifikat ausweisen, verdoppelt sich die Zahl der zu verwaltenden Identitäten zusätzlich.

ACME ist nicht nur für Let’s Encrypt

ACME (RFC 8555) ist als Protokoll für die automatische Ausstellung und Erneuerung bekannt geworden, vor allem über Let’s Encrypt im öffentlichen Web. Das Protokoll selbst ist aber CA-agnostisch. Eine interne CA kann eine ACME-Schnittstelle anbieten, und dann erneuern sich interne Dienste nach demselben Mechanismus selbst, ohne dass jemand ein Zertifikat von Hand bestellt.

Für die interne Validierung greifen dabei andere Challenge-Typen als im öffentlichen Web. Die HTTP-Challenge, die für öffentliche Domains üblich ist, passt selten zu internen Diensten. Stattdessen kommen DNS-basierte Verfahren oder, je nach Umgebung, an die Plattform gebundene Identitätsnachweise zum Zug. Service-Meshes lösen das teils intern über eine eigene Identitätsschicht und kurzlebige Zertifikate mit Lebensdauern von Stunden statt Wochen.

Was den Unterschied macht

Drei Fähigkeiten entscheiden darüber, ob interne Automatisierung trägt.

Discovery auch nach innen. Der gefährliche Ausfall ist selten das gepflegte Frontend-Zertifikat. Es ist das vergessene Zertifikat auf einem internen Dienst, einer Appliance oder in einem Cluster, den niemand mehr aktiv beobachtet. Ein Inventar muss interne Endpunkte ebenso erfassen wie öffentliche.

Eine CA-agnostische Sicht. In gewachsenen Umgebungen existieren meist mehrere CAs nebeneinander: eine öffentliche für die Außenkante, eine oder mehrere interne, dazu vielleicht eine Cloud-eigene. Eine Verwaltung, die über alle hinweg einen einheitlichen Blick und einheitliche Erneuerung bietet, verhindert, dass jede CA ihre eigene Insel mit eigenen Lücken wird.

Erneuerung mit Kontrolle. Vollautomatik ist das Ziel, aber nicht um den Preis verlorener Nachvollziehbarkeit. Wo es nötig ist, gehört zum automatischen Renewal ein dokumentierter Genehmigungs- und Protokollschritt, damit auch bei hoher Frequenz nachvollziehbar bleibt, was wann ausgestellt wurde.

Genau dieses Muster, Discovery zuerst, dann CA-agnostische Automatisierung mit Approval, liegt unserem Modul NextPKI zugrunde. Die Stoßrichtung gilt jedoch unabhängig vom Werkzeug: Wer die kurzen Laufzeiten der Außenkante beherrscht, aber das Innere übersieht, hat das eigentliche Volumen nicht im Griff.

Die 47-Tage-Diskussion ist ein guter Anlass, den Blick zu weiten. Die meisten Zertifikate eines Unternehmens stehen nicht im Schaufenster, sondern im Maschinenraum.