Eine Public-Key-Infrastruktur (PKI) ist in erster Linie Verwaltung: Zertifikate beantragen, Anträge prüfen, Zertifikate ausstellen. Alle Schritte müssen zuverlässig und sicher ablaufen, damit das Vertrauen aller Beteiligten erhalten bleibt. Dabei ist eine PKI weit mehr als ein Root-Zertifikat und der berüchtigte "openssl"-Befehl. In Bild 1 kommen die wichtigsten Teilnehmer einer PKI zusammen: Der Anwender vertraut dem unbekannten Gesprächspartner, weil dieser eine Bestätigung (das Zertifikat) vorweisen kann. Diese Bestätigung stammt von einer vertrauenswürdigen Instanz (Root-CA), der beide Parteien vertrauen.

Die PKI regelt den Umgang mit Zertifikaten: ausstellen, prüfen, widerrufen. Und das alles bestenfalls automatisiert. Das wird mit dem openssl-Befehl schwierig und daher gibt es umfassende Ansätze, die Aufgaben einer PKI hinter einer schicken Webseite zu verstecken. Dieser Artikel wirft einen Blick auf drei frei nutzbare PKI-Projekte, welche Features sie bieten und wie sie sich in der Praxis verhalten. Aber eine Warnung vorweg: Die eigene PKI erfordert Planung und Vorsicht. Fällt der private Schlüssel der CA in falsche Hände, kann ein Angreifer damit Zertifikate für beliebige Domains ausstellen. Alle Clients, die dieser CA vertrauen, akzeptieren solche Zertifikate und zeigen keinerlei Hinweis an.

Der Weg zum Zertifikat ist vergleichbar mit einem Reisepass: Antrag ausfüllen, beim Amt vorsprechen, Gebühren bezahlen. Am Ende gibt es den fertigen Reisepass. Immerhin entfällt bei den Zertifikaten die Wartezeit. Doch viele Server benötigen viele Zertifikate und durch das Ablaufdatum wiederholt sich der Vorgang alle paar Monate oder Jahre. Daher gilt für Zertifikate das Gleiche wie für Server: "treat your servers like cattle not pets". Alle Server, die ein Zertifikat benötigen, sollten sich selbstständig und frühzeitig an die CA wenden und die Bestellung regeln.

Ein früher Lösungsansatz ist das "Simple Certificate Enrollment Protocol" (SCEP), das sich als Quasistandard durchgesetzt hat. Bei SCEP wendet sich der Client mit seiner Zertifikatsanfrage per HTTP – also unverschlüsselt – an die CA und fragt regelmäßig nach dem Status seines Zertifikats. Die CA empfängt die Anfrage, stellt das Zertifikat aus und übergibt es dem Anforderer. Unverschlüsseltes HTTP ist kein Showstopper, da sich der Anfragende durch ein Shared Secret ausweist. Ein Lauscher erhält zwar die Kommunikation im Klartext, aber diese enthält keine vertraulichen Informationen, sondern nur die Zertifikatsanforderung und das Zertifikat.

SCEP ist in einem RFC ordentlich dokumentiert. Leider hat der fast zehnjährige Standardisierungsprozess viele inkompatible Zwischenversionen hervorgebracht, die in so manche Implementierung eingeflossen sind. Beispielsweise sendet Certmonger von FreeIPA als Benutzernamen den Hostnamen, was bei der PKI von EJBCA auf Unverständnis stößt. Und selbst wenn ein entsprechender Account bei EJBCA vorhanden ist, kommt das Zertifikat nicht sauber zu Certmonger zurück.

Den Wunsch nach mehr Sicherheit wollte das Protokoll "Enrollment over Secure Transport" (EST) erfüllen. Client und Server kommunizieren über HTTPS und verwenden ein definiertes Web-API. Der Ansatz ist gut, aber das Protokoll hat sich eher im IoT-Umfeld verbreitet. Aus mehreren kleinen Unzulänglichkeiten entstand das "Automatic Certificate Management Environment" (ACME). Die Anfragen sind in JSON formuliert, nutzen HTTPS, und auf der Serverseite gibt es ein API mit wohldefinierten Befehlen und robuster Authentifizierung mittels JSON-Web-Token.

Da ACME für die Masse konzipiert ist, arbeitet es nicht mit Shared Secrets, sondern mit Challenges. Wer ein Zertifikat auf den Hostnamen "www.stark.de" haben möchte, muss zuerst beweisen, dass er der Eigentümer der Webseite ist. Dazu erwartet der ACME-Server eine spezielle URL auf der Webseite "http://www.stark.de", die der ACME-Client dort als Beweis anlegen muss. Kann der Server die URL erreichen, ist der Beweis erbracht und es gibt ein Zertifikat – allerdings nur auf den Namen "www.stark.de". ACME ist eng verbunden mit Let's Encrypt, aber prinzipiell auch von anderen CAs nutzbar, da es sich um einen offenen Standard handelt. Falls lediglich das ACME-Protokoll gewünscht ist, lohnt sich ein Blick auf das "ACME Server"-Projekt bei GitHub [1].

Eine schnelle Root-CA entsteht auf der Kommandozeile mit dem bekannten openssl-Befehl, den wahrscheinlich jeder Admin schon einmal benutzt hat. OpenSSL ist vielseitig, aber die Parameter sind nicht gerade selbsterklärend. Auch das certtool aus der GnuTLS-Bibliothek [2] hilft gerne bei allen Aufgaben rund um die Zertifikate. Eine weitere Möglichkeit ist das wenig bekannte Tool cfssl von Cloudflare [3]. Es bezeichnet sich selbst als das Schweizer Taschenmesser für PKI und TLS. Die Software steht unter einer freien Lizenz und lässt sich kommerziell einsetzen. Für ein CA-Zertifikat benötigt cfssl zwar nur einen einzigen Befehl, erwartet aber alle Informationen in Form einer JSON-Datei:

Danach befinden sich der private Schlüssel "cert-key.pem" und das Zertifikat "cert.pem" der neuen Root-CA im Arbeitsverzeichnis. Damit lässt sich bereits eine Guerilla-PKI betreiben oder die Schlüssel für eine "echte" CA erzeugen, dazu später mehr.

Der Name dieser PKI ist Programm, denn PKIaaS.io [4] ist ein reiner Clouddienst – sozusagen as-a-Service. Der Anbieter stellt ein Web-GUI zur Verfügung, um eine Root-CA zu gründen und damit weitere Zertifikate auszustellen. Dazu gibt es die üblichen Protokolle zur Verifizierung und zum automatischen Rollout von Zertifikaten. Es gibt keine formale Registrierung. Die Erstanmeldung erfolgt mit dem eigenen GitHub/Google/Microsoft-Account und danach kann es direkt losgehen. Eine Preisliste suchen Nutzer vergebens, da das Geschäftsmodell auf Spenden basiert. Eine regelmäßige Zuwendung hebt die 30-tägige Gültigkeitsbeschränkung der Zertifikate auf.

Das Einrichten der eigenen Root-CA ist schnell erledigt. Dazu fragt das Web-GUI die üblichen Informationen ab, die später im Root-Zertifikat stehen. Es folgt die Auswahl von Key Usage und Extended Key Usage, die bereits mit akzeptablen Voreinstellungen belegt sind. Im Hintergrund erstellt PKIaaS das Kryptomaterial und formt daraus die PKI. Dabei fällt auf, dass der private Schlüssel unter Verschluss bleibt. Das ist prinzipiell richtig, macht aber einen Umzug von diesem Anbieter zu einem anderen oder ins heimische Rechenzentrum knifflig. Vermutlich lässt sich dies mit einer Spende regeln.

Wer die volle Kontrolle über seinen privaten Schlüssel haben möchte, kann diesen auf dem eigenen Computer erzeugen und bei der Erstellung der CA bei PKIaaS importieren. Die neue CA basiert dann auf dem eigenen Schlüssel. Eine weitere Auffälligkeit: Bei PKIaaS gibt es keine Hierarchie mit Root-CA und Issuing-CA. Die Root-CA bleibt im Tagesgeschäft stets online und stellt die Zertifikate für die End Entities aus. Wer hier Sicherheitsbedenken äußert, sollte PKIaaS nur zu Übungszwecken nutzen.

Für das Tagesgeschäft bringt PKIaaS Zertifikatsvorlagen mit. In einer solchen ist hinterlegt, wie lange das Zertifikat gültig ist, welche Felder ausgefüllt werden müssen und ob das Zertifikat für einen Server oder für einen Client ist. In einer neuen PKI gibt es anfangs nur die Vorlage "Web Server", aber neue Templates lassen sich einfach hinzuklicken. Die fertigen Vorlagen sind über diverse URLs ansprechbar. Damit kann ein Client seinen Zertifikatswunsch über verschiedene Methoden und Protokolle an die PKI richten. Bei den Protokollen ist PKIaaS gut aufgestellt. Zertifikate gibt es per ACME, SCEP und über einen manuellen Antrag per Webseite. Schwierig wird es bei der Fehlersuche, da PKIaaS keinen Einblick in die Logdateien bietet. Support gibt es über die Kommentarfunktion der Webseite.

Ein Goodie gibt es noch: PKIaaS lässt sich mit dem Security-Token YubiKey koppeln, um dort den privaten Schlüssel zu erzeugen und zu speichern. Der YubiKey steckt dabei im eigenen Linux-Computer und die Software IoT-HSM [5] verbindet sich mit den Servern von PKIaaS. Die Einrichtung erfolgt webbasiert (Bild 2) und die Kopplung mit der Cloud ist durch Zertifikate abgesichert.

OpenXPKI ist keine Neuentwicklung, sondern eine Abspaltung des OpenCA-Projekts. Das erste Release tauchte Mitte 2006 bei SourceForge auf, allerdings noch mit einer führenden Null als Versionsnummer. Bis zur Marktreife 2015 hatten die Entwickler genügend Zeit, eine robuste PKI zu konstruieren.

OpenXPKI ist quelloffen und alle Komponenten liegen seit 2012 bei GitHub. Als Einnahmequelle vermarktet die Firma hinter OpenXPKI ihre Enterprise-Edition. Kunden erhalten Support, Extras und Softwarepakete für die Enterprise-Linux-Distributionen von Red Hat und SuSE. Wer sich die Einrichtung und den Betrieb selbst zutraut, greift zur Community-Edition und folgt der komplexen Installationsanleitung, wahlweise per Skript, Debian-Paket oder als Docker-Container. Zum Reinschnuppern bietet die Anleitung eine "Sample / Demo Configuration".

Auffällig ist, dass sich OpenXPKI nicht als Root-CA oder Intermediate-CA versteht. Das mag verwirren, aber die Software beschäftigt sich nur mit den Aufgaben einer PKI und nicht mit der Sicherheit einer CA-Gründung. Immerhin verweist die Dokumentation auf das Schwesterprojekt CLCA [6], das sich mit dem Schlüsselmaterial befasst.

Für das Tagesgeschäft bringt OpenXPKI Zertifikatsprofile mit (Bild 3). Die Profile funktionieren wie die Certificate Templates bei PKIaaS und legen die Eigenschaften des zukünftigen Zertifikats fest. Wem die Standardprofile nicht zusagen, kann diese gerne anpassen oder neue Profile erstellen. Für sämtliche Änderungen geht es runter auf die Kommandozeile – das Web-GUI bietet hier keine Unterstützung. Ein Zertifikatsprofil ist hierbei eine YAML-formatierte Datei unterhalb von "/etc/openxpki/config.d/realm/*/profile/". Viele erklärende Beispiele befinden sich im Unterordner "template".

Die PKI stellt neue Zertifikate nur aus, wenn sie einem der Profile entsprechen. So kann der Administrator beispielsweise festlegen, dass seine Zertifikate maximal 90 Tage gültig sind oder ausschließlich die Kryptografie mit elliptischen Kurven verwenden. Der Antragsteller entscheidet sich zu Beginn für ein Profil und erhält später das daraus resultierende Zertifikat.

Schon bei der Installation zeigt sich die Komplexität von OpenXPKI, die hauptsächlich der Sicherheit geschuldet ist. Dafür ist jeder Arbeitsschritt und jede spätere Tätigkeit dokumentiert. Für alltägliche Aufgaben bietet OpenXPKI eine übersichtliche Webseite. Grundlegende Änderungen finden direkt in den Konfigurationsdateien statt. Etwas Erfahrung mit der Linux-Bash und einem Texteditor sind von Vorteil. Die Möglichkeiten zur Automatisierung beschränkt OpenXPKI auf das SCEP-Protokoll. Für eine Enterprise-PKI ist OpenXPKI vor allem wegen der Trennung der Privilegien zu empfehlen, für kleine Umgebungen ist das Produkt übertrieben.

Die "Enterprise JavaBeans Certificate Authority" (EJBCA) hat in ihrem Titel tatsächlich die Zielgruppe, die Programmiersprache und die Funktion eingebettet. Und damit ist die schwedische Firma, die EJBCA entwickelt und Support anbietet, seit 2001 erfolgreich am Markt unterwegs. Die PKI-Software gibt es als Enterprise- und als Community-Edition. Letztere verzichtet auf kommerziellen Support und einzelne Features. Die Einschränkungen beziehen sich nicht auf die Laufzeit oder die Anzahl der Zertifikate, sondern auf die Protokolle.

EJBCA kommt als Bare-Metal-Installation oder Docker-Image. Die klassische Installation umfasst viele Schritte und basiert auf anderen Tools wie Wildfire, Ant, MariaDB und natürlich Java. Das angebotene Docker-Image kümmert sich um alles und übergibt eine schlüsselfertige PKI. Die PKI gliedert sich in Certificate Authority, Registration Authority (RA) und Validation Authority (VA). Über die Webseite der RA können Antragsteller ihre Zertifikatswünsche einkippen. Die VA prüft die Gültigkeit der ausgestellten Zertifikate. CA, VA und RA können auf unterschiedlichen Servern laufen, sodass die CA als Herzstück der PKI keine Verbindungen von außen annehmen muss und damit eine minimale Angriffsfläche bietet.

Im Installationsmodus "simple" entsteht eine Spielumgebung, die ohne Authentifizierung arbeitet. Erst im "true"-Modus macht EJBCA Ernst und erzwingt eine Anmeldung per Clientzertifikat. Am Ende der Installation spuckt die Konsole ein Passwort und die URL aus, unter der sie das Zertifikat zum Download anbietet. Der Zugriff gelingt mit einem beliebigen Webbrowser. Der Dateiname "SuperAdmin.p12" ist Programm, denn hier handelt es sich um den obersten Admin der zukünftigen PKI. Sobald das Clientzertifikat aus der P12-Datei im lokalen Zertifikatsspeicher angekommen ist, öffnet das Web-GUI von EJBCA ihre Pforten. Die ersten Gehversuche beginnen auf der Weboberfläche unter "https://127.0.0.1/ejbca/adminweb/". Von den verwirrend vielen Menüeinträgen benötigt die neue CA nur den obersten Block.

Eine minimale CA entsteht bei EJBCA in vier Schritten: Kryptomaterial anlegen, CA erstellen, Zertifikatsprofile bilden und Protokolle aktivieren. Beim Menüpunkt "Crypto Token" erstellt der Admin mehrere Schlüsselpaare und wählt einen Speicherort. Der Typ "SOFT" legt die Keys im lokalen Dateisystem an. Für den Einsatz eines Hardware Security Modules (HSM) sind Anpassungen auf der Kommandozeile nötig. Dafür unterstützt EJBCA jede Menge Securitymodule und fasst diese in einer Kompatibilitätsliste zusammen. Unabhängig vom Crypto-Backend benötigt die zukünftige CA einen Encryption Key und einen Signing Key.

Im Menübereich "Certification Authorities" existiert bereits die Management-CA, die der Installer ungefragt anlegt. Die neue CA erwartet zunächst einen festen Namen, der später im Root-Zertifikat für jedermann sichtbar ist. Die bekannten PKIs von Verisign/Digicert und GlobalSign hinterlegen im Namen der CA übrigens eine Versionsnummer wie beispielsweise G2 oder R5. Dies verhindert die späteren Bezeichnungen "neu" oder "neu2", wenn ein Generationswechsel ansteht. Anschließend fragt der Webassistent nach den Schlüsseln aus dem vorherigen Schritt (Bild 4) und bietet zahlreiche weitere Optionen an. Die wichtigsten sind der Subject DN, die Gültigkeit des Zertifikats und die Sperrliste.

Nun könnte die CA bereits Zertifikate ausstellen, da mehrere Standardprofile existieren. Die "Certificate Profiles" funktionieren genau wie bei PKIaaS.io und OpenXPKI. Die vordefinierten Profile lassen sich per Klonfunktion auf die neu erstellte CA übertragen und beliebig anpassen. Wichtig bei einem Zertifikatsprofil sind die Aspekte "Key Algorithm" und "Bit Length". Der gewählte Algorithmus plus Schlüssellänge sollten für die geplante Lebensdauer der CA ein solides Sicherheitsniveau bieten. EJBCA spendiert bei den Profilen ein Admin-freundliches Feature, denn hier lässt sich das Ablaufdatum mit dem Wochentag kombinieren. So laufen Zertifikate beispielsweise nie zwischen Freitag und Montag ab. Wer das Ablaufdatum nicht per Monitoringsystem im Blick hat, bekommt den Stress zumindest nicht am Wochenende (Bild 5).

Die CA ist fertig und über die Registration Authority akzeptiert EJBCA bereits manuelle Zertifikatsanfragen. Die Automatisierungsprotokolle befinden sich bei "System Configuration" und erwarten eine einmalige Aktivierung. Leider behält EJBCA die meisten Protokolle Kunden der Enterprise-Edition vor, sodass im kostenlosen Bereich lediglich SCEP nutzbar ist.

Es ergibt wenig Sinn, die eigene Landschaft mit Zertifikaten zu stärken und gleichzeitig den Zugang zur CA mit nur einem simplen Passwort zu schützen. OpenXPKI und EJBCA akzeptieren ein Login per Clientzertifikat, wobei EJBCA diese Anmeldung sogar erzwingt. Im letzten Schritt erstellt der Installer ein Client-Zertifikat und stellt es per URL zum Download bereit. Die Erstanmeldung erfolgt ausschließlich damit.

PKIaaS vertraut bei der Anmeldung auf die Authentifizierungsdienste von Google, GitHub und Microsoft. Leider erzwingt dies keine Zwei-Faktor-Authentifizierung, sodass der Zugang zur PKI auch mit einem herkömmlichen Kennwort möglich ist. Ernsthafte Nutzer der PKI sollten den verwendeten Zugang entsprechend absichern. Alle unterstützten Authentifizierungsdienste akzeptieren eine Authenticator-App oder einen Passkey.

Der private Schlüssel ist das Heiligtum jeder CA. Fällt der Schlüssel in falsche Hände, ist eine sofortige Rückrufaktion erforderlich. Die Bandbreite eines Schlüsselkonzepts ist vielfältig: Root-CA verschlüsseln oder Kryptomaterial auf einem (verschlüsselten) USB-Stick im Bankschließfach lagern. Im professionellen Umfeld hat sich das Hardware Security Module bewährt. Dabei liegen die Keys in einem physischen Gerät, das gegen Angriffe gehärtet ist.

Das HSM kommt als 19-Zoll-Appliance und lässt sich per Ethernet ins Firmennetz einbinden. Für maximale Sicherheit erzeugt das HSM die Schlüssel selbst und gibt sie niemals preis. Die kryptografischen Operationen finden direkt im HSM statt. Leider sind die Appliances nicht gerade preisgünstig. Für zertifizierte Geräte fallen fünfstellige Eurobeträge an.

Wer sich mit einem HSM vertraut machen möchte, kann vorab einen Blick auf eine Softwareimplementierung werfen. Dazu eignen sich "SoftHSM" [7] von OpenDNSSEC sowie "Bouncy Hsm" [8], die sich beide wie ein echtes Hardware-Sicherheitsmodul verhalten. Bouncy Hsm läuft unter Windows und kommt mit einer bequemen Webseite für die Konfiguration (Bild 6). SoftHSM gibt es zwar für Linux und Windows, aber die Anbindung läuft über PKCS#11. Das ist zwar vielseitig, benötigt aber ein weiteres Tool für die Einrichtung. Das eingangs erwähnte IoT-HSM bietet keine PKCS#11-Schnittstelle und funktioniert daher nur mit dem Angebot von PKIaaS.io.

Der PKI-Server und das HSM kommunizieren über das Firmennetz und nutzen die Spezifikation PKCS#11. Beim Aufbau der PKI kooperiert die Root-CA mit dem HSM, um dort die Schlüssel generieren zu lassen. Auch bei der späteren Ausstellung von Zertifikaten überträgt die CA die Krypto-Arbeit an das HSM. Auch wenn die Kommunikation durch PKCS#11 genormt ist, geben die PKI-Entwickler eine Liste kompatibler Hersteller an. Dazu gehören nicht nur Hardware-Appliances, sondern auch Cloudanbieter, die ihre HSM-Dienste virtuell liefern, wie beispielsweise AWS CloudHSM.

Für den kleinen Geldbeutel gibt es Security-Token mit USB-Anschluss wie den YubiKey. Per Kommandozeile oder GUI lässt sich ein vorhandener Schlüssel importieren oder neu erstellen. Beim Signieren von Zertifikatsanfragen muss der YubiKey allerdings passen. Hierzu ist eine ordentliche PKI nötig.

Unter dem Stichwort Certificate Lifecycle Management haben Zertifikate eine kurze Lebensdauer von meist drei Monaten. Damit zwingen die großen PKIs ihre Kunden zur Automatisierung und bieten gleichzeitig ein entsprechendes Protokoll wie SCEP oder ACME an. Beispielsweise macht Let's Encrypt keine Ausnahme und limitiert die Laufzeiten auf exakt 90 Tage.

Die erzwungene Automatisierung hat mehrere Vorteile. Die Tragweite eines kompromittierten Schlüssels ist auf den Zeitraum von drei Monaten begrenzt. Außerdem lassen sich neue Kryptoalgorithmen schneller ausrollen und unsichere Algorithmen rascher aus dem Verkehr ziehen, wenn jeder Webserver nach maximal 90 Tagen ein neues Zertifikat haben muss.

Die Open-Source-Welt bietet noch mehr PKI-Sternchen, die entweder allgemein bekannt sind oder deren kostenfreies Programm streng limitiert ist. Beispielsweise ist das Dogtag Certificate System [9] schon lange in der Community vertreten. Leider gibt es die Installationspakete nur für ältere Linux-Distributionen und auch die Webseite sieht nicht mehr ganz frisch aus. Dafür ist die Dokumentation ausführlich und viele Probleme sind in den Mailinglisten bereits ausdiskutiert. Kommerziellen Support gibt es nicht, obwohl Red Hat hinter dem Projekt steht. Laut FAQ handelt es sich lediglich um ein "Development Project".

Step-CA hätte es als "Der Schnelle" in diesen Artikel geschafft, wenn die Software eine Weboberfläche hätte. Tatsächlich gibt es nur eine Kommandozeile, auch wenn diese pfeilschnell ist und alle Features bedient. Außerdem erlaubt das Projekt im kostenfreien Modus maximal zehn Geräte.

Beim Run auf die Zertifikate ist auch HashiCorp mit seinem Vault dabei. Es handelt sich hierbei eigentlich um einen virtuellen Banktresor, der nebenbei auch Zertifikate ausstellen kann. Die PKI-Option ist anfangs inaktiv und kommt als "Secrets Engine" hinzu. Vault plus PKI sind schnell installiert und der Aufstieg zur CA stellt nur wenige Rückfragen. Bei den Protokollen spendiert HashiCorp OCSP und ACME. Erst beim HSM erwartet Vault eine kostenpflichtige Enterprise-Lizenz. Die Anzahl der ausgestellten Zertifikate ist nicht begrenzt.

Die Zeiten, in denen lediglich der Lastverteiler und das ERP-System ein Zertifikat benötigten, sind vorbei. Heutzutage erwartet jeder simple Webdienst ein korrekt ausgestelltes Zertifikat, damit weder Anwender noch API-Clients aufgescheucht werden. Wer seine Zertifikate jedoch nicht kaufen möchte, kann eine eigene PKI gründen und sich eigene Zertifikate generieren.

Die vorgestellten PKIs bringen das notwendige Handwerkszeug mit und ermöglichen über diverse Protokolle ein automatisiertes Certificate Lifecycle Management. Da Leistungsumfang und Komplexität variieren, ist ein vorheriger Blick in die Spezifikation hilfreich, um das passende Produkt für die eigene Umgebung auszuwählen. Sobald alles rundläuft, erneuern die Server selbstständig ihre Zertifikate. Der Admin greift nur noch bei Problemen ein.