EST einfach erklärt: Zertifikate über HTTPS anfordern und erneuern

SCEP hat Geräte-Zertifikate automatisiert, schleppt aber Altlasten mit: eigene Verschlüsselung über HTTP und ein schwaches Challenge-Passwort. Sein Nachfolger heißt EST, Enrollment over Secure Transport, und ist seit Oktober 2013 als RFC 7030 standardisiert. EST nutzt einfach TLS verschlüsselte Verbindung. Erkennbar am Schloss-Symbol im Browser.">HTTPS, kennt saubere Erneuerung mit dem alten Zertifikat und kann auf Wunsch den Schlüssel auf dem Server erzeugen. Dieser Artikel erklärt die Endpunkte, die Anmeldung am Server, den Ablauf einer Erneuerung und wo EST eingesetzt wird.

Die Idee: HTTPS statt Eigenbau

SCEP verschlüsselt jede Nachricht selbst, weil Geräte um das Jahr 2000 oft kein TLS konnten; mehr dazu in SCEP einfach erklärt. EST überlässt den Schutz der Verbindung TLS, also derselben Technik wie bei HTTPS; siehe Wie funktioniert HTTPS?. Das hat drei Vorteile:

Der Server weist sich aus: Der Client prüft das TLS-Zertifikat des EST-Servers, bevor er etwas sendet.
Der Client kann sich ausweisen: mit einem vorhandenen Zertifikat (wie bei Mutual TLS) oder mit Benutzername und Passwort.
Bekannte Werkzeuge: Webserver, Load Balancer und Bibliotheken für TLS gibt es überall.

Zwei Spalten: SCEP nutzt HTTP mit eigener Verschlüsselung und Challenge-Passwort, EST nutzt HTTPS, der Server weist sich per TLS aus und der Client meldet sich mit Zertifikat oder Passwort an. — Was EST gegenüber SCEP verbessert.

Die Endpunkte von EST

Alle Aufrufe liegen unter einem festen Pfad, /.well-known/est/. Die wichtigsten Operationen:

cacerts: liefert die aktuellen CA-Zertifikate. Damit lernt ein neues Gerät, welcher CA es vertrauen soll.
simpleenroll: erster Antrag. Der Client schickt einen CSR im Format PKCS#10 per POST und erhält das Zertifikat.
simplereenroll: Erneuerung. Der Client meldet sich mit seinem noch gültigen Zertifikat an und schickt einen neuen CSR.
csrattrs: Der Server sagt, welche Felder und Algorithmen er im CSR erwartet, etwa eine bestimmte Kurve.
serverkeygen: Der Server erzeugt das Schlüsselpaar und liefert Schlüssel und Zertifikat zurück. Das ist nützlich für sehr einfache Geräte oder wenn der Schlüssel für eine Wiederherstellung hinterlegt werden muss.
fullcmc: volle Anträge im Format CMC (RFC 5272) für komplexe Fälle; selten genutzt.

Die Antworten sind base64-kodierte PKCS#7-Container. So holt man die CA-Zertifikate und zeigt sie an (Servername als Beispiel):

curl https://est.beispiel.de/.well-known/est/cacerts -o cacerts.b64
openssl base64 -d -in cacerts.b64 | openssl pkcs7 -inform DER -print_certs

Den Container-Typ erklärt Zertifikatsformate einfach erklärt. Ein Antrag ist ebenso schlicht:

curl --cacert ca.pem --user geraet17:Einmalpasswort --data-binary @antrag.b64 -H "Content-Type: application/pkcs10" https://est.beispiel.de/.well-known/est/simpleenroll -o zertifikat.b64

Sechs Zeilen mit den EST-Endpunkten cacerts, simpleenroll, simplereenroll, csrattrs, serverkeygen und fullcmc und ihrer Aufgabe. — Die sechs Operationen von EST nach RFC 7030.

Wer darf ein Zertifikat beantragen?

EST trennt zwei Fragen sauber: Wer ist der Server, und wer ist der Client? Den Server prüft der Client über TLS. Für den Client sieht RFC 7030 zwei Wege vor:

Zertifikat: Ein Gerät, das schon ein Zertifikat hat, meldet sich damit an. Das kann ein Herstellerzertifikat aus der Fabrik sein, mehr dazu im Beitrag über Geräteidentität im IoT, oder das bisherige Zertifikat bei einer Erneuerung.
Passwort: HTTP-Anmeldung mit Benutzername und Passwort, idealerweise ein Einmal-Passwort pro Gerät.

Ein Kniff verhindert, dass ein Angreifer einen fremden CSR durch seine eigene, angemeldete Verbindung schleust: Der Client kann einen Wert aus der TLS-Sitzung (tls-unique) als Challenge-Passwort in den CSR schreiben. Der Server sieht dann, dass CSR und Verbindung zusammengehören. Außerdem kann der Server einen Antrag zunächst mit dem HTTP-Status 202 beantworten und den Client später wiederkommen lassen, wenn ein Mensch freigeben muss.

Erneuern mit simplereenroll

Die eigentliche Stärke von EST ist die Erneuerung. Das Gerät meldet sich mit seinem alten Zertifikat per TLS an, erzeugt ein neues Schlüsselpaar und schickt einen neuen CSR mit demselben Namen. Es braucht kein neues Passwort und keinen Menschen. Ein Beispiel: Bei einer Laufzeit von 365 Tagen und Erneuerung nach 80 Prozent der Zeit tauscht das Gerät sein Zertifikat nach 292 Tagen. Läuft ein Zertifikat trotzdem ab, kann es sich damit nicht mehr anmelden und braucht wieder ein Passwort oder einen Administrator. Wie wichtig rechtzeitige Erneuerung ist, zeigt Zertifikatsmanagement einfach erklärt.

Zeitleiste über 365 Tage: Bei Tag 292, nach 80 Prozent der Laufzeit, erneuert das Gerät per simplereenroll und erhält ein neues Zertifikat, bevor das alte abläuft. — Rechenbeispiel zur Erneuerung mit EST.

Wo EST eingesetzt wird

Netzwerkgeräte: Cisco und andere Hersteller unterstützen EST für Router, Switches und Zugangspunkte.
Internet der Dinge: Für sehr kleine Geräte gibt es die Variante EST-coaps (RFC 9148) über das schlanke Protokoll CoAP und DTLS.
Automatisches Onboarding: Das Verfahren BRSKI (RFC 8995) nutzt EST, damit ein neues Gerät mit seinem Herstellerzertifikat sicher ein Betreiberzertifikat bekommt.
CA-Software: EJBCA und viele kommerzielle PKI-Produkte bieten EST-Endpunkte; Cisco stellt mit libest eine freie Bibliothek für Client und Server bereit.

Im Vergleich: SCEP ist älter und weiter verbreitet, CMP kann mehr und wird in Industrie und Mobilfunk genutzt. Für Webserver mit öffentlichen Zertifikaten bleibt ACME der Standard.

Häufige Fragen

Ist EST sicherer als SCEP? In der Regel ja. TLS schützt die Verbindung und weist den Server aus, und das Gerät kann sich mit einem Zertifikat statt einem gemeinsamen Passwort anmelden.

Sollte ich serverkeygen nutzen? Nur wenn das Gerät selbst keine guten Schlüssel erzeugen kann oder eine Hinterlegung nötig ist. Sonst ist ein Schlüssel, der das Gerät nie verlässt, sicherer.

Was ist RFC 8951? Eine Klarstellung zu RFC 7030 aus dem Jahr 2020, die unter anderem die Kodierung der Antworten eindeutig regelt.

Ersetzt EST das ACME-Protokoll? Nein. ACME prüft die Kontrolle über eine Domain und ist für öffentliche Webzertifikate gemacht. EST richtet sich an Geräte in einer privaten PKI.

Fazit

EST bringt Geräte-Zertifikate auf ein solides Fundament: TLS schützt die Verbindung, der Client meldet sich mit Zertifikat oder Passwort an, und die Erneuerung läuft mit dem alten Zertifikat ohne menschliches Zutun. Mit sechs Endpunkten unter /.well-known/est/ ist das Protokoll überschaubar. Mehr in der Übersicht Verschlüsselung und IT-Sicherheit.