Warum diesen Parser verwenden?

Validieren Sie, was auf Ihrem Zertifikat erscheinen wird, bevor Sie es an eine Behörde senden.
Erkennen Sie einen fehlenden SAN, einen zu kurzen Schlüssel, einen schwachen Algorithmus, verdächtige IDN-Kodierung.
Sparen Sie Zeit beim Onboarding oder bei der Verlängerung, indem Sie sofort die nützlichen Felder lesen.

Was ist ein CSR?

Ein Certificate Signing Request ist eine Textdatei im PEM-Format, die Folgendes enthält:

Ihren öffentlichen Schlüssel
Identitätsinformationen zu Subjekt und SAN
eine mit Ihrem privaten Schlüssel erstellte Signatur zum Nachweis des Besitzes

Der CSR wird an eine CA—Let's Encrypt, DigiCert, GlobalSign…—übermittelt, die das Zertifikat ausstellt, wenn die Überprüfung erfolgreich ist: DV, OV, EV.

Wann sollte ein CSR generiert werden?

Erstellung oder Verlängerung eines TLS-Zertifikats für Webserver, API, MTA
Hinzufügen einer neuen SAN-Subdomain, neuer FQDN
Wechsel von RSA zu EC für bessere Leistung
Standardisierung einer heterogenen Infrastruktur, bei der die Felder inkonsistent sind

Was sollte ein guter CSR enthalten?

Subjekt-CN wird manchmal von modernen CAs ignoriert, behalten Sie ihn, aber verlassen Sie sich nicht allein darauf
SAN Subject Alternative Name die Liste aller abgedeckten Namen, einschließlich der nackten Domain, falls erforderlich
Öffentlicher Schlüsseltyp RSA 2048 min, ideal 3072 oder EC P-256/P-384
Signatur SHA-256 empfohlen
Optionale Key Usage und Extended Key Usage entsprechend Ihren Anforderungen

Erinnerung
Ohne SAN lehnen viele CAs ab. Ein CN allein reicht nicht mehr aus.

Anleitung

Fügen Sie den vollständigen CSR zwischen -----BEGIN CERTIFICATE REQUEST----- und -----END CERTIFICATE REQUEST----- ein.
Klicken Sie auf CSR analysieren.
Lesen Sie die Zusammenfassung: Subjekt, SAN, Schlüsseltyp und -größe, Algorithmus, Fingerabdrücke.
Korrigieren und regenerieren Sie, falls etwas blockiert.

Nützliche OpenSSL-Beispiele

RSA 3072 CSR mit SAN

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

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

EC P-256 CSR mit SAN

openssl ecparam -name prime256v1 -genkey -noout -out site.key
openssl req -new -key site.key -out site.csr -config san.cnf

IDN

Verwenden Sie Punycode xn--… in SANs, um Überraschungen zu vermeiden.

Fehlerbehebung und häufige Fehler

Fehlende SANs das Zertifikat deckt weniger Namen ab als erwartet
RSA 1024 oder SHA-1 wahrscheinliche Ablehnung
Privater Schlüssel offengelegt fügen Sie niemals den privaten Schlüssel hier oder in einem Ticket ein
Ausgefallene Feldselektoren O, OU, L, ST, C nutzlos bei DV und Quelle von Inkonsistenzen bei OV/EV
Falsch kodiertes IDN verwenden Sie exakten Punycode
Wildcard *.beispiel.com fügen Sie auch beispiel.com hinzu, wenn Sie die nackte Domain abdecken möchten

Best Practices

Generieren Sie das Schlüsselpaar serverseitig und halten Sie den privaten Schlüssel von jeder Freigabe fern
Bevorzugen Sie EC P-256/P-384 oder RSA ≥ 3072 für neue Bereitstellungen
Beschränken Sie die SAN-Liste auf das, was tatsächlich nützlich ist
Führen Sie ein Protokoll: Datum, Subjekt, SAN, Schlüsselgröße, Ursprungsperson
Testen Sie das Lesen des CSR nach der Generierung, um einen Roundtrip mit der CA zu vermeiden

Datenschutzverpflichtung

Ihr CSR wird nur zur Dekodierung und Anzeige an die CaptainDNS-API gesendet.
Der Inhalt wird nicht gespeichert. Kein Feld wird im Klartext protokolliert.
Es werden nur anonyme technische Metriken erfasst: Verarbeitungszeit, Größe, Schlüsseltyp und Algorithmus zur Verfügbarkeitsüberwachung.

CSR-Parser