Serverzertifikate im Abonnement : Automatisierung mit ACME

Von Hans-Joachim Knobloch, Jannis Pinter, Karlsruhe

Die Serverzertifikate, die für das mittlerweile quasi obligatorische Transport-Layer-Security-Protokoll (TLS) benötigt werden, sind in vielen Augen der Pferdefuß bei dessen Einsatz. Auf der Beliebtheitsskala von Serveradministratoren rangiert die Einrichtung und Erneuerung von Zertifikaten nicht selten irgendwo zwischen Hardwareausfall und Backup-Fehler; bei ihren Teamleitern tauchen sie oft als ungeliebter, Manpower-verschlingender Posten auf. Ein Resultat sind dann unter anderem die scheinbar unausrottbaren Fehlermuster und Warnungen aufgrund abgelaufener oder für den Anwender nicht vertrauenswürdiger Zertifikate.

Der Aufwand für den Bezug von Serverzertifikaten und die dafür nötige Vorlaufzeit sind zum großen Teil den Anforderungen des CA/Browser-Forums (vgl. Kasten auf S. 67) an die Validierung von Anträgen für öffentlich gültige Serverzertifikate geschuldet [4,5]. Besonders für die höheren Zertifizierungsstufen OV und EV (vgl. Kasten unten) erfordert die vorgeschriebene Validierung der antragstellenden Organisation manuelle Schritte wie die Vorlage und Sichtung von Dokumenten und gegebenenfalls sogar telefonische Rückrufe. Demgegenüber können einige der zulässigen Validierungsmethoden für die Domaininhaberschaft, deren Nachweis für einfache DV-Zertifikate bereits ausreicht, auch automatisch ausgeführt werden.

Dies entspricht dann auch eher der üblichen Arbeitsweise beim Server-Management: Einmal korrekt eingerichtet, soll der Server soweit es geht ohne manuelle Eingriffe laufen. Bezogen auf Serverzertifikate bedeutet das: Es braucht ein Zertifikatsabonnement – zu jeder Zeit ein nutzbares und gültiges Serverzertifikat – anstelle eines einzelnen Zertifikats, für das man am besten schon bei seiner Einrichtung ein Wartungsfenster für die rechtzeitige Erneuerung einplanen muss.

Möglich wird dies seit einiger Zeit durch das ACME-Protokoll und öffentliche Trustcenter wie Let’s Encrypt, die anbieten, per ACME Zertifikate zu beziehen und zu erneuern. ACME steht dabei nicht wie in den Roadrunner-Cartoons für „American company that makes everything“, sondern für „Automatic Certificate Management Environment“ (bzw. ursprünglich „Automated …“).

Validierungsstufen für Zertifikate

Öffentlich gültige TLS-Serverzertifikate gibt es in drei Stufen, die sich darin unterscheiden, welche Informationen über den Zertifikatsinhaber im Zertifikat enthalten sind und wie sorgfältig diese Informationen vor der Ausstellung validiert werden. Abhängig von der Validierungsstufe zeigen die Browser dem Endanwender unterschiedliche Informationen an.

Bei Zertifikaten mit Domain-Validation (DV) sind nur der oder die Hostnamen des betreffenden Servers im Zertifikat enthalten. Der Antragsteller muss nachweisen, dass er die Verfügungsgewalt über die betreffende DNS-Domain beziehungsweise über die betroffenen Hostnamen hat. Der Browser zeigt an, dass eine sichere Verbindung besteht, aber keine weiteren Informationen.

Organization-Validated-(OV)-Zertifikate umfassen zusätzlich den Namen des Unternehmens oder der Organisation, die den Server betreibt, und meist auch Ort und Land, in dem diese Organisation ihren Sitz hat. Dies wird in der Regel über einen Eintrag im Handelsregister oder vergleichbaren Unternehmensregistern geprüft. Vom Browser werden Verbindungen, die über OV-Zertifikate gesichert sind, nicht anders angezeigt als bei DV-Zertifikaten. Hartnäckige Anwender können sich zwar über mehrere Klicks die Betreiberinformation aus dem Zertifikat anzeigen lassen, man kann jedoch getrost davon ausgehen, dass sich dies in der Praxis unterhalb des Promillebereichs bewegt.

Erst bei der Extended-Validation (EV) wird die Betreiberinformation wirklich gründlich geprüft, beispielsweise über einen Rückruf bei einem Geschäftsführer oder Prokuristen, der im Handelsregisterauszug genannt ist. Verwendet der Server ein EV-Zertifikat, zeigen die Browser das traditionell durch einen „grünen Balken“ an. In aktuellen Browserversionen handelt es sich dabei eher um die auffällig grüne Nennung des Serverbetreibers entweder direkt in der URL-Adresszeile oder nach einem Klick in ebendiese.

Der Weg zum Standard

Das ACME-Protokoll deckt die gesamte Transaktion eines Zertifikatsbezugs vom Antrag bei der Registration-Authority über die Domain-Validierung bis hin zum Abruf von Zertifikaten automatisiert ab. Anders als andere Enrollment-Protokolle löst ACME die für DV-Zertifikate benötigte Domain-Validierung „in band“, also als integralen Bestandteil des Protokolls. Mit dem Start von Let’s Encrypt wurde das ACME-Protokoll in Version 1 von der Internet Security Research Group ISRG veröffentlicht – der Dachorganisation von Let’s Encrypt. Der Nachfolgestandard ACMEv2 wurde im Rahmen der Internet Engineering Task Force (IETF) standardisiert und im März 2019 als RFC 8555 publiziert [1]. Der neue Standard bietet einige Vorzüge gegenüber ACMEv1 – neben der Verbesserung einiger Feinheiten im Protokoll lassen sich mit ACMEv2 beispielsweise auch Wildcard-Zertifikate beziehen.

Das CA/Browser-Forum

In den Urzeiten des World Wide Web sind die Browser recht hemdsärmelig damit umgegangen, wessen Serverzertifikate akzeptiert wurden. Erst gab es nur ein öffentliches Trustcenter, dessen Root-Zertifikat mit ausgeliefert wurde. Dann war man froh, dass sich ein Mitbewerber fand, um keinen Ärger mit den Anti-KartellBehörden zu riskieren.

Das änderte sich im Laufe der Zeit, als immer mehr Aspiranten sich meldeten, und so fand sich 2005 das CA/Browser-Forum zusammen, ein informeller Zusammenschluss (laut Satzung „voluntary gathering“), der seither die Spielregeln für die Aufnahme öffentlicher Trustcenter-Zertifikate in die verbreiteten Browser festlegt und durchsetzt.

Mitglieder sind auf der einen Seite die führenden Betriebssystem- und Browser-Hersteller, unter anderem Apple, Google, Microsoft und die Mozilla Foundation. Auf der anderen Seite sind circa 70 bis 80 öffentliche Trustcenter dort vertreten, deren Zusammensetzung gelegentlich aufgrund von Marktbewegungen etwas variiert.

Die wichtigsten, immer wieder aktualisierten Dokumente des CA/Browser-Forums sind die „Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates“ [4] und die ergänzenden „EV SSL Certificate Guidelines“ [5] für EV-Zertifikate. In den Kapiteln 3.2.2.4.6, 3.2.2.4.7 und 3.2.2.4.10 der Baseline-Requirements sind die automatisierbaren Methoden für die Domain-Validierung geregelt, die in ACME genutzt werden – quasi die Geschäftsgrundlage des Protokolls.

Funktionsweise von ACME

Um ein TLS-Serverzertifikat über das ACME-Protokoll beziehen zu können, benötigt man eine Clientsoftware, die zunächst ein Schlüsselpaar erzeugt (typischerweise RSA 2048 Bit), um die nachfolgende Kommunikation mit dem ACME-Server der Zertifizierungsstelle kryptografisch zu signieren. Der Nachrichtentransport erfolgt im JSON-Format über HTTPS, wobei die einzelnen Nachrichten mit JSON Web Signatures (JWS, [2]) und dem zu Beginn erzeugten Schlüssel signiert werden.

Danach erstellt die Clientsoftware einmalig ein Konto bei der Zertifizierungsstelle. Dazu wird eine Kontaktadresse des Administrators abgefragt, welche bei der Kontoregistrierung der Certification-Authority (CA) des Trustcenters mitgeteilt wird. Die Clientsoftware reicht die Registrierungsnachricht dann mit ihrem zuvor generierten öffentlichen JWS-Schlüssel und den Kontaktinformationen bei der Zertifizierungsstelle ein.

Nun kann die Client-Software mit der Beantragung eines Zertifikats beginnen: Dazu reicht sie eine signierte Zertifikats-Bestellung bei der Zertifizierungsstelle ein. Die Bestellung umfasst alle Domainnamen, die später im Zertifikat enthalten sein sollen. Als Antwort erhält der Client für jeden beantragten Domainnamen eine Liste mit Challenges, wovon er mindestens eine pro Domainnamen erfolgreich lösen muss, um die Kontrolle über den Domainnamen nachzuweisen (Domain-Validation).

Zentrales Element: das Challenge-Verfahren

Das Protokoll selbst definiert zwei mögliche Challenges: ein auf HTTP aufsetzendes Verfahren und ein Verfahren, das auf DNS beruht.

Das HTTP-basierte Verfahren sieht vor, dass der Antragssteller auf dem Webserver unter dem Pfad /.well-known/acme-challenge/ eine Datei mit einem von der CA vorgegebenen Namen und Inhalt (Token) publiziert. Kann die CA diese Datei dann abrufen, gilt die Challenge als gelöst und die Domainvalidierung für diesen Domainnamen als erfolgreich durchgeführt. Zur Sicherheit versucht die CA diese Datei von mehreren weltweit verteilten Standorten abzurufen, um das Restrisiko durch Angriffe auf das Border-Gateway-Protocol (BGP) zu minimieren.

Das alternative, auf DNS aufsetzende Verfahren ist das einzige, das optional den Bezug von Wildcard-Zertifikaten erlaubt. Dabei muss der Client für die zu validierende Domain einen TXT-Eintrag unter der Subdomain _acme-challenge erstellen und darin ähnlich wie beim HTTP-basierten Verfahren einen von der CA vorgegebenen Token-Wert hinterlegen. Kann die CA diesen Wert über das DNS abrufen, gilt die Challenge als gelöst und die Domainvalidierung als erfolgreich durchgeführt.

Ursprünglich war noch ein weiteres Verfahren auf der Basis von Server-Name-Indication (SNI) definiert, das den Vorteil besaß, dass eine Validierung über HTTPS erfolgen konnte. Server, die nur über HTTPS, aber nicht über HTTP erreichbar waren, konnten also mit diesem Verfahren Zertifikate per ACME erhalten. Später stellte sich jedoch heraus, dass man dieses Verfahren auf manchen Shared-Hosting-Umgebungen austricksen konnte, um Zertifikate für fremde Domainnamen zu erhalten, die sich denselben Server teilten. Das SNI-basierte Verfahren wurde daher in der RFC-Version aus dem Protokoll entfernt.

Als Ersatz dafür wurde ein auf Application-Layer-Protocol-Negotiation (ALPN) aufsetzendes Challenge-Verfahren entworfen, das sich seit Juli 2018 bei Let’s Encrypt nutzen lässt. Die Standardisierung dieses Verfahrens läuft allerdings noch – die neueste Spezifikation liegt als eigenständiger Internet-Draft vor, der später RFC 8555 ergänzen soll [3].

Finalisierung der ACME-Transaktion

Zum Abschluss der Zertifikatsbeantragung kann die Client-Software einen PKCS#10 Certificate Signing Request mit den beantragten Domainnamen einreichen und im Erfolgsfall wenig später das frisch von der CA ausgestellte Serverzertifikat samt Zertifikatskette herunterladen.

Das Protokoll unterscheidet dabei nicht zwischen Erstbezug und Erneuerung eines Zertifikats. Auch für eine Erneuerung (mit oder ohne Schlüsselwechsel) muss eine neue Bestellung eingereicht und in der Regel auch eine erneute Domain-Validierung durchgeführt werden. In manchen Fällen kann die Zertifizierungsstelle aber auf die Domain-Validierung verzichten, beispielsweise wenn derselbe Client – identifiziert durch sein JWS-Schlüsselpaar – erneut ein Zertifikat mit einem bereits kürzlich validierten Domainnamen beantragt.

Optionen und Besonderheiten

ACME bietet aber noch weitere Möglichkeiten, die bisher kaum genutzt werden: So sieht das Protokoll einen Mechanismus vor, um maschinell erstellte ACME-Konten mit einem Firmenkonto bei der Registrierungsstelle zu verknüpfen. Dieses Verfahren nennt sich External-Account-Binding und kann beispielsweise dazu dienen, um auch OV- oder gar EV-Zertifikate automatisiert zu beziehen, sofern das entsprechende Validierungsprozedere für die Organisationsangaben zuvor einmal bei der Registrierungsstelle durchlaufen wurde. Bisher wird dies aber noch von keinem Trustcenter angeboten.

Auch das Sperren von Zertifikaten ist über das Protokoll möglich. Dabei muss ein ACME-Client entweder den Besitz des zugehörigen geheimen Schlüssels nachweisen oder den signierten Sperrantrag mit dem gleichen ACME-Client (identifiziert durch sein JWS-Schlüsselpaar) einreichen. Alternativ kann ein ACME-Client auch eine Domain-Validierung für alle im zu sperrenden Zertifikat aufgeführten Domainnamen durchführen und dann eine Sperrung dafür beantragen. Im Falle von Let’s Encrypt wird das Zertifikat dann in aller Regel innerhalb weniger Sekunden gesperrt.

ACME-Unterstützung in der Praxis

Clientsoftware, mit der sich Zertifikate von Let’s Encrypt und anderen Zertifizierungsstellen beziehen lassen, gibt es zu Dutzenden in verschiedenen Programmiersprachen sowie für verschiedene Plattformen und Einsatzzwecke. Besonders populär sind der von der Electronic Frontier Foundation (EFF) entwickelte Certbot (https://certbot.eff.org) sowie die reinen Shell-Implementierungen acme.sh (https://acme.sh) und dehydrated (https://dehydrated.io). Letztere erfreuen sich zunehmender Beliebtheit, da sie keine großen Abhängigkeiten zu Softwarepaketen wie Python haben und in vielen Szenarien auch ohne die Root-Rechte des Server-Administrators ausgeführt werden können.

Die TLS-Zertifikate von Let’s Encrypt sind 90 Tage lang gültig und damit deutlich kürzer als bei den meisten anderen öffentlichen Trustcentern. Allerdings erfolgen der Zertifikatsbezug und die Zertifikatserneuerung vollständig automatisiert im „Zertifikats-Abo“, wodurch die geringe Gültigkeitsdauer in der Praxis keine negativen Effekte hat. Im Gegenteil wird dadurch sogar das Restrisiko durch eine im Fall des Falles eventuell unterbliebene Zertifikatssperrung zeitlich begrenzt.

Neben Let’s Encrypt bietet das norwegische Trustcenter Buypass mit Buypass Go ebenfalls kostenfreie, öffentlich gültige Zertifikate über ACME an (www.buypass.com/ssl/de/products/acme), die 180 Tage gültig sind. Auch weitere Anbieter erkennen zunehmend die Vorteile des Protokolls: So wurde eine ACME-Schnittstelle in die Enterprise-Variante der PrimeKey CA-Software (EJBCA) integriert. Und das kommerzielle Trustcenter GlobalSign hat sein „Auto Enrollment Gateway“ ebenfalls mit einer ACME-Schnittstelle ausgestattet, um kostenpflichtige Serverzertifikate und solche von einer Managed-PKI einfach und automatisiert durch Linux-Server abrufbar zu machen.

Das ACME-Protokoll ist also keineswegs mehr an Let’s Encrypt gebunden – allerdings sind immer noch viele ACME-Clients mit Let’s Encrypt „hart verdrahtet“. Plant man den Einsatz von ACME, sollte man daher bedenken, dass nicht jede Clientsoftware geeignet ist, Zertifikate von anderen Zertifizierungsstellen zu beziehen oder dass dafür Änderungen am Quellcode erforderlich sein können.

Einsatz für interne Server

Auch in internen Netzen wird aufgrund von Vorgaben des Sicherheitsmanagements oder wegen Complianceanforderungen immer häufiger TLS eingesetzt (bspw. für Intranet-Server, Datenbankverbindungen oder in Webservice-basierten Anwendungen).

Wer nun eine eigene PublicKey-Infrastructure (PKI) betreibt, um (auch) TLS-Serverzertifikate für seine internen Server zu betreiben, steht meist vor einer Zwickmühle zwischen Effizienz und Vertrauenswürdigkeit: Entweder man handhabt den Antragsprozess recht lax und stellt für alle potenziellen Server-Administratoren jedes beantragte Zertifikat mit beliebigen plausiblen Servernamen ohne Weiteres aus – auch auf das Risiko hin, dass ein schwarzes Schaf darunter fehlerhaft oder missbräuchlich gültige Zertifikate erhalten kann. Oder es ist ein manueller Prüfprozess erforderlich, an dem sowohl der Server-Administrator als Antragsteller als auch ein PKI-Administrator als prüfender Certificate-Manager beteiligt sind.

Theoretisch wäre es zwar möglich, die Prüfung, welcher Mitarbeiter gerade für welche Server zuständig ist und somit Zertifikate für die betreffenden Servernamen beantragen darf, anhand von Einträgen in einer Configuration-Management-Database (CMDB) oder einer ähnlichen Datenquelle automatisiert durchzuführen. In der Praxis zeigt sich jedoch leider häufig, dass der Erfassungsgrad und die Datenqualität in solchen Quellen dafür nicht ausreichen. Zudem wird von vielen CA-Produkten ein derartiger Abgleich mit einer Datenquelle jenseits des Active Directory (AD) technisch nicht unterstützt.

Im Vergleich dazu bringt die Zertifikatsbeantragung und -erneuerung per ACME mit der eingebauten Domainvalidierung, die den Ansprüchen an öffentlich gültige Zertifikate genügt, Sicherheit und Effizienz wesentlich besser auf einen Nenner. Was läge also näher, als ACME auch für das Management von Zertifikaten interner Server zu verwenden? Dazu müsste allerdings in vielen existierenden PKIs eine zusätzliche Issuing-CA unter Verwendung eines der noch rar gesäten ACME-kompatiblen CA-Produkte eingerichtet werden.

All diejenigen, die in ihrem internen Netz öffentlich registrierte DNS-Namen verwenden (und nicht z. B. eine „.local“-Domain) können jedoch als Joker öffentlich gültige DV-Zertifikate auch für interne Server verwenden. Diese Zertifikate werden dank des mit Browsern und Betriebssystemen vorinstallierten Root-Zertifikats dann auch in praktisch allen internen Netzen als vertrauenswürdig anerkannt – ohne dass man vorab flächendeckend das Root-Zertifikat einer internen PKI verteilen müsste. Dies ist dank Trustcentern wie Let’s Encrypt oder Buypass Go sogar gebührenfrei möglich.

Proxy und Split-DNS

Der direkten Nutzung eines ACME-Clients auf einem internen Server stehen jedoch meist Firewall-Regeln und Netzwerk-Policies im Weg, sodass die Domain-Validierung durch das Trustcenter von außen und damit der Bezug eines Zertifikats fehlschlägt. Diese Lücke kann ein Enrollment-Gateway in einer DMZ schließen, das als ACME-Proxy fungiert: Damit das externe Trustcenter zur Domain-Validierung beim Enrollment-Gateway anfragt, müssen interne Servernamen allerdings in einer sogenannten Split-DNS-Konfiguration im Internet auf das Enrollment-Gateway verweisen.

Von Split-DNS spricht man, wenn DNS-Anfragen im internen Netz zu anderen Auskünften führen als die gleiche DNS-Anfrage aus dem Internet heraus. Im hier betrachteten Fall muss der interne DNS bei einer Anfrage nach einem internen Server auf dessen tatsächliche interne DNS-Adresse verweisen – der DNS, der Anfragen aus dem Internet beantwortet, jedoch auf die vom Internet aus erreichbare IP-Adresse des Enrollment-Gateways.

In dieser Konstellation finden dann zwei separate, wenn auch miteinander verschachtelte ACME-Transaktionen statt: eine zwischen dem internen Server und dem Enrollment-Gateway und eine zweite zwischen dem Enrollment-Gateway und dem externen Trustcenter.

Konkreter führt zunächst das Enrollment-Gateway die Domain-Validierung der Zertifikatsanfrage vom internen Server her durch. Im Erfolgsfall reicht es dann den Antrag über eine eigene ACME-Transaktion als Client an das externe Trustcenter weiter und löst stellvertretend dessen HTTP-Challenge für die externe Domain-Validierung des internen Servernamens. Das erhaltene Serverzertifikat wird zum Abschluss an den internen ACME-Client weitergereicht.

Auf diese Weise wird das Management von TLS-Serverzertifikaten für interne Server genauso sicher, effizient und automatisiert, wie dies dank ACME und Let’s Encrypt vielerorts bereits für Server im Internet umgesetzt ist.

Dipl.-Inf. Hans-Joachim Knobloch und B. Sc. Jannis Pinter sind Security-Consultants bei der Secorvo Security Consulting GmbH.

Literatur

[1] R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten, Automatic Certificate Management Environment (ACME), RFC 8555, März 2019, www.ietf.org/rfc/rfc8555.txt
[2] M. Jones, J. Bradley, N. Sakimura, JSON Web Signature (JWS), RFC 7515, Mai 2015, www.ietf.org/rfc/rfc7515.txt
[3] R. Shoemaker, ACME TLS ALPN Challenge Extension, Internet Draft, August 2018, https://tools.ietf.org/html/draft-ietf-acme-tls-alpn-05
[4] CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, Version 1.6.5, 16. April 2019, https://cabforum.org/baseline-requirements-documents/
[5] CA/Browser Forum, Guidelines For The Issuance And Management Of Extended Validation Certificates, Version 1.7.0, 21. Juni 2019, https://cabforum.org/extendedvalidation/