CSR-Viewer

Der CSR Viewer parst PEM-kodierte Certificate Signing Requests und zeigt alle Informationen an, die im resultierenden Zertifikat erscheinen werden -- Subject-Felder, SANs, Public-Key-Details und Signaturalgorithmus -- damit Sie Fehler erkennen können, bevor Sie den Antrag bei einer Certificate Authority einreichen. Fügen Sie einen CSR ein, der mit -----BEGIN CERTIFICATE REQUEST----- beginnt, und überprüfen Sie sofort jedes Feld.

Certificate Signing Requests verstehen

Ein Certificate Signing Request ist der formale Antrag, den Sie an eine Certificate Authority senden, wenn Sie ein neues Zertifikat benötigen. Er enthält Ihre Identitätsinformationen (Domainname, Organisationsdetails), Ihren öffentlichen Schlüssel und eine Liste angeforderter Erweiterungen wie Subject Alternative Names. Der CSR wird mit Ihrem privaten Schlüssel signiert, um zu beweisen, dass Sie das zugehörige Schlüsselpaar besitzen. Die CA prüft diese Informationen, verifiziert Ihre Identität durch Domain-Validierung oder Organisations-Validierung und stellt ein Zertifikat basierend auf dem Inhalt des CSR aus.

Das Entscheidende ist: Sobald ein Zertifikat ausgestellt ist, ist die Korrektur von Fehlern aufwändig. Wenn Sie einen CSR mit einem Tippfehler im Common Name, einem fehlenden SAN-Eintrag oder dem falschen Schlüsselalgorithmus eingereicht haben, müssen Sie einen neuen CSR generieren, ihn erneut einreichen und auf die Bearbeitung durch die CA warten. Für Domain-Validation-Zertifikate über Let's Encrypt ist das eine kleine Unannehmlichkeit. Für Organization-Validation- oder Extended-Validation-Zertifikate von kommerziellen CAs kann die Neuausstellung Tage dauern und zusätzliche Gebühren verursachen. Den CSR vor der Einreichung zu prüfen, ist die dreißig Sekunden immer wert.

Dieser Viewer dekodiert den CSR und stellt jedes Feld in menschenlesbarem Format dar. Sie können überprüfen, ob der Common Name mit Ihrer beabsichtigten Domain übereinstimmt, ob alle Subject Alternative Names vorhanden und korrekt geschrieben sind, ob der Schlüsselalgorithmus und die Schlüsselgröße Ihren Anforderungen entsprechen und ob der Signaturalgorithmus aktuell ist. Der Viewer weist auch auf potenzielle Probleme hin, wie schwache Schlüsselgrößen, veraltete Algorithmen oder fehlende SAN-Einträge, die bei der Ausstellung Probleme verursachen könnten.

So betrachten Sie einen Certificate Signing Request

1. Fügen Sie Ihren PEM-kodierten CSR ein (beginnend mit -----BEGIN CERTIFICATE REQUEST-----)
2. Der Viewer extrahiert und zeigt alle CSR-Felder an
3. Überprüfen Sie Subject-Details, SANs, Schlüsselinformationen und eventuelle Validierungswarnungen
4. Verifizieren Sie die Richtigkeit, bevor Sie den CSR bei Ihrer CA einreichen

Beispiel-CSR-Ausgabe

Einfügen eines typischen Multi-Domain-CSR:

Subject:
  Common Name (CN):  www.example.com
  Organization (O):  Example Inc.
  Locality (L):      San Francisco
  State (ST):        California
  Country (C):       US

Requested SANs:
  DNS: www.example.com
  DNS: example.com
  DNS: api.example.com
  DNS: cdn.example.com

Public Key:
  Algorithm:  RSA
  Key Size:   2048 bits

Signature:
  Algorithm:  SHA-256 with RSA

Automatische Validierungsprüfungen

Der Viewer kennzeichnet potenzielle Probleme automatisch:

Wann dieses Tool verwenden

• Überprüfung vor der Einreichung -- einen CSR vor dem Senden an eine Certificate Authority prüfen, besonders bei teuren EV- (Extended Validation) oder OV- (Organization Validation) Zertifikaten, bei denen eine Neuausstellung Zeit und Geld kostet
• Automatisierte CSR-Prüfung -- überprüfen, ob CSRs, die von ACME-Clients, Terraform, Ansible oder anderen Automatisierungstools generiert wurden, die korrekten Domains und Organisationsdetails enthalten
• Debugging von Zertifikatsausstellungsfehlern -- wenn eine CA einen CSR ablehnt, diesen untersuchen, um schwache Schlüssel, fehlende Felder oder Formatierungsprobleme zu identifizieren
• Team-Review -- von anderen Teammitgliedern erstellte CSRs vor der Einreichung auditieren und sicherstellen, dass Namenskonventionen und Domain-Abdeckung korrekt sind
• CSR mit ausgestelltem Zertifikat vergleichen -- überprüfen, ob die CA ein Zertifikat ausgestellt hat, das dem Antrag entspricht
• Schlüsselalgorithmus-Überprüfung -- bestätigen, ob ein CSR RSA oder ECDSA verwendet, bevor er eingereicht wird, besonders bei der Migration von Schlüsseltypen

Wie Certificate Signing Requests funktionieren

Ein CSR ist eine Nachricht, die ein Antragsteller an eine Certificate Authority sendet, um ein digitales Identitätszertifikat zu beantragen. Der CSR enthält:

1. Subject Distinguished Name -- identifiziert, wer das Zertifikat anfordert (CN, O, OU, L, ST, C-Felder)
2. Öffentlicher Schlüssel -- der öffentliche Schlüssel des Antragstellers, der im Zertifikat eingebettet wird
3. Angeforderte Erweiterungen -- zusätzliche Attribute wie Subject Alternative Names
4. Signatur -- der CSR wird mit dem privaten Schlüssel des Antragstellers signiert, um zu beweisen, dass er das zugehörige Schlüsselpaar besitzt

Generierung eines CSR mit OpenSSL

Ein typischer CSR-Generierungsbefehl:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key \
  -out example.com.csr \
  -subj "/C=US/ST=California/L=San Francisco/O=Example Inc./CN=www.example.com"

Für CSRs mit SANs benötigen Sie eine OpenSSL-Konfigurationsdatei, die die subjectAltName-Erweiterung spezifiziert, oder verwenden Sie das -addext-Flag:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key \
  -out example.com.csr \
  -subj "/CN=www.example.com" \
  -addext "subjectAltName=DNS:www.example.com,DNS:example.com"

CSR vs. Zertifikat

Best Practices für die CSR-Überprüfung

Der mit Abstand häufigste CSR-Fehler ist, den Common Name nicht in die Subject Alternative Names aufzunehmen. Seit Chrome 58 (veröffentlicht 2017) ignorieren Browser das CN-Feld bei der Hostname-Validierung vollständig und prüfen nur die SANs. Wenn Ihr CSR CN=www.example.com hat, aber keinen DNS:www.example.com-SAN-Eintrag, wird das ausgestellte Zertifikat in jedem modernen Browser Hostname-Mismatch-Fehler erzeugen. Stellen Sie immer sicher, dass jede Domain, die abgedeckt werden soll, als SAN-Eintrag erscheint, einschließlich des CN selbst.

Ein weiteres häufiges Problem ist die Generierung eines CSR mit einem zu kleinen Schlüssel. CAs stellen keine Zertifikate für RSA-Schlüssel unter 2048 Bits aus, und einige Compliance-Frameworks erfordern 4096-Bit RSA oder ECDSA P-384. Wenn Ihre Automatisierungstools Standard-Schlüsselgrößen haben, prüfen Sie diese vor dem Einsatz in der Produktion. Einen CSR mit einem größeren Schlüssel neu zu generieren ist einfach; das Problem zu entdecken, nachdem das Zertifikat ausgestellt und deployed wurde, ist es nicht.

Für Teams, die Infrastructure-as-Code-Tools wie Terraform oder Ansible zur CSR-Generierung verwenden, sollten Sie einen Überprüfungsschritt in Ihre Pipeline einbauen. Lassen Sie den CSR automatisch parsen und validieren, bevor er an die CA übermittelt wird. Dies fängt Konfigurationsdrift, fehlerhafte Variablensubstitutionen und Template-Fehler ab, die sonst zu Zertifikaten mit falschen Domains oder fehlenden SANs führen würden. Eine einzeilige Prüfung, die verifiziert, dass die CN- und SAN-Liste des CSR mit den erwarteten Werten übereinstimmt, kann Stunden der Fehlersuche sparen.

Häufig gestellte Fragen

Kann eine CA ändern, was in meinem CSR steht? Ja. Die CA kontrolliert, was in das endgültige Zertifikat kommt. Bei DV-Zertifikaten entfernen CAs typischerweise Organisationsfelder und behalten nur den CN und die SANs. Bei OV/EV-Zertifikaten überprüft die CA die Organisationsdetails und kann sie anpassen. Die CA setzt immer den Gültigkeitszeitraum, die Seriennummer und die Issuer-Felder. Sowohl Ihren CSR als auch das ausgestellte Zertifikat zu überprüfen, ist eine bewährte Praxis.

Warum zeigt mein CSR SHA-256 with RSA, obwohl ich ihn mit einem ECDSA-Schlüssel generiert habe? Der Signaturalgorithmus im CSR spiegelt wider, wie der CSR selbst signiert wurde, was von Ihrem Schlüsseltyp abhängt. Ein ECDSA-Schlüssel erzeugt ecdsa-with-SHA256 oder ähnlich. Wenn Sie sha256WithRSAEncryption sehen, ist Ihr Schlüssel RSA. Prüfen Sie den Public-Key-Abschnitt, um zu bestätigen, dass Algorithmus und Schlüsselgröße Ihren Erwartungen entsprechen.

Muss ich SANs im CSR angeben, oder kann die CA sie hinzufügen? Das hängt von der CA ab. Die meisten modernen CAs erlauben Ihnen, SANs während des Bestellvorgangs anzugeben, auch wenn sie nicht im CSR enthalten sind. SANs im CSR anzugeben ist jedoch Best Practice, da es Ihre Absicht dokumentiert und von einigen CAs verlangt wird. Überprüfen Sie immer, ob das ausgestellte Zertifikat alle erwarteten SANs enthält.

Wie überprüfe ich, ob ein CSR und ein privater Schlüssel zusammenpassen? Extrahieren Sie den öffentlichen Schlüssel sowohl aus dem CSR als auch aus dem privaten Schlüssel und vergleichen Sie sie. Mit OpenSSL: openssl req -in csr.pem -noout -pubkey und openssl pkey -in key.pem -pubout. Wenn die Ausgabe identisch ist, wurde der CSR mit diesem privaten Schlüssel generiert. Der Public Key Extractor kann bei diesem Vergleich ebenfalls helfen.

Was ist der Unterschied zwischen PKCS#10 und einem Certificate Signing Request? Sie sind dasselbe. PKCS#10 (RFC 2986) ist der formale Standard, der das CSR-Format definiert. Wenn Tools auf einen "PKCS#10 Request" oder einen "CSR" verweisen, meinen sie dieselbe Datenstruktur. Der PEM-Header -----BEGIN CERTIFICATE REQUEST----- wird für PKCS#10-CSRs verwendet.

Kann ich einen CSR nach Ablauf des Zertifikats wiederverwenden? Technisch ja, wenn Sie noch den zugehörigen privaten Schlüssel haben. Best Practice ist jedoch, für jede Erneuerung ein neues Schlüsselpaar und einen neuen CSR zu generieren. Dies begrenzt das Expositionsfenster, falls der private Schlüssel irgendwann während der Lebensdauer des vorherigen Zertifikats kompromittiert wurde.

Verwandte Tools

• X.509 Certificate Viewer - Das ausgestellte Zertifikat ansehen, um es mit dem ursprünglichen CSR zu vergleichen
• Public Key Extractor - Den öffentlichen Schlüssel aus CSR und Zertifikat extrahieren, um zu überprüfen, ob sie übereinstimmen
• SAN Extractor - SANs aus dem ausgestellten Zertifikat extrahieren, um zu bestätigen, dass alle angeforderten Domains abgedeckt sind
• Certificate Fingerprint Generator - Fingerabdrücke für das ausgestellte Zertifikat generieren
• Certificate Expiry Checker - Den Gültigkeitszeitraum des ausgestellten Zertifikats prüfen