Bitte Namen eintragen

von Dr. Matthias Wübbeling

Das automatische Provisionieren von Geräten ist eine große Arbeitserleichterung für IT-Abteilungen. Das dafür notwendige Ausstellen und Verteilen von Zertifikaten unterstützen bereits seit vielen Jahren unterschiedliche Ansätze. Doch geht es um zahlreiche Geräte wie etwa in einem IoT, ist auch Automatisierung gefragt. Enrollment over Secure Transport führt diese Aufgabe sicher durch.

Digitale Zertifikate gibt es bereits seit den 1980er-Jahren. Der ursprünglich 1988 veröffentlichte X.509-Standard der ITU-T, einer Organisation der Vereinten Nationen, bestimmt auch heute noch deren Datenstruktur. Zertifikate sichern unsere digitale Kommunikation, unabhängig davon, ob Sie mit Ihrem Webserver im Internet surfen, E-Mails schreiben und versenden oder über eine definierte Schnittstelle mit Ihrer Bank kom- munizieren. Auch die Authentifikation von Geräten in kleinen und großen Netzwerken basiert seit Langem darauf.

Einfacher und sicherer

Je mehr Geräte und Services in einer Infrastruktur zum Einsatz kommen, desto komplexer gestalten sich Erstellen, Verteilen und Verwalten von Zertifikaten beim Provisioning. Dies gilt sowohl beim Betrieb einer eigenen Public Key Infrastructure (PKI) als auch bei der Nutzung einer entfernten CA. Eine Möglichkeit, das Ausstellen von Zertifikaten zu vereinfachen und zu automatisieren ist das Enrollment over Secure Transport (EST) [2].

EST wurde bereits 2013 als Protokoll für das Registrieren und Verwalten digitaler Zertifikate veröffentlicht. Es ist eine Weiterentwicklung älterer Protokolle, insbesondere im Hinblick auf Sicherheit und Flexibilität der genutzten Verfahren. EST erhöht dabei die Sicherheit in der Kommunikation und soll gleichzeitig die Komplexität für Entwickler und Administratoren reduzieren.

Vermutlich setzen Sie bereits an vielen Stellen Protokolle für die einfache Verteilung von Zertifikaten in Ihrem Unternehmen ein. Vor allem natürlich, wenn Sie eine sichere, automatisierte und skalierbare Administration von Zertifikaten auf Ihren Endgeräten anstreben. Benötigen Sie regelmäßig Client- und Serverzertifikate, können Sie dafür EST einsetzen. Nutzen Sie IoT-Geräte in Ihrem Unternehmen, verwenden die Hersteller in vielen Fällen bereits EST für das Ausstellen von Zertifikaten zur Authentifikation der Geräte im Netzwerk. So können Sie ohne großen Aufwand auch Tausende von Geräten sicher in Ihrer Infrastruktur miteinander verbinden.

Die Ursprünge automatischer Zertifikate

Bevor wir den praktischen Einsatz von EST besprechen, lohnt zunächst ein Blick in die Vergangenheit. Das automatisierte Ausstellen von Zertifikaten war schon vor der Jahrtausendwende ein Problem, dem unterschiedliche Protokolle begegneten. Eines der grundlegenden Protokolle ist das "Certificate Management over CMS" (CMC), das die allgemeine Kommunikation zwischen einer Zertifizierungsstelle und einer anfordernden Stelle, etwa einem Gerät oder einem Benutzer, definiert. Obwohl die Entwickler bereits seit 1998 an diesem Protokoll arbeiteten, veröffentlichten sie das resultierende RFC 5272 erst im Juni 2008.

Parallel dazu erfolgte die Entwicklung des "Internet X.509 Public Key Infrastructure Certificate Management Protocol" (CMP), das ein ähnliches Ziel mit einem noch etwas breiteren Ansatz verfolgt. Aufgrund der damals großen Relevanz wurden bereits beide Protokolle in Windows NT 4 und Windows 2000 implementiert, zum Teil in etwas rudimentären Varianten. Das CMP konnte sich dabei vor allem in industriellen Anwendungen etwas besser durchsetzen.

Der Nachfolger hat Sicherheitsprobleme

CMC und CMP sind sehr allgemeine Ansätze zum Management von Zertifikaten. Der Netzwerkausrüster Cisco und das aus der RSA Security gegründete Verisign entwickelten gemeinsam das spezifischere "Simple Certificate Enrollment Protocol" (SCEP). Auch dies begann um das Jahr 2000, die Fertigstellung des Protokolls als Veröffentlichung in RFC 8894 [1] erfolgte aber erst im September 2020. SCEP entwickelte sich von Beginn an rasant und wurde bereits viele Jahre vor der Veröffentlichung zum De-facto-Standard für die automatisierte Bereitstellung und Verwaltung digitaler Zertifikate. SCEP wird etwa für die Ausstellung von Zertifikaten für die Absicherung von Kommunikation über IPSec-Verbindungen genutzt.

Sind Sie in Ihrem Unternehmen verantwortlich für die Verwaltung mobiler Geräte, haben Sie SCEP vermutlich schon einmal eingesetzt. Es wird sowohl im Rahmen von Microsoft Intune als auch für Apples MDM verwendet. Die Microsoft-Implementierung mit dem Namen "Network Device Enrollment Service" wird dabei als Teil der Active Directory Certificate Services verwendet, um Geräte ohne Microsoft-Betriebssystem mit Zertifikaten aus der AD-PKI zu versorgen.

SCEP definiert einen einfachen, aber effektiven Ablauf: Ein Client generiert einen privaten Schlüssel und eine darauf basierende Zertifikatsignaturanforderung (CSR), die mittels definierter HTTP-Endpunkte an die CA gesendet wird. Der Server überprüft die Anforderung und signiert den in der CSR enthaltenen öffentlichen Schlüssel. Die CA gibt anschließend das resultierende Zertifikat als Antwort auf die Anfrage zurück an den Client.

Ein wesentlicher Vorteil von SCEP ist seine Einfachheit und die weit verbreitete Unterstützung, insbesondere in Netzwerken mit Cisco-Ausrüstung. Allerdings gibt es einige Kritik an SCEP, auch bezüglich der Sicherheit. Ein Einsatz von SCEP ist daher in modernen Sicherheitsumgebungen problematisch aufgrund der begrenzten Möglichkeiten zur sicheren Authentifizierung und der fehlenden Unterstützung moderner kryptografischer Algorithmen. Diese Kritik hat mit dazu geführt, dass EST als Alternativprotokoll entwickelt wurde.

Trotz der genannten Einschränkungen ist SCEP in vielen Organisationen immer noch im Einsatz, vor allem wegen seiner Einfachheit und der Tatsache, dass es eine zuverlässige Lösung für Umgebungen bietet, in denen komplexe Sicherheitsanforderungen nicht im Vordergrund stehen. Es eignet sich gut für die Verwaltung von Zertifikaten in mittelgroßen Netzwerken, in denen Benutzerfreundlichkeit und schnelle Bereitstellung wichtiger sind als fortschrittliche Sicherheitsfeatures.

Einfach mit dem Let’s-Encrypt-Protokoll

Auch wenn Ihnen die bisher genannten Protokolle vielleicht noch nicht über den Weg gelaufen sind, kennen Sie vermutlich das ACME-Protokoll ("Automatic Certificate Management Environment"). Das hauptsächlich von der Zertifizierungsinitiative Let’s Encrypt entwickelte Protokoll dient vor allem der Überprüfung von Berechtigungen und dem Ausstellen von Zertifikaten für Webserver.

Es definiert dafür den Ablauf der Zertifikatbeantragung, aber auch den Speicherort der in einer Challenge übermittelten Token, etwa direkt über den Webserver oder innerhalb des DNS-Eintrags zu einer Domain. Im Gegensatz zu den zuvor beschriebenen Protokollen geht es also vor allem um die Authentifikation bei der Ausstellung von Zertifikaten mittels Challenge-Response-Verfahren, was so in Unternehmensinfrastrukturen natürlich häufig nicht sinnvoll umsetzbar ist. Es ist vielleicht erwähnenswert, dass neben den Entwicklern der Electronic Frontier Foundation und von Let’s Encrypt auch im ACME-RFC 8555 ein Mitarbeiter von Cisco als einer der Hauptautoren gelistet ist.

Grundlegende Standards

Es würde den Rahmen dieses Artikels sprengen, alle relevanten Protokolle und Standards aus dem Bereich Certificate Enrollment zu diskutieren. Sie haben beim Lesen des Artikels vielleicht schon gemerkt, dass die Internetcommunity in den letzten 25 Jahren mitunter parallel Standards entwickelt hat, die sich zum Teil ausschließen oder aber eben auch ergänzen. Dennoch gibt es einige Standards, die fast durchgängig den anderen Protokollen zugrunde liegen. Das sind etwa jene von der ITU-T, einer Einrichtung der Vereinten Nationen, definierten x509-Standards, die z. B. den allgemeinen Aufbau von (x509)-Zertifikaten definieren.

Auch die ursprünglich von RSA Security veröffentlichten Public Key Cryptography Standards (PKCS) sind in den meisten Protokollen und Standards eine gesetzte Größe. Dabei handelt es sich ursprünglich um 15 unterschiedliche Standards, die aber zum Teil gar nicht fertiggestellt oder zwischenzeitlich in andere Standards aufgenommen wurden. Der Aufbau der bereits erwähnten Zertifikatsignaturanforderungen ist etwa als Teil des in RFC 2986 veröffentlichten "PKCS #10: Certification Request Syntax Specification" definiert. Auch die Antwort einer CA auf einen CSR, also das Zertifikat, ist in RFC 2315 "PKCS #7: Cryptographic Message Syntax" festgelegt und damit Bestandteil der relevanten Standards.

Wie Enrollment over Secure Transport arbeitet

Kommen wir zurück zur praktischen sicheren Verwaltung von Zertifikaten in einem Netzwerk. Bei der Entwicklung von EST ist auch wieder Cisco einer der führenden Akteure bei der Standardisierung. Als potenzieller Nachfolger von SCEP läuft die Arbeit an EST seit 2012 und das zugehörige, aktuelle RFC 7030 stammt aus dem Oktober 2013. Bereits in der Einleitung machen die Autoren des Standards deutlich, wie sie sich den Protokollstapel beim Einsatz von EST vorstellen. EST basiert auf einer mit TLS verschlüsselten HTTP-Verbindung (entspricht HTTPs). Damit ist die gesamte Kommunikation zwischen Client und Server vor dem Abhören, aber auch vor Manipulation der übermittelten Daten geschützt.

Ein wesentliches Merkmal adressiert einen der Hauptkritikpunkte an SCEP, die möglicherweise schwache Authentifikation der beteiligten Parteien allein über ein zuvor definiertes Shared-Secret. EST unterstützt daher starke Authentifizierungsmethoden, wie zum Beispiel Clientzertifikate oder Einmalpasswörter, die sicherstellen, dass nur autorisierte Clients Zertifikate anfordern können.

Ein EST-Client kann nun CSRs an eine CA senden, wobei entsprechend der Definition in PKCS #10 der öffentliche Schlüssel und andere Identifikationsinformationen als Teil des CSR übermittelt werden. Nach einer Legitimitätsprüfung der Anfrage durch die CA wird das signierte Zertifikat sicher an den Client zurückgesendet. EST unterstützt auch das automatische Erneuern vor dem Ablaufdatum des aktuell gültigen Zertifikats, was für die kontinuierliche Netzwerksicherheit relevant ist.

EST erlaubt ebenfalls, CA-Zertifikate und vollständige Zertifikatsketten bereitzustellen, was den Aufbau eines Vertrauensverhältnisses zwischen Clients und CA erleichtert. Dies ist besonders in komplexen Netzwerken wichtig, in denen mehrere Ebenen von Zertifikaten zum Einsatz kommen. Darüber hinaus umfasst EST Mechanismen für das Lebenszyklusmanagement von Zertifikaten, einschließlich der Möglichkeit, diese sicher zu widerrufen, wenn sie etwa nach einem Sicherheitsvorfall als kompromittiert gelten müssen oder auch, wenn sie zeitnah ablaufen.

EST für Testumgebungen

Cisco bietet für einen ersten Kontakt zu EST eine Referenzimplementierung für erste Tests auf Ihrem System. Diese finden Sie im entsprechenden Git-Repository [4]. Das Git-Repository ist leider nicht besonders gut gepflegt und daher nicht mit der aktuellsten Version der OpenSSL-Bibliothek kompilierbar. Es gibt zwar einen nicht bearbeiteten Pull-Request, den Sie manuell anwenden können, um einfach erst einmal einen Blick auf die Funktionsweise zu werfen, Sie benötigen das aber nicht. Vielmehr erstellen wir einen Docker-Container, der mit einer etwas älteren Version von OpenSSL ausgestattet ist, und kompilieren die libest darin (Listing 1).

Auf Basis des Dockerfiles aus Listing 1 erstellen Sie mit dem Kommando docker build . --tag est einen fertigen Container. Das dauert etwas: Wie Sie am ersten RUN-Kommando des Dockerfiles erkennen, installiert es zunächst die benötigten Tools (git, OpenSSL) und baut zudem eine entsprechende Build-Umgebung auf. Anschließend wird das Git-Repository heruntergeladen, die Softwarequellen mit "./configure" vorbereitet, kompiliert und installiert. Alle darauffolgenden Kommandos räumen wieder etwas auf, sodass Sie im Resultat ein nur 180 MByte großes Image erhalten (statt etwa 400 MByte). Dann erzeugt "createCA.sh" noch alle für eine CA relevanten Zertifikate und richtet die Zertifizierungsinstanz ein. Starten Sie nun den Server mit dem Kommando

Anschließend sehen Sie die Statusausgaben des Servers in Ihrer Konsole. Der nächste Schritt ist ein fiktiver Client, etwa ein IoT-Device in Ihrem Netzwerk, das Sie zum Ausbringen entsprechend vorbereiten. Um direkt mit dem Server innerhalb des Docker-Containers zu interagieren, öffnen Sie mit dem folgenden Kommando eine Shell in diesem Container

Dann wechseln Sie innerhalb des Containers in den Ordner" /libest/example/ client" und erstellen dort einen Ordner für die abgerufenen Zertifikate

Nun erzeugen Sie die Umgebungsvariable "EST_OPENSSL_CACERT" mit den CA-Cert-Daten des Servers zur Prüfung und können dann den EST-Client aufrufen und zunächst noch einmal die CA-Zertifikate des Servers abfragen. Das machen Sie mit der Option "-g", die Parameter "-s" und "-p" definieren den Servernamen beziehungsweise IP-Adresse und Port des Diensts. Mit "-o" geben Sie den Ausgabeordner "certs" und mit "--pem-output" weisen Sie den Client an, die Zertifikate Base64-codiert im PEM-Format zu speichern:

Das Zertifikat finden Sie nun im certs-Ordner. Damit sind die Voraussetzungen geschaffen, ein Clientzertifikat für das Gerät zu beantragen. Dafür erstellen Sie zunächst einen privaten Schlüssel und den dazugehörige CSR für den gewählten Gerätenamen, hier "iotdevice". Jetzt senden Sie die Anfrage an den EST-Server:

Über "-u" und "-h" geben Sie Benutzername und Passwort für die HTTP-Authentifikation beim EST-Server an. Die hier gewählten Werte dafür sind die Standardwerte aus dem libest-Repository. Als Output-Format wählen Sie wieder "PEM" und geben auch dem Server noch einmal den Namen des Geräts mit. Durch die Angabe von "-v" erhalten Sie zusätzlich Informationen in der Konsolenausgabe des Clients.

Im Bild sehen Sie die etwas gekürzte Konsolenausgabe des Servers. Hier erkennen Sie noch einmal den Namen des Geräts, aber auch die Laufzeit des Zertifikats. Der Standardwert von einem Jahr ist vermutlich für viele Infrastrukturen gut geeignet, lässt sich aber natürlich im EST-Server auch anpassen.

Selbstverständlich sollte sich das Gerät automatisch ein neues Zertifikat besorgen, wenn das alte kurz vor dem Ablauf steht. Für die Neuausstellung benötigen Sie nun keine HTTP-Credentials mehr, sondern geben das aktuell noch gültige Gerätezertifikat zur Authentifikation mit an:

Der Server erkennt bei dieser Anfrage, dass es sich um eine Neuausstellung handelt und akzeptiert das alte Clientzertifikat entsprechend.

EST produktiv nutzen

Natürlich eignet sich der von Cisco über die libest bereitgestellte Server schon allein aufgrund mangelnder Aktivität der Entwickler nur bedingt für den produktiven Einsatz. Nutzen Sie bereits Cisco-Geräte im Netzwerkmanagement, können Sie diese als Server für EST konfigurieren. Cisco liefert dafür eine sehr ausführliche Anleitung [5]. Hier bietet sich etwa der "Enterprise JavaBeans Certificate Authority" (EJBCA)-Server [6] von Keyfactor an. Diesen gibt es auch in einer kostenfreien Community-Edition, EST ist aber den Benutzern der Enterprise-Variante vorbehalten.

In EJBCA nehmen Sie unter "System Configuration / EST Configuration" die Einstellungen für den EST-Server vor. Hier müssen Sie sich vor allem entscheiden, ob Sie EST im Client- oder im RA-Modus (Registration Authority) betreiben. Der Clientmodus setzt insbesondere voraus, dass die Geräte bereits vorab im System registriert wurden und sich über ein Einmalpasswort oder ein auf dem Gerät installiertes Herstellerzertifikat authentifizieren. Der RA-Modus legt bei der Anfrage nach einem Zertifikat bei Bedarf einfach einen neuen Account für das entsprechende Gerät an und es findet im Grunde keine echte Kontrolle der zugelassenen Geräte statt. Die Entwickler von EJBCA empfehlen daher, den RA-Modus nicht zu verwenden.

Darüber hinaus konfigurieren Sie die Einstellungen der Zertifikaterstellung, Benutzernamen und Passwort für die Ausstellung und ob Sie das Re-Enrollment, wie zuvor gezeigt, mit dem ablaufenden Zertifikat erlauben möchten oder nicht. Natürlich können Sie, statt den Server selbst zu hosten auch die Angebote der Zertifikatdienstleister für Ihre Infrastruktur prüfen. So bieten etwa Globalsign [7] oder Digicert [8] umfassende Plattformen für das Management einer PKI an.

Das Anbinden an entsprechende Infrastrukturen, wie den "Azure IoT Hub" von Microsoft erfolgt dann über die jeweiligen Schnittstellen und Geräteverwaltungen. Die Voraussetzung dafür ist die Einrichtung eines Device Provisioning Services über das Azure-Portal [9]. Wählen Sie nun den "Provisioning Service" im Azure-Portal aus, können Sie unter "Einstellungen / Registrierungen verwalten" eine neue Registrierungsgruppe hinzufügen und dort unter "Bereitstellungen" die entsprechenden Settings für den EST-Server hinterlegen.

Fazit

Mit Enrollment over Secure Transport sichern IT-Verantwortliche die automatisierte Zertifikatausstellung zum Beispiel für IoT-Geräte in der Infrastruktur weiter ab. Sie können dafür selbst gehostete Software verwenden oder die benötigten Services bei Zertifikatsexperten einkaufen und beides etwa mit dem Azure-IoT-Device-Management verbinden.

Zertifikate verteilen mit Enrollment over Secure Transport

Bitte Namen eintragen

Einfacher und sicherer

Einfacher und sicherer

Die Ursprünge automatischer Zertifikate

Der Nachfolger hat Sicherheitsprobleme

Einfach mit dem Let’s-Encrypt-Protokoll

Grundlegende Standards

Wie Enrollment over Secure Transport arbeitet

EST für Testumgebungen

EST produktiv nutzen

Fazit