PKI-Toolkit

Wofür das hier gut ist

Der Klassiker ist die Fehlermeldung „incomplete certificate chain" oder „unable to get local issuer certificate" - meistens bei nginx, aber genauso bei Apache, HAProxy oder jedem anderen TLS-Endpunkt. Der Server hat ein Zertifikat, aber die dazwischenliegenden Intermediates fehlen oder liegen in der Konfigurationsdatei in der falschen Reihenfolge. Die bekannten Online-Prüfdienste beantworten das zuverlässig - vorausgesetzt, der Host ist öffentlich erreichbar. Auf einem internen Reverse Proxy, einer Verwaltungsoberfläche im eigenen Netz oder gegenüber einer unternehmenseigenen CA ist genau das nicht der Fall, und dafür ist dieses Werkzeug gebaut: alles läuft im eigenen Browser.

Dieselbe Lage entsteht, wenn ein Zertifikatssatz von einem Kunden, einem Dienstleister oder einer alten Ablage hereinkommt - mehrere PEM-, CRT- oder CER-Dateien, vielleicht ein PKCS#7-Bündel oder ein PKCS#12-Container, ohne dass klar ist, was davon Root, was Intermediate und was Leaf ist, und ob der private Schlüssel überhaupt zum richtigen Zertifikat gehört. Dazu gehört auch die Verwirrung, wenn zwei CA-Zertifikate mit demselben Aussteller-Namen im Umlauf sind - nach einem Root-Rollover oder bei Cross-Signing - und nicht klar ist, welches der beiden gerade tatsächlich signiert.

Wie man es benutzt

1. Dateien in die Ablagefläche im Bereich „Dateien" ziehen oder per Klick auswählen - beliebig gemischt und in beliebiger Reihenfolge: .pem, .crt, .cer, .der, .p7b, .p7c, .csr, .key, .p12, .pfx. Erkannt wird am Inhalt, nicht an der Dateiendung - eine falsch benannte Datei fällt also nicht durch.
2. In der Tabelle „Eingelesene Zertifikate" nachsehen: Datei, Subjekt, Aussteller, Gültig bis, Schlüssel und Status je Zertifikat. Was nicht geöffnet werden konnte, steht mit dem konkreten Grund unter „Hinweise zu den Dateien".
3. Im Bereich „Chain-Fixer" auf „Kette bauen" klicken. Jede Aussteller-Kind-Beziehung wird kryptographisch geprüft, nicht nur am Namen erkannt.
4. Bei Bedarf die Checkbox „Root-Zertifikat mit ausgeben" setzen - ohne sie endet die Kette beim obersten Intermediate, für die meisten Serverkonfigurationen die richtige Wahl.
5. Ergebnis über „fullchain.pem herunterladen" speichern oder mit „In Zwischenablage kopieren" übernehmen. Blockiert der Browser den Download, funktioniert Markieren und Strg/Cmd+C immer.

Was angezeigt wird

Der Bereich „Dateien" listet jede erkannte Datei mit ihrem Ausgang: verstanden, erkannt aber nicht geöffnet (etwa eine Zertifikatsanfrage oder ein PKCS#7-Bündel einer anderen Inhaltsart), oder beschädigt - mit einer Meldung, die den technischen Grund nennt statt nur „Fehler" zu melden. Die Tabelle darunter zeigt je erkanntem Zertifikat Subjekt, Aussteller, Gültigkeitsende, Schlüsselgröße bzw. -kurve und Status (gültig, abgelaufen, noch nicht gültig).

Der Bereich „Chain-Fixer" zeigt zuerst Hinweise: ein fehlender Aussteller, ein Zyklus in der Kette, mehrere mögliche Blattzertifikate in derselben Auswahl, oder mehrere Zertifikate mit gleichem Aussteller-Namen, von denen nur ein Teil tatsächlich signiert (Rotation oder Cross-Signing). Fehlt ein Intermediate und trägt das vorhandene Zertifikat eine AIA-caIssuers-URL, wird diese Adresse zum Nachladen genannt. Am Ende steht die sortierte Kette als Liste - je Eintrag Aussteller, Gültigkeitsende und Schlüssel - und darunter das fertige fullchain.pem in einem Textfeld.

Was bewusst nicht passiert

Keine Datei verlässt den Browser. Das ist keine Zusage, sondern technisch erzwungen: Die Content-Security-Policy dieses Werkzeugs setzt connect-src 'none', ausgehende Verbindungen sind damit unterbunden, nicht nur unterlassen - im Netzwerk-Tab der Browser-Entwicklerwerkzeuge in wenigen Sekunden nachprüfbar.

Eine fehlende AIA-URL wird genannt, aber nicht selbst abgerufen - das Nachladen bleibt Handarbeit, weil dafür eine Verbindung nach außen nötig wäre. Aus demselben Grund prüft dieses Werkzeug keine Sperrlisten (CRL) und keinen OCSP-Status: Eine solche Prüfung braucht eine Online-Anfrage, und genau die verhindert die CSP.

Von einem privaten Schlüssel wird nur der öffentliche Teil gelesen, um ihn mit den geladenen Zertifikaten abzugleichen - der geheime Teil wird an keiner Stelle ausgegeben, weder in die Zwischenablage noch in eine heruntergeladene Datei. Bei einem passwortgeschützten PKCS#12-Behälter wird kein Passwort erraten; automatisch versucht wird lediglich ein leeres Passwort, weil manche Exportwerkzeuge das als Voreinstellung setzen.

Grenzen

Ein Durchlauf verarbeitet bis zu 300 Zertifikate und insgesamt maximal 20 MB an Dateien, je Einzeldatei maximal 8 MB. Wer mehr hat, liest in kleineren Gruppen ein.

Ausgeliefert ist heute der Chain-Fixer: Dateien einlesen, Format am Inhalt erkennen und daraus eine korrekt sortierte Kette bauen. Eine grafische Hierarchie-Darstellung mit Gültigkeitsfenstern, Schlüsselalgorithmen und den Erweiterungen, die eine PKI-Struktur tatsächlich einschränken (pathLen, Name Constraints, Extended Key Usage je Zertifikat nebeneinander), sowie eine Ablauf-Zeitleiste über alle eingelesenen Zertifikate sind als nächster Schritt vorgesehen, aber noch nicht Teil dieser Seite.

Bei Name Constraints vergleicht das Werkzeug nur die Namensarten dNSName und directoryName - andere Namensarten in derselben Erweiterung werden weder bestätigt noch beanstandet. Eine im Zertifikat hinterlegte Abstandsangabe (minimum/maximum) für einen erlaubten oder ausgeschlossenen Teilbaum wird gelesen, aber nicht ausgewertet; RFC 5280 verlangt hier ohnehin minimum gleich 0 und kein maximum.

Manche Verschlüsselungsverfahren innerhalb eines PKCS#12- oder PKCS#8-Behälters werden erkannt und benannt, aber nicht entschlüsselt - das Werkzeug sagt dann, welches Verfahren vorliegt und dass es hier nicht geöffnet werden kann, statt einfach zu schweigen. Und Signaturblöcke, die ein PKCS#7-Bündel zusätzlich zu den Zertifikaten transportiert, werden nicht geprüft - dieses Werkzeug liest daraus nur die Zertifikate.

Wo eine dieser Grenzen greift, braucht es entweder ein Werkzeug mit Netzwerkzugriff (Sperrlisten, OCSP, AIA-Nachladen) oder eines, das die betroffene Verschlüsselung tatsächlich öffnet - zum Beispiel openssl auf der Kommandozeile.

Wo es herkommt

Dieses Werkzeug gehört zur Sammlung „Werkzeuge für Administratoren" auf nexilon.de/tools/ - Werkzeuge, die vollständig im Browser laufen, weil eine Unternehmens-CA nichts ist, was man bei einem fremden Anbieter hochlädt. Es ist Teil dessen, was die Seite „Eigene Software" zeigt: kein Auftragsentwicklungsangebot, sondern der Beleg für die technische Tiefe, auf die sich unsere Beratung beruft. Gebaut ohne Upload, damit es auch für eine interne CA taugt, bei der ein öffentlich erreichbarer Prüfdienst ohnehin nicht infrage kommt.