Erleuchtete Immatrikulation: Das Buch der fünf Zertifikatseinschreibungsprotokolle

In diesem Blogbeitrag wird Mike Agrenius Kushner in seiner Rolle als Produktarchitekt einen Leitfaden für Laien zum PKI-Enrollment über API und fünf der heute von EJBCA unterstützten Protokolle vorstellen. 

Erinnern Sie sich, wenn Sie dabei waren, an Ihren ersten Tag an der Universität. Der erste Akt bestand darin, zu einem Schreibtisch zu gehen und auf Ihren Namen in einem Buch zu zeigen, woraufhin Ihnen ein fadenscheiniges Stück Papier mit einem Benutzernamen (basierend auf einer wahrscheinlich peinlichen Verkürzung der Buchstaben Ihres Namens) und einem automatisch generierten Passwort (das Sie irgendwann nach Bestehen des Kurses in Differentialtransformation im dritten Jahr ändern durften) ausgehändigt wurde. Dieser ganze Vorgang wurde Immatrikulation genannt.

Dies entspricht in etwa der ersten Phase des Lebenszyklus eines Zertifikats, in der der Inhaber eines Schlüssels sich und seine Anmeldedaten bei einer Zertifizierungsstelle vorstellt, die ihm dann ein Zertifikat ausstellt, mit dem er sich auszeichnen kann. Wir alle haben die Registrierung mit Hilfe von Certificate Signing Requests (CSRs) und deren manuelle Übermittlung an verschiedene Tools und Anwendungen über command Zeilen, Skripte oder vielleicht sogar eine Benutzeroberfläche durchgeführt. Die wahre Magie geschieht dann, wenn Sie Ihr Gerät sich völlig selbständig anmelden lassen können. Wenn Sie wirklich Glück hatten, haben Sie nicht einmal gemerkt, dass es passiert ist.

In diesem Blogbeitrag werden wir uns fünf der von EJBCA unterstützten Anmeldeprotokolle ansehen: ACME, SCEP, CMP, EST und unsere eigene REST-API-Suite . Wir befassen uns mit der Geschichte jedes Protokolls, den Vor- und Nachteilen und der Frage, wo Sie sie einsetzen können. In diesem Blog werden wir die automatische Registrierung von Microsoft als einen völlig anderen Anwendungsfall behandeln.

Das Certificate Management Protocol (CMP) ist das älteste der von EJBCA unterstützten Protokolle. Es wurde erstmals 1996 entworfen, erreichte 1999 mit RFC 2510 RFC-Status und 2005 mit RFC 4210 CMPv2 seinen aktuellen Stand.

Als Protokoll ist CMP zweifellos in die Jahre gekommen, sowohl in Bezug auf das Design als auch auf die ungerechtfertigte Komplexität, die zum Teil darauf zurückzuführen ist, dass die PKI zum Zeitpunkt der Entwicklung noch im Entstehen begriffen war. Die Komplexität (und in einigen Fällen Unklarheit) des RFC bedeutet, dass verschiedene Server- und Client-Implementierungen in den Feinheiten abweichen können und dies auch tun.

Die größte Stärke von CMP ist daher auch seine größte Schwäche - dass es eines der umfassendsten Protokolle ist, was die verfügbaren Operationen und verschiedenen Permutationen angeht. Dies führt auch dazu, dass es nur wenige Clients gibt, die den Anspruch erheben, alle Funktionen von RFC 4210 zu unterstützen.

Dieses Alter und diese Widerstandsfähigkeit bedeuten auch, dass CMP als Protokoll nicht auf viele Technologie-Stacks angewiesen ist. Es kann über HTTP, TCP oder auch Brieftaube gesendet werden.

Einer der Hauptaspekte, der CMP heute relevant macht, ist das 3GPP LTE-Framework, das ursprünglich für und von der Telekommunikationsbranche entwickelt wurde und CMP um die Unterstützung von Herstellerzertifikaten erweitert. Dadurch kann ein Hersteller ein Gerät mit einem signierten Zertifikat seiner eigenen Zertifizierungsstelle ausstatten. Dieses Zertifikat kann dann von einem Endgerätebenutzer angeboten werden, um sich bei seiner PKI anzumelden.CMP ist auch in anderen Branchen von Bedeutung. Ein weiteres Beispiel sind Eisenbahnnetze, wo CMP als Standardprotokoll für ERTMS-Systeme definiert ist.

Wenn Sie sich mit EJBCA und CMP vertraut machen möchten, kann ich Ihnen diesen Abschnitt aus dem Video PKI at the Edge für die Keyfactor Community empfehlen.

+ Wenn Sie ein Protokoll mit einer vollständigen Reihe von Operationen benötigen

+ Sie sind ein Telekommunikationshersteller oder eine andere Person in einer Branche, die auf 3GPP angewiesen ist.

- Sie sind nicht bereit, einen komplexen Client zu pflegen, der möglicherweise die verschiedenen RFC-Auffassungen der verschiedenen CA-Anbieter berücksichtigen muss.

Fast so alt wie CMP ist das Simple Certificate Enrollment Protocol, dessen erster Entwurf bereits im Jahr 2000 veröffentlicht wurde. Im Gegensatz zu CMP wurde SCEP so leichtgewichtig und einfach wie möglich gestaltet und basiert auf einem proprietären Protokoll, das ursprünglich für Cisco entwickelt wurde, das auch den ersten Entwurf für SCEP vorgelegt hat.

Im Vergleich zu CMP ist die Anzahl der Operationen von SCEP viel begrenzter und umfasst einige Befehle für die Registrierung und den Abruf von Zertifikaten und CRLs, wobei in späteren Versionen des Entwurfs auch eine leicht schräge Möglichkeit zur Erneuerung vorgesehen ist. SCEP steckte zwischen der Veröffentlichung von Version 23 des ursprünglichen Entwurfs im Jahr 2011 und der endgültigen Veröffentlichung von RFC 8894 im Jahr 2020 in der Entwurfshölle fest, was bedeutet, dass die Entwurfsversion 23 immer noch die De-facto-Version ist, die von den meisten CAs unterstützt wird software, einschließlich EJBCA.

Aufgrund seines Erbes und seiner weiten Verbreitung ist SCEP auch heute noch ein beliebtes Anmeldeprotokoll, insbesondere für einfache Anwendungen wie die Geräteanmeldung. Microsofts Entscheidung, SCEP bei der Definition seines Intune-Dienstes für die Registrierung von Geräten in der Azure-Cloud zu erweitern, hat SCEP als ein Protokoll zementiert, das noch viele Jahre lang unterstützt werden sollte.

Da der Schwerpunkt auf der Leichtgewichtigkeit liegt, fehlt SCEP die Unterstützung für mehrere Funktionen, die als wesentlich angesehen werden könnten, einschließlich des Widerrufs und der expliziten Erneuerung (die im RFC, aber nicht im Entwurf 23 vorhanden ist). Die Verschlüsselung der Nutzdaten ist auch einer der Hauptnachteile von SCEP, da die Verschlüsselungsmethode auf dem öffentlichen Schlüssel der CA beruht. Das bedeutet, dass SCEP nur RSA-Schlüssel unterstützt und in einer Post-Quantum-Zukunft wahrscheinlich keine Verwendung mehr finden wird. Der Verschlüsselungsprozess selbst ist wohl so komplex, dass das "S" in SCEP überflüssig ist.

+ Als altes Protokoll wird es immer noch weithin genutzt und unterstützt.

+ Eine Voraussetzung, wenn Ihr Anwendungsfall Microsoft Intune beinhaltet

- Die noch begrenzte Annahme des RFC im Gegensatz zum Entwurf kann in Zukunft zu Kompatibilitätsproblemen führen

- Der Vorgangssatz umfasst nicht den gesamten Lebenszyklus eines Zertifikats

- Keine Unterstützung für elliptische Kurven und begrenzte Krypto-Flexibilität

- Cisco selbst empfiehlt EST für neue Anwendungen

Das Enrollment over Secure Transport-Protokoll (EST) ist in vielerlei Hinsicht der geistige Nachfolger von SCEP. Es wurde von Cisco und Aruba Networks als leichtgewichtiges Enrollment-Protokoll mit TLS im Hinterkopf geschrieben und berücksichtigt die bis zu seiner Veröffentlichung im Jahr 2013 gemachten Erfahrungen. Wie bei SCEP gibt es auch bei EST keinen Nachrichtentyp für den Widerruf, aber es unterstützt die Erneuerung von Anfang an. EST ist in RFC 7030 beschrieben.

Eines der Grundprinzipien von EST ist insbesondere die Verwendung von TLS, wodurch Nutzdaten über einen verschlüsselten Kanal übertragen werden können und somit nicht mit einem gemeinsamen Geheimnis verschlüsselt werden müssen. Dadurch kann EST im Gegensatz zu SCEP mit elliptischen Kurven-basierten Schlüsseln umgehen.

Wie bei SCEP kann EST ein gemeinsames Geheimnis (Passwort) für die Client-Authentifizierung verwenden, aber auch ein Client-Zertifikat, das von einer vertrauenswürdigen dritten Partei ausgestellt wurde.

Das Vertrauen auf den HTTPS-Stack führt zu einfacheren Abfragen (EST kann mit curl aufgerufen werden), was schlanke Client-Implementierungen ermöglicht. Außerdem können mit EST die Schlüssel auf der Serverseite generiert werden. Diese Details machen EST zur natürlichen Wahl für IoT und andere leichtgewichtige PKI-Anwendungsfälle.

+ Wenn Sie ein Protokoll mit einer vollständigen Reihe von Operationen benötigen

+ Sie sind ein Telekommunikationshersteller oder eine andere Person in einer Branche, die auf 3GPP angewiesen ist.

- Sie sind nicht bereit, einen komplexen Client zu pflegen, der möglicherweise die verschiedenen RFC-Auffassungen der verschiedenen CA-Anbieter berücksichtigen muss.

ACME ist eines der wenigen Protokolle, die mit einem ganz bestimmten Ziel entwickelt wurden - es wurde von einer gemeinnützigen Gesellschaft, der Internet Security Research Group (ISRG), als Teil einer konzertierten Aktion entwickelt, um TLS weithin verfügbar zu machen und im Internet zu verwenden. Die anderen Elemente dieser Bemühungen sind die Let's Encrypt-Zertifizierungsstelle und der dazugehörige CertBot-Zertifikats-Client.

Was ACME von anderen Registrierungsprotokollen unterscheidet, ist die vollständige Automatisierung während des gesamten Lebenszyklus des Zertifikats und insbesondere die Möglichkeit für den Kunden, einen Identitätsnachweis zu erbringen (Inhaberschaft eines bestimmten DNS Namens), ohne dass eine manuelle Interaktion oder Überprüfung durch die Zertifizierungsstelle erforderlich ist.

Zu diesem Zweck bietet ACME einen Rahmen von Herausforderungen, die es der Zertifizierungsstelle ermöglichen, eine Reihe von Möglichkeiten festzulegen, mit denen der Client das Eigentum an der Ressource nachweisen kann, die als Identität dieses Zertifikats angegeben werden soll, z. B. ein DNS -Name oder eine E-Mail-Adresse für ein S/MIME-Zertifikat. Theoretisch soll ein Client, der ACME einsetzt, das Zertifikat so lange registrieren und erneuern können , wie die angegebene Identität noch kontrolliert wird.

Auch wenn dies nach einem Füllhorn von PKI-Vorteilen klingt, sollte man nicht vergessen, dass ACME in erster Linie für den Anwendungsfall TLS geschrieben wurde. Die Verfasser von RFC 8555 haben zwar geschickt Erweiterungen des RFC zugelassen, um zusätzliche Challenge-Typen zu definieren (und mehrere existieren als RFCs oder Entwürfe), aber das ACME-Protokoll hängt immer noch davon ab, dass diese Interaktion durchgeführt wird - wenn man sie auslässt, wird der Anwendungsfall für ACME sogar komplett negiert.

Die Komplexität dieser Interaktion erfordert auch die Unterstützung der Clients, da jede erweiterte Herausforderung oder Variation des RFC, die vom Server gehostet wird, bedeutungslos ist, wenn die Clients (von denen CertBot einer ist, aber es gibt eine Vielzahl) sich nicht dafür entscheiden, sie zu akzeptieren. Denken Sie also daran, dass jeder Anwendungsfall, der vom allgemeinen Modell der CA/Client-Interaktion abweicht, sowohl auf der Server- als auch auf der Client-Seite unterstützt werden muss.

+ Bestes Protokoll für die Ausstellung von TLS Zertifikaten

+ Bietet eine vollständige Reihe von Vorgängen und eine integrierte Automatisierung für die Einschreibung

+ Die automatische Erneuerung fördert die Verwendung von kurzlebigen Zertifikaten, was wiederum die Flexibilität der Kryptoindustrie erhöht.

+ Der leicht erweiterbare RFC bietet reichlich Gelegenheit, weitere Anwendungsfälle zu finden.

- Vanilla RFC ist für TLS -Zertifikate optimiert, während bei anderen Anwendungsfällen sichergestellt werden muss, dass^{3rd-Party-Client-Unterstützung} vorhanden ist.

- Unabhängig vom Anwendungsfall ist ACME darauf angewiesen, dass eine Herausforderung als Teil des Arbeitsablaufs verarbeitet wird. Wenn Ihr Anwendungsfall nicht vorsieht, dass die Zertifizierungsstelle die Kontrolle über eine Ressource überprüfen kann, ist ACME möglicherweise nicht das beste Protokoll für Sie.

Schließlich werden wir über unsere selbst entwickelte REST-API sprechen, die durch unsere Legacy-WebService-API ergänzt wird. Diese API ist natürlich genauso leistungsfähig wie alle anderen, bietet aber zusätzlich Einblicke und Verwaltungsfunktionen, die komplexe Arbeitsabläufe wie die Arbeit mit dem Genehmigungssystem von EJBCA, die Verwaltung von Endeinheiten, Krypto-Tokens und CAs ermöglichen.

Wie EST stützt sich auch die REST-API von EJBCAauf TLS für die Sicherheit und Integrität der Nachrichten, aber die Authentifizierung kann auch über OAuth und ein Client-Zertifikat erfolgen. Natürlich wird unsere REST-API ständig weiterentwickelt, so dass neue Arbeitsabläufe sehr viel schneller implementiert und eingeführt werden können, als wenn man auf die Verabschiedung eines RFC-Updates wartet.

Der Nachteil bei der Nutzung unserer REST-API ist natürlich, dass man als einzelner Anbieter an EJBCA gebunden ist, wie bei jeder proprietären API. Dies gilt natürlich für die gesamte Branche, da es keinen erfolgreichen Versuch gegeben hat, eine standardisierte REST-API unter den PKI-Anbietern zu schaffen.

+ Unbegrenzt erweiterbar, sowohl auf Anfrage von Keyfactor als auch für jeden, der Zugriff auf den Quellcode hat

+ Bietet im Vergleich zu anderen Protokollen detailliertere Arbeitsabläufe für die Registrierung und Ausstellung von Dokumenten

+ Kann mit den komplexeren Workflows von EJBCAverwendet werden, z. B. für Genehmigungen.

+ Kann auch für die Verwaltung von Aspekten von EJBCA verwendet werden, z. B. Krypto-Token, Endeinheiten und CAs

- Da es sich um ein proprietäres Protokoll handelt, wird die REST-API von EJBCAvon Drittanbietern nur begrenzt unterstützt.

Damit Sie alle Ihre PKI-Anwendungsfälle heute und in Zukunft abdecken können, benötigen Sie wahrscheinlich die Flexibilität, die relevanten Protokolle auszuwählen. EJBCA unterstützt diese und andere Protokolle, eine Vielzahl von Public-Key-Infrastruktur (PKI)-Anwendungsfällen, Szenarien und Integrationen in andere Anwendungsökosysteme - und hat sich in großen Implementierungen weltweit bewährt. Und da es als open source und als kostenlose Testversion in der Cloud verfügbar ist, können Sie es schon heute ausprobieren.

Möchten Sie selbst Hand anlegen und es ausprobieren?

• Sehen Sie sich den zweiten Teil der PKI at the Edge-Schulung an, um zu erfahren, wie man Zertifikate und CRLs mithilfe von EJBCA und Bouncy Castle mit CMP sowie REST-API.
• Eine detaillierte Spezifikation finden Sie unter EJBCA Interoperabilität und Zertifizierungen.
• Wenn Sie Unterstützung für andere Protokolle oder Anwendungsfälle benötigen, können Sie sich gerne an uns wenden.