CSR-Decoder (Certificate Signing Request)

Fügen Sie einfach einen CSR (Certificate Signing Request) im PEM-Format ein und prüfen Sie CN, SAN, Organisation und Schlüsselalgorithmus, bevor Sie ihn bei einer Zertifizierungsstelle einreichen. Kostenloses Tool zur frühzeitigen Fehlererkennung.

Was ist der CSR-Decoder?

Der CSR-Decoder ist ein kostenloses Tool, mit dem Sie einen CSR (Certificate Signing Request) im PEM-Format einfügen und sich sofort das beantragte Subject (CN, Organisation usw.), die SAN-Einträge (Subject Alternative Name), den Algorithmus des öffentlichen Schlüssels sowie den Signaturalgorithmus übersichtlich anzeigen lassen können. So lässt sich noch vor der Einreichung bei einer Zertifizierungsstelle (CA) auf einen Blick prüfen, ob die eingegebenen Angaben tatsächlich dem entsprechen, was beantragt werden soll.

Während das verwandte Tool „X.509-Zertifikatsdecoder" bereits ausgestellte Zertifikate analysiert, befasst sich dieses Tool ausschließlich mit dem CSR selbst – also mit der Phase vor der Prüfung und Ausstellung durch die CA. Es eignet sich damit ideal für die letzte Kontrolle, bevor überhaupt ein Zertifikat existiert oder bevor Sie ein neues Schlüsselpaar erzeugen.

So verwenden Sie den CSR-Decoder

  1. CSR im PEM-Format einfügen Fügen Sie den Text, der mit „-----BEGIN CERTIFICATE REQUEST-----" beginnt, unverändert in das Eingabefeld ein.
  2. Mehrere CSRs auf einmal einfügen Sie können auch mehrere CSRs gemeinsam einfügen – jeder Block wird automatisch als eigener Eintrag erkannt.
  3. Auf „Analysieren" klicken Prüfen Sie zunächst die Anzahl der erkannten CSRs und starten Sie anschließend die serverseitige Analyse per Klick.
  4. Ergebnis prüfen Subject, SAN, Schlüsselalgorithmus und weitere Angaben werden übersichtlich als Liste dargestellt.

Tipps für die Nutzung

  • Prüfen Sie vor der Einreichung unbedingt, ob sowohl im CN (Common Name) als auch in den SAN-Einträgen wirklich alle Hostnamen enthalten sind, die später ausgestellt werden sollen. Ein vergessener SAN-Eintrag führt fast immer zu einer aufwendigen Neuausstellung.
  • Nutzen Sie diesen Zeitpunkt auch, um zu kontrollieren, ob der Algorithmus des öffentlichen Schlüssels nicht unterhalb von RSA 2048 Bit liegt oder eine veraltete EC-Kurve verwendet – so vermeiden Sie eine Ablehnung durch die CA während der Prüfung.
  • Bevor Sie denselben CSR für mehrere Server wiederverwenden, sollten Sie noch einmal abgleichen, ob Organisation und Domain in Subject und SAN tatsächlich mit dem geplanten Verwendungszweck übereinstimmen.
  • Dieses Tool zeigt ausschließlich die im CSR beantragten Angaben. Welche SAN-Einträge die CA letztlich tatsächlich ausstellt, kann je nach Prüfungsergebnis davon abweichen.

Anwendungsbeispiele

Letzte Kontrolle vor der Einreichung bei der CA

Vor dem Kauf eines kostenpflichtigen SSL-Zertifikats lässt sich prüfen, ob CN und SAN bei der CSR-Erstellung korrekt eingegeben wurden.

Überprüfung interner CSR-Erstellungsabläufe

Auch Mitarbeitende ohne Kommandozeilenerfahrung können visuell nachvollziehen, ob ein mit openssl req oder ähnlichen Werkzeugen erzeugter CSR den Erwartungen entspricht.

Nachträgliche Prüfung archivierter CSRs

Als Datei gespeicherte CSRs lassen sich sicher erneut einsehen, ohne dass dabei der private Schlüssel berührt wird.

SAN-Vollständigkeitsprüfung bei Multidomain-Zertifikaten

Wenn mehrere Hostnamen gemeinsam auf einem einzigen Zertifikat beantragt werden sollen, lässt sich vor der Einreichung zuverlässig prüfen, ob alle Domains in der SAN-Liste enthalten sind.

Glossar

CSR (Certificate Signing Request)
Ein Datensatz, der bei der Beantragung eines Zertifikats an eine CA übermittelt wird und den öffentlichen Schlüssel sowie die Antragsangaben (Subject, SAN usw.) zusammenfasst.
CA (Zertifizierungsstelle)
Kurz für Certificate Authority. Eine vertrauenswürdige dritte Instanz, die den Inhalt eines CSR prüft und daraufhin das eigentliche SSL/TLS-Zertifikat ausstellt.
CN (Common Name)
Ein Feld des Subject, das den primären Hostnamen oder Dienstnamen des Zertifikats angibt. Früher prüften Browser nur den CN, heute hat die SAN-Angabe Vorrang.
SAN (Subject Alternative Name)
Ein Erweiterungsfeld, in dem zusätzliche gültige Hostnamen oder IP-Adressen des Zertifikats aufgeführt werden. Auf CSR-Ebene wird dies als Teil der „Requested Extensions" (angeforderte Erweiterungen) hinterlegt.
Requested Extensions (angeforderte Erweiterungen)
Attribute, mit denen der Antragsteller eines CSR festlegt, welche Erweiterungen bei der Ausstellung berücksichtigt werden sollen. SAN-Einträge sind hier enthalten, werden von der CA jedoch nicht zwingend unverändert übernommen.
Algorithmus des öffentlichen Schlüssels
Das Verfahren, mit dem der im CSR enthaltene öffentliche Schlüssel erzeugt wurde – etwa RSA oder EC (elliptische Kurvenkryptografie). Die Sicherheit hängt von Schlüssellänge bzw. gewählter Kurve ab.

Häufig gestellte Fragen

Für die Analyse wird der CSR einmalig an den Server übermittelt, jedoch nicht dauerhaft gespeichert oder protokolliert. Zwar enthält ein CSR keinen privaten Schlüssel, dennoch sollten Sie keine Antragsdaten einfügen, die Sie nicht öffentlich preisgeben möchten.

Nein. Dieses Tool unterstützt ausschließlich CSRs, die mit „-----BEGIN CERTIFICATE REQUEST-----" beginnen. Fügen Sie einen privaten Schlüssel niemals in irgendein Online-Tool ein.

Mögliche Ursachen sind fehlende BEGIN/END-Zeilen, ein beschädigter Base64-Teil oder das versehentliche Einfügen eines Zertifikats bzw. eines privaten Schlüssels anstelle eines CSR.

Der X.509-Zertifikatsdecoder analysiert bereits von einer CA ausgestellte Zertifikate, während dieses Tool den CSR – also die reinen Antragsdaten vor der Einreichung bei der CA – analysiert. Gültigkeitsdauer und Fingerabdruck existieren in einem CSR noch nicht und werden daher nicht angezeigt.

In den meisten Fällen ja, die endgültige Entscheidung liegt jedoch bei der Prüfung durch die CA. Manche Zertifizierungsstellen ignorieren die SAN-Angaben des CSR und übernehmen stattdessen die Angaben aus einem separaten Webformular bei der Bestellung.
Tool-kun

Übrigens – warum enthält ein CSR eigentlich eine Signatur?

Betrachtet man den Inhalt eines CSR genauer, findet sich nach den Angaben zu Subject und öffentlichem Schlüssel auch ein Signaturalgorithmus samt Signaturwert. Das mag zunächst überraschen: Warum sollte ein Dokument, mit dem man die CA bittet, „bestätigen Sie meine Identität", bereits eine eigene Signatur enthalten? Die Antwort liegt im Konzept des „Proof of Possession" (Nachweis des Besitzes des privaten Schlüssels). Der gesamte CSR-Inhalt – also Subject, öffentlicher Schlüssel und weitere Angaben – wird mit dem privaten Schlüssel signiert, der zum im CSR enthaltenen öffentlichen Schlüssel gehört. Damit weist der Antragsteller der CA nach, tatsächlich im Besitz des passenden privaten Schlüssels zu sein. Würde jemand versuchen, einen CSR mit dem öffentlichen Schlüssel einer fremden Person zu erstellen, könnte er ohne den zugehörigen privaten Schlüssel keine gültige Signatur erzeugen – auf diese Weise werden betrügerische Anträge zuverlässig verhindert.

Das CSR-Format wurde 1986 von RSA als Teil der PKCS-Familie (Public-Key Cryptography Standards) unter der Bezeichnung PKCS#10 festgelegt. Heute wird der Standard von der IETF als RFC 2986 weitergeführt, in der Praxis hat sich die Bezeichnung PKCS#10 jedoch bis heute gehalten. Innerhalb der TLS-Zertifikatswelt wirkt dieser Mechanismus unscheinbar, bildet jedoch den unverzichtbaren Ausgangspunkt des gesamten Ausstellungsprozesses.

Dass sich SAN-Einträge über die Requested Extensions in einen CSR aufnehmen lassen, ist historisch betrachtet eine vergleichsweise junge Entwicklung. Der ursprüngliche CSR-Standard (PKCS#10) sah im Wesentlichen nur Subject und CN vor. Erst mit der zunehmenden Verbreitung von Multidomain- und Wildcard-Zertifikaten begannen die Zertifizierungsstellen, SAN-Angaben jeweils auf eigene Weise entgegenzunehmen. Heute unterstützen gängige Werkzeuge wie openssl standardmäßig den in RFC 2985 beschriebenen Mechanismus „Extension Request", um SAN-Einträge in einen CSR aufzunehmen – und genau an dieser standardisierten Stelle (dem Attribut extensionRequest innerhalb der Attributes) liest auch dieses Tool die SAN-Angaben aus.