CSR und X.509-Zertifikate lokal untersuchen

Die Formate unterscheiden

Ein Certificate Signing Request (CSR) enthält einen Antragsteller und einen öffentlichen Schlüssel sowie die Signatur des Antragstellers. Ein ausgestelltes X.509-Zertifikat enthält zusätzlich Aussteller, Seriennummer, Gültigkeitsdaten und Erweiterungen. Ein CSR besitzt keine vom Aussteller festgelegte Gültigkeitsdauer. Beide Formate können als PEM-Text mit Base64-kodierten DER-Daten vorliegen.

Felder untersuchen

Öffnen Sie den X.509- und CSR-Decoder und fügen Sie einen vollständigen PEM-Block ein. Behalten Sie BEGIN- und END-Markierungen bei. CERTIFICATE steht für ein Zertifikat, CERTIFICATE REQUEST für einen CSR. Der Parser liest die ASN.1-Struktur lokal im Browser. OpenSSL ist für diese Untersuchung nicht erforderlich.

-----BEGIN CERTIFICATE REQUEST-----
(base64 DER data)
-----END CERTIFICATE REQUEST-----

Ergebnisse prüfen

Vergleichen Sie den Antragsteller mit der erwarteten Identität. Prüfen Sie bei Zertifikaten Aussteller, Gültigkeitsdaten und alternative Namen, sofern vorhanden. Beachten Sie Algorithmus und Größe des öffentlichen Schlüssels. Kontrollieren Sie einen CSR vor der Übermittlung an Ihre Zertifizierungsstelle. Dekodieren validiert keine Zertifikatskette und prüft weder Widerruf noch die Sicherheit einer Website.

Private Schlüssel getrennt halten

Fügen Sie niemals einen PRIVATE KEY-Block ein. Auch öffentliche Zertifikate können interne Namen und Organisationsdaten offenlegen. Verwenden Sie Beispiele beim Teilen. Optionale KI-Hilfe ist vom lokalen Parser getrennt und kann nach Zustimmung Daten extern senden. Prüfen Sie die Offline-Verfügbarkeit, bevor Sie sich in einem Vorfall auf den Cache verlassen.

Normative Prüfpunkte (RFC 2986 und RFC 5280)

Bei der Fehlersuche in PKI-Zertifikaten und TLS-Handshakes sollten Sie folgende Standards beachten:

1. Alternative Antragstellernamen (SAN) statt CN: Moderne Webclients (RFC 5280 & RFC 6125) stufen das klassische commonName-Attribut als veraltet ein. Enthält Ihr Zertifikat keine subjectAltName-Erweiterung mit allen Domänen oder IP-Adressen, verweigern Browser die Verbindung mit ERR_CERT_COMMON_NAME_INVALID.
2. Besitznachweis (Proof of Possession, POP): In einem gültigen PKCS#10-CSR (RFC 2986) signiert der private Schlüssel die CertificationRequestInfo-Struktur. Der Decoder verifiziert diese Eigensignatur, um sicherzustellen, dass der Antragsteller tatsächlich über den zugehörigen privaten Schlüssel verfügt.
3. Erweiterte Schlüsselverwendung (Extended Key Usage, EKU): Stellen Sie sicher, dass das Zertifikat serverAuth (1.3.6.1.5.5.7.3.1) für Webserver oder clientAuth (1.3.6.1.5.5.7.3.2) für mTLS-Szenarien explizit aufführt.