CSR-Parser

Warum einen CSR vor dem Einreichen analysieren?

Ein CSR-Decoder zeigt Felder an. Er beantwortet die Frage "was steht in dieser Datei", nie die Frage, die sich vor dem Bezahlen eines Zertifikats stellt: Wird meine Zertifizierungsstelle ihn annehmen, und wenn nicht, warum.

Der Unterschied ist messbar. Ein Common Name, der in den SAN fehlt, ein Wildcard auf *.co.uk, ein Unterstrich in einem DNS-Namen, ein Name auf .local, eine private IP-Adresse in den SAN oder gar keine SAN: lauter Anfragen, die eine öffentliche Zertifizierungsstelle ablehnt und die die gängigen Decoder kommentarlos anzeigen.

Dieser Parser dekodiert den CSR vollständig und prüft dann jeden gemessenen Fakt gegen die CA/Browser Forum Baseline Requirements und die einschlägigen RFC. Er liefert ein Urteil mit drei Zuständen, konform, Warnung oder nicht konform, samt Befunden und deren Quelle. Der Katalog umfasst 59 Codes; wie viele Prüfungen tatsächlich laufen, hängt vom analysierten CSR ab.

Drei Anwendungsfälle, die immer wiederkehren:

• Vor dem Einreichen: die blockierenden Punkte beheben und den richtigen CSR nur ein einziges Mal senden.
• Beim Erhalt des Zertifikats: prüfen, ob es wirklich aus diesem CSR stammt, belegt durch den Fingerabdruck des öffentlichen Schlüssels.
• Bei der Übernahme einer alten PKI: interne Namen, zu kurze Schlüssel und untersagte Felder aufspüren.

Was ein CSR enthält

Ein Certificate Signing Request ist ein ASN.1-Objekt nach RFC 2986, in DER kodiert und dann als Base64 in einer PEM-Hülle transportiert. Er trägt drei Dinge:

• einen öffentlichen Schlüssel, RSA oder auf elliptischer Kurve, und sonst nichts;
• die beantragten Bezeichner: das Subject (CN, O, L, ST, C) und, in einem PKCS#9-Attribut namens extensionRequest, die gewünschten Erweiterungen einschließlich der SAN;
• eine Signatur, erzeugt mit dem passenden privaten Schlüssel.

Die SAN sind also kein Feld der obersten Ebene: Sie reisen in einem Attribut mit. Das erklärt, warum eine unvollständige openssl-Konfiguration einen CSR ganz ohne SAN erzeugt, ohne dass irgendetwas protestiert.

Was Ihre Zertifizierungsstelle wirklich mit dem CSR macht

Hier liegt der Punkt, den fast alle Decoder übersehen: Die Zertifizierungsstelle baut das Zertifikat neu auf, sie kopiert den CSR nicht. Sie erzeugt authorityInformationAccess, authorityKeyIdentifier, certificatePolicies, extKeyUsage und selbst den subjectAltName des ausgestellten Zertifikats eigenständig. Ein einziges Feld wird Byte für Byte übernommen: SubjectPublicKeyInfo, Ihr öffentlicher Schlüssel und seine Algorithmuskennung.

Das bestimmt den Schweregrad jedes Befundes und ist die zentrale Kalibrierung des Tools. Ein Inhalt wird nur dann blockierend, wenn er ein konformes Zertifikat unmöglich macht: Schlüssel außerhalb des Profils, kompromittierter Schlüssel, unzulässiger Bezeichner oder ein Verstoß des CSR selbst gegen RFC 2986. Alles, was die Zertifizierungsstelle überschreibt oder ignoriert, eine Organisationseinheit oder eine exotische Erweiterung, bleibt bei einer Warnung.

Was die Signatur beweist und was nicht

Die Signatur eines CSR belegt eines: Zum Zeitpunkt der Erstellung besaß der Urheber den privaten Schlüssel zum öffentlichen Schlüssel, und das Tripel aus Subject, Schlüssel und Attributen hat sich seither nicht verändert. Sie belegt keinerlei Kontrolle über die Domain, keine Befugnis des Antragstellers, keine Aktualität (PKCS#10 trägt keinen Zeitstempel) und keine Exklusivität: Der Schlüssel kann längst in einem öffentlichen Repository liegen.

Eine ungültige Signatur bricht die Analyse deshalb nicht ab, sie ist ein Befund unter vielen, und die Ursache ist oft harmlos: Abschneiden beim Kopieren, ein vom Hosting-Portal neu kodierter CSR. Das Tool unterscheidet drei Zustände statt zwei, gültig, ungültig und nicht prüfbar; es wirft einem CSR, den es nicht verifizieren konnte, nie eine Manipulation vor.

Die Ablehnungen, die eine reine Dekodierung nicht sieht

Der CN muss in den SAN stehen

Der Common Name ist optional und in den aktuellen Profilen unerwünscht. Ist er aber vorhanden, muss er exakt einen der Werte aus subjectAltName wiederholen: Ein CN, der nirgends in den SAN auftaucht, macht das Zertifikat nicht konform.

Der verwandte Fall ist noch häufiger, der CSR ganz ohne SAN. Mit einem CN hängt er von einem wohlwollenden Neuaufbau durch die Zertifizierungsstelle ab, worauf man sich nicht verlassen sollte. Ohne CN und ohne SAN hat die Zertifizierungsstelle nichts zu validieren, und die Ablehnung ist sicher.

Die zwei Regelebenen für Wildcards

Die syntaktische Ebene stammt aus RFC 9525: nur ein einziger Wildcard, und er muss den gesamten Inhalt des am weitesten links stehenden Labels bilden. *.captaindns.com ist gültig; *.*.captaindns.com und www*.captaindns.com sind es nicht, und ein konformer Client muss den Namen ignorieren. Das Zertifikat würde ausgestellt und wäre dann unbrauchbar.

Die politische Ebene stammt aus den Baseline Requirements: Eine Zertifizierungsstelle muss einen Wildcard auf einem Public Suffix aus dem ICANN-Abschnitt ablehnen, etwa *.co.uk. Im privaten Abschnitt derselben Liste ist die Ablehnung nur eine Empfehlung, daher lediglich eine Warnung.

Ein oft vergessener Hinweis: Ein Wildcard reicht nur eine Ebene tief. *.captaindns.com deckt weder captaindns.com noch a.b.captaindns.com ab.

Interne Namen sind seit 2015 nicht mehr ausstellbar

server.local, intranet.corp, nas.lan, localhost, ein einzelnes Label ohne Punkt oder eine TLD, die es in der Root-Zone nicht gibt: Das sind interne Namen. Ihre Ausstellung ist seit dem 1. November 2015 verboten, und die bestehenden Zertifikate wurden am 1. Oktober 2016 zwangsweise widerrufen. Trotzdem tauchen sie noch in CSR auf, die aus alten internen PKI stammen und zu einer öffentlichen Zertifizierungsstelle weitergereicht werden.

Dieselbe Logik gilt für reservierte IP-Adressen in den SAN, ob nach RFC 1918, Loopback, Link-Local, CGNAT oder ULA: Eine Zertifizierungsstelle validiert nicht, was sie nicht erreichen kann. Neu ist: Seit dem 15. März 2026 ist auch ein Name verboten, der auf .in-addr.arpa oder .ip6.arpa endet.

Die Organisationseinheit ist aus den Zertifikaten verschwunden

Das Feld organizationalUnit ist seit dem 1. September 2022 untersagt, in Anwendung des am 29. Juni 2021 angenommenen Ballot SC047v2; der übliche Verweis auf "Ballot SC62" ist falsch. Die Zertifizierungsstelle lehnt den CSR deswegen nicht ab, sie entfernt das Feld, daher eine Warnung.

Eine E-Mail-Adresse im Subject gilt nach RFC 5280 als veraltet und hat in einem TLS-Serverzertifikat keinen legitimen Platz. Und ein Punkt gegen die Intuition: Ein leeres Subject ist konform, und sogar modern. Das Profil der Domain-Validierung akzeptiert nur das Land, optional, und den Common Name, unerwünscht.

Schlüssellängen, Algorithmen und bereits kompromittierte Schlüssel

RSA 2048 bleibt konform: 3072 Bit ist eine Empfehlung mit Blick auf 2030 und wird als Information gemeldet. Eine Signatur mit SHA-1 ist im Sinne der Baseline Requirements nicht blockierend, denn deren Klausel gegen SHA-1 zielt auf Objekte, die eine Zertifizierungsstelle signiert, nicht der Antragsteller; sie wird als Warnung eingestuft, mit der Einschränkung, dass die Zertifizierungsstellen sie in der Praxis seit 2016 ablehnen.

Zwei Prüfungen gehen weiter. Es sind die einzigen Stellen der Baseline Requirements, an denen steht, dass die Zertifizierungsstelle die Anfrage ablehnen muss:

• ROCA (CVE-2017-15361): RSA-Schlüssel aus einer in Chipkarten und TPM verbreiteten Bibliothek haben eine erkennbare Struktur, die ihre Entropie einbrechen lässt. Die Erkennung faktorisiert nichts, sie ist ein Fingerabdrucktest auf dem Modulus.
• Schwache Debian-Schlüssel (CVE-2008-0166): Zwischen September 2006 und Mai 2008 hat ein defekter Zufallsgenerator den Schlüsselraum auf einige Zehntausend Werte je Länge geschrumpft. Die Liste ist im Dienst hinterlegt und wird offline abgefragt.

In beiden Fällen muss das gesamte Schlüsselpaar neu erzeugt werden: Denselben Schlüssel in einem neuen CSR wiederzuverwenden würde die Schwäche fortschreiben.

Der SPKI-Fingerabdruck, der alles andere zusammenführt

Alle Decoder zeigen einen "Fingerabdruck" des CSR an. Das ist der Hash der gesamten Datei: Er ändert sich, wenn Sie den CSR mit demselben Schlüssel neu erzeugen, und er hat nichts mit dem Zertifikat zu tun, das Sie erhalten werden.

Der Fingerabdruck, der wirklich nützt, ist der des SubjectPublicKeyInfo, definiert in RFC 7469: der SHA-256-Hash der in DER kodierten Struktur des öffentlichen Schlüssels. Da dies das einzige Byte für Byte übernommene Feld ist, findet sich derselbe Wert im CSR, im ausgestellten Zertifikat und im passenden privaten Schlüssel wieder, und er überlebt eine Neuausstellung.

Drei unmittelbare Anwendungen: ein erhaltenes Zertifikat seinem CSR zuordnen, ohne Subjects zu vergleichen, die die Zertifizierungsstelle ohnehin neu geschrieben hat; lokal prüfen, ob Ihr privater Schlüssel der richtige ist, mit dem weiter unten angegebenen Befehl; einen DANE-Eintrag 3 1 1 zusammensetzen, dessen Selektor 1 genau dieser Fingerabdruck ist, den der DANE/TLSA Checker anschließend im DNS kontrolliert. Der Fingerabdruck wird hexadezimal und in Base64 ausgegeben.

Den CSR mit dem ausgelieferten Zertifikat vergleichen

Optional und standardmäßig nicht aktiviert: Geben Sie einen Host an, und der Parser holt das Zertifikat, das dieser tatsächlich ausliefert, und vergleicht die beiden SPKI-Fingerabdrücke. Drei Fälle, gleicher Schlüssel, anderer Schlüssel oder Host nicht erreichbar, wobei der letzte am häufigsten ist, da ein CSR vor der Ausstellung analysiert wird.

Das ist der einzige Netzwerkpfad des Tools: Ist das Kästchen nicht aktiviert, gibt es keine ausgehende Verbindung. Das Ergebnis fließt nie in das Konformitätsurteil ein, denn was anderswo ausgeliefert wird, sagt nichts über die Gültigkeit einer Anfrage aus, und es wird nichts aus dem CSR an den Host übermittelt.

Um das ausgelieferte Zertifikat selbst zu beurteilen, samt Vertrauenskette und Ablauf, ist der SSL Certificate Checker das passende Tool. Danach folgt der Lebenszyklus der Zertifikate, zumal die Laufzeit bis 2029 auf 47 Tage sinkt.

Nützliche openssl-Befehle

Datei san.cnf, ohne die openssl einen CSR ganz ohne SAN erzeugt:

[ req ]
prompt = no
distinguished_name = dn
req_extensions = v3_req
[ dn ]
CN = www.captaindns.com
[ v3_req ]
subjectAltName = @alt
[ alt ]
DNS.1 = www.captaindns.com
DNS.2 = captaindns.com

# RSA 3072
openssl req -new -newkey rsa:3072 -nodes -keyout captaindns.key -out captaindns.csr -config san.cnf

# ECDSA P-256
openssl ecparam -name prime256v1 -genkey -noout -out captaindns.key
openssl req -new -key captaindns.key -out captaindns.csr -config san.cnf

Den SPKI-Fingerabdruck des CSR, des erhaltenen Zertifikats und des privaten Schlüssels berechnen und dann prüfen, ob alle drei übereinstimmen, ohne irgendetwas irgendwohin zu senden:

openssl req  -in captaindns.csr -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
openssl x509 -in captaindns.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
openssl pkey -in captaindns.key -pubout       | openssl pkey -pubin -outform DER | openssl dgst -sha256

Bei einer internationalisierten Domain tragen Sie die Punycode-Form (Präfix xn--) in den SAN ein: Der Parser zeigt die Unicode-Form daneben an und verwirft ein korrektes xn---Label nie.

Datenschutz

Fügen Sie niemals Ihren privaten Schlüssel ein, weder hier noch anderswo: Ein CSR trägt nur den öffentlichen Schlüssel. Ein PEM-Header eines privaten Schlüssels wird vor jedem Senden erkannt, und die Analyse wird an Ort und Stelle verweigert. Wurde der Schlüssel bereits in ein Webformular eingefügt, betrachten Sie ihn als kompromittiert und erzeugen Sie das Paar neu.

Der CSR selbst ist kein Geheimnis: Er trägt Bezeichner, die in einem Zertifikat erscheinen sollen, das anschließend in den Certificate-Transparency-Logs veröffentlicht wird. Er wird im Speicher verarbeitet, um analysiert und angezeigt zu werden. Einzige Ausnahme: Der Wert des Attributs challengePassword wird nie zurückgegeben, nie angezeigt und nie protokolliert; gemeldet wird allein seine Anwesenheit.

FAQ - Häufig gestellte Fragen

F: Was ist ein CSR (Certificate Signing Request)?

A: Eine PKCS#10-Datei, in PEM transportiert, die Ihren öffentlichen Schlüssel, die beantragten Bezeichner (Subject und SAN) und eine mit dem passenden privaten Schlüssel erzeugte Signatur trägt. Sie enthält niemals den privaten Schlüssel. Sie übermitteln sie einer Zertifizierungsstelle, die Ihre Kontrolle über die Domains prüft und dann das Zertifikat ausstellt.

F: Warum lehnt eine Zertifizierungsstelle einen CSR ab?

A: Meist ein Common Name, der in den SAN fehlt, ein fehlerhafter Wildcard oder ein Wildcard auf einem Public Suffix, ein unzulässiges Zeichen in einem DNS-Namen (allen voran der Unterstrich), ein interner Name auf .local oder .corp, eine private IP-Adresse in den SAN, ein Schlüssel unter 2048 Bit oder das völlige Fehlen von SAN.

F: Muss der Common Name in den SAN stehen?

A: Ja, sobald er vorhanden ist: Die Baseline Requirements verlangen, dass er exakt einen der Werte aus subjectAltName wiederholt. Am einfachsten lassen Sie ihn leer, denn Browser lesen seit Jahren ausschließlich die SAN.

F: Mein CSR ist mit SHA-1 signiert, ist das blockierend?

A: Nicht im Sinne der Baseline Requirements: Die Klausel, die SHA-1 verbietet, zielt auf Objekte, die mit dem privaten Schlüssel einer Zertifizierungsstelle signiert wurden, ein CSR aber wird vom Antragsteller signiert. Das Tool stuft ihn als Warnung ein. In der Praxis lehnen öffentliche Zertifizierungsstellen CSR mit SHA-1 seit 2016 ab, erzeugen Sie ihn also mit SHA-256 neu. MD5 und MD2 sind blockierend.

F: Muss man die Felder O, OU, L und ST im Subject ausfüllen?

A: Nein, nicht bei einem Zertifikat mit Domain-Validierung: Das Profil akzeptiert nur das Land, optional, und den Common Name, unerwünscht. Ein leeres Subject ist vollkommen konform. Die Organisationseinheit ist seit dem 1. September 2022 sogar untersagt.

F: Wozu dient der SPKI-Fingerabdruck?

A: Er ist der SHA-256-Hash der Struktur des öffentlichen Schlüssels, das einzige Feld, das eine Zertifizierungsstelle Byte für Byte aus dem CSR in das Zertifikat übernimmt. Er belegt, dass ein CSR, ein erhaltenes Zertifikat und ein privater Schlüssel denselben Schlüssel tragen, und er dient als Selektor 1 in einem DANE-TLSA-Eintrag. Der von anderen Decodern angezeigte Fingerabdruck bezieht sich auf die ganze Datei und erlaubt keine dieser Zuordnungen.

F: Passt das bereits online stehende Zertifikat zu meinem CSR?

A: Aktivieren Sie die Vergleichsoption und geben Sie den Host an. Der Parser holt das ausgelieferte Zertifikat und vergleicht dessen SPKI-Fingerabdruck mit dem des CSR: gleicher Schlüssel, anderer Schlüssel oder Host nicht erreichbar. Dieser Vergleich beeinflusst das Konformitätsurteil nie und übermittelt nichts aus dem CSR an den abgefragten Host.

F: Wie erzeugt man mit openssl einen CSR mit SAN?

A: Legen Sie eine Konfigurationsdatei an, die DNS.1, DNS.2 und so weiter auflistet, und führen Sie dann openssl req -new -newkey rsa:3072 -nodes -keyout captaindns.key -out captaindns.csr -config san.cnf aus. Für einen Schlüssel auf elliptischer Kurve erzeugen Sie zuerst den Schlüssel mit openssl ecparam -name prime256v1 -genkey -noout und rufen dann openssl req -new -key auf. Ohne diese Datei erzeugt openssl einen CSR ganz ohne SAN.

Ergänzende Tools

Nützliche Ressourcen

• RFC 2986 - Syntax der Zertifizierungsanfrage (PKCS#10-Struktur des CSR)
• RFC 9525 - Prüfung der Dienstidentität (Wildcard-Regeln, ersetzt RFC 6125)
• RFC 7469 - Public-Key-Pinning (normative Definition des SPKI-Fingerabdrucks)
• CA/Browser Forum - Baseline Requirements (Regeln für die Ausstellung von TLS-Zertifikaten)