CSR-Decoder: Anforderung auslesen und prüfen

Fügen Sie eine CSR ein und lesen Sie jedes Feld aus, das sie enthält: den Antragsteller, den Schlüssel, jeden alternativen Namen und jede Erweiterung. Die Seite prüft die Anfrage außerdem gegen die Regeln, die eine öffentliche CA anwendet, und sagt Ihnen, ob Ihr privater Schlüssel dazu passt. Auch ein SSL-Zertifikat lässt sich hier decodieren.

Decodiert in Ihrem Browser mit Web Crypto · nichts wird hochgeladen, nichts wird gespeichert · Baseline Requirements v2.3.1 des CA/Browser Forum

Alles auf dieser Seite geschieht in Ihrem Browser. Öffnen Sie das Netzwerk-Panel und beobachten Sie: Keine Anfrage trägt Ihre Daten.

Was ist eine CSR?

Eine Zertifikatsanforderung (CSR) ist eine kleine signierte Datei, die bei einer Zertifizierungsstelle ein Zertifikat beantragt. Sie enthält Ihren öffentlichen Schlüssel, die Namen, die Sie auf dem Zertifikat haben möchten, und eine mit Ihrem privaten Schlüssel erstellte Signatur.

Das Format ist PKCS#10, festgelegt in RFC 2986. Der signierte Teil enthält nur vier Dinge: eine Versionsnummer, ein Antragsteller-Name, ein SubjectPublicKeyInfo mit Ihrem öffentlichen Schlüssel und eine Reihe von Attributen. Das Ganze wird dann mit dem privaten Schlüssel signiert, der zum öffentlichen Schlüssel darin gehört — eine CSR ist also selbstsigniert. Diese Signatur ist der Besitznachweis: Jeder kann Ihren öffentlichen Schlüssel lesen, aber nur der Besitzer des privaten Schlüssels kann eine Anfrage signieren, die sich dagegen verifizieren lässt.

Ihr privater Schlüssel steckt nicht in der Datei und sollte es auch nie tun. Eine CSR lässt sich gefahrlos per E-Mail verschicken, in das Webformular einer CA einfügen und hier decodieren — deshalb kann diese Seite ihre gesamte Arbeit in Ihrem Browser erledigen, ohne irgendetwas irgendwohin zu senden.

Eine Anfrage, Byte für ByteRFC 2986 · PKCS#10

Die ganze Datei

  • Hülle4 Bytes
  • Der signierte Teil469 Bytes
  • Welcher Signaturalgorithmus15 Bytes
  • Die Signatur selbst261 Bytes

Innerhalb des signierten Teils

  1. Version3 BytesImmer null: die einzige Version, die das Format definiert
  2. Antragsteller-Name108 BytesDer Distinguished Name, den Sie in das Formular eingegeben haben
  3. Ihr öffentlicher Schlüssel294 BytesAlgorithmus, Größe und der Schlüssel — das eine Feld, das eine Zertifizierungsstelle garantiert nutzt
  4. Attribute60 BytesHier reisen die angeforderten alternativen Namen mit

Ihr privater Schlüsselsigniert den Teil obenBeweis, dass Sie den passenden privaten Schlüssel besitzen · Die Signatur deckt nur diesen Teil ab, nicht die ganze Datei

Die Beispielanfrage, die diese Seite anbietet, 749 Bytes davon. Vier Dinge gehen in den signierten Teil ein; der private Schlüssel, der zum öffentlichen Schlüssel darin passt, signiert genau diesen Teil, und was dabei herauskommt, sind die letzten 261 Bytes.
CSR-Decoder-Ergebnis: eine decodierte CSR mit Antragsteller, Schlüssel, alternativen Namen und CA-Regel-BefundenCSR-Decoder-Ergebnis: eine decodierte CSR mit Antragsteller, Schlüssel, alternativen Namen und CA-Regel-BefundenEinfügen oder ablegenEine CSR, ein Zertifikat oder ein öffentlicher Schlüssel — PEM, Base64, ein Hex-Dump oder eine Datei. Mehrere auf einmal sind kein Problem.Das UrteilWas eine öffentliche CA mit dieser Anfrage macht: ausstellen, ändern oder ablehnen, jeweils mit Begründung.Die NamenJeder Name, den das Zertifikat abdecken würde, mit dem allgemeinen Namen dagegen abgeglichen.Schlüssel und SignaturAlgorithmus, Größe, Kurve und Exponent, und ob die eigene Signatur der Anfrage hält.SchlüsselabgleichFügen Sie den privaten Schlüssel oder das ausgestellte Zertifikat hinzu, um zu sehen, ob er zu dieser Anfrage gehört. Nichts davon verlässt Ihren Browser.
Eine CSR in ihre Bestandteile zerlegt: das Urteil, die angeforderten Namen, der zugehörige Schlüssel und ein Platz, um Ihren eigenen Schlüssel abzugleichen. Wählen Sie eine Nummer, um zu sehen, was der jeweilige Teil zeigt.

Wie Sie eine CSR prüfen, bevor Sie sie senden

Drei Dinge lohnt es sich zu prüfen: dass die Namen die sind, die Sie meinten, dass die Signatur gültig ist, und dass nichts darin gegen eine Regel Ihrer CA verstößt.

Fügen Sie die Anfrage oben ein. Die Seite liest den Antragsteller Attribut für Attribut aus, listet jeden Subject Alternative Name auf, zeigt Algorithmus und Größe des Schlüssels, und prüft dann die eigene Signatur der Anfrage. Eine Anfrage, deren Signatur sich nicht verifizieren lässt, wurde seit ihrer Erstellung bearbeitet, abgeschnitten oder beschädigt — erzeugen Sie sie neu, statt sie zu senden.

Danach kommen die Regeln. Eine Zertifizierungsstelle wendet die Baseline Requirements des CA/Browser Forum an, und eine Anfrage, die gegen eine davon verstößt, wird abgelehnt oder stillschweigend geändert. Die Befunde auf dieser Seite sind mit Zu beheben markiert, wenn die CA nicht ausstellen kann, was Sie beantragt haben, mit Wird geändert, wenn sie ausstellt, aber ein Feld entfernt oder ändert, und mit Hinweis, wenn nichts falsch ist, aber etwas einen Blick wert ist.

Drei Prüfungen, in der Reihenfolge, in der sie laufenCA/Browser Forum TLS BR 2.3.1
  1. Die NamenJeder Name, den das Zertifikat abdecken würde, und ob der allgemeine Name darunter ist
  2. Die SignaturGeprüft mit der eigenen Kryptografie Ihres Browsers
  3. Die Regeln der ZertifizierungsstelleEinzeln angewendet, jede mit dem Dokument, aus dem sie stammt
  • SendenNichts in der Anfrage verstößt gegen eine Regel
  • Wird abgelehntDie Datei ist in Ordnung; was sie verlangt, ist nicht erlaubt
  • Neu erstellenEine Signatur, die sich nicht verifizieren lässt, bedeutet, dass die Datei nach ihrer Erstellung bearbeitet, abgeschnitten oder schlecht kopiert wurde
Die ersten beiden Prüfungen betreffen die Datei selbst, die dritte betrifft das, was eine Zertifizierungsstelle erlaubt. Eine Anfrage kann beide ersten bestehen und trotzdem abgelehnt werden.

Was in einer CSR steht — und was Ihre CA tatsächlich nutzt

Von allem, was in einer CSR steht, nutzt eine öffentliche CA zuverlässig nur ein Feld: den öffentlichen Schlüssel. Den Rest validiert sie meist selbst, überschreibt ihn, oder darf ihn gar nicht übernehmen.

DigiCert sagt es in der eigenen Dokumentation unverblümt: „DigiCert uses the public key embedded in the CSR to create your client certificate. All other fields in the CSR are ignored.“ Bei einem OV- oder EV-Zertifikat muss die CA Organisation, Ort und Land selbst validieren, bevor sie aufgenommen werden; was Sie eingegeben haben, wird nicht ungeprüft übernommen. Gültigkeitsdaten werden nie aus einer Anfrage übernommen: Sie folgen dem Zeitplan der Baseline Requirements.

Zwei Antragsteller-Felder sind nicht nur ignoriert, sondern verboten. organizationalUnitName (OU) darf in einem öffentlichen TLS-Zertifikat nicht vorkommen — nach Ballot SC047 des CA/Browser Forum darf es in keinem seit dem 1. September 2022 ausgestellten Zertifikat enthalten sein — und emailAddress ist in einem domainvalidierten Zertifikat überhaupt nicht zulässig. Ein allgemeiner Name ist erlaubt, aber nicht empfohlen, und wenn er vorhanden ist, muss er exakt einen der Subject Alternative Names wiederholen. Diese letzte Regel ist der Grund, warum diese Seite einen allgemeinen Namen meldet, der in der SAN-Liste fehlt.

Was eine Zertifizierungsstelle mit jedem Feld machtCA/Browser Forum TLS BR 2.3.1
In Ihrer AnfrageWas damit geschiehtWarum
Öffentlicher SchlüsselSubjectPublicKeyInfoÜbernommen, wie gesendetDas eine, das eine Zertifizierungsstelle garantiert von Ihnen übernimmt
Alternative NamensubjectAltName2.5.29.17Übernommen, wie gesendetDie CA bestätigt, dass Sie jeden Namen kontrollieren, bevor sie auch nur einen davon aufschreibt
Allgemeiner NameCN2.5.4.3Validiert, dann von der CA geschriebenNicht empfohlen; wenn vorhanden, muss er exakt einen der alternativen Namen wiederholen
Organisation, Ort, BundeslandO, L, ST2.5.4.10Validiert, dann von der CA geschriebenBei einem organisationsvalidierten Zertifikat stammen diese aus den eigenen validierten Datensätzen der CA, nicht aus dem, was Sie eingegeben haben
LandC2.5.4.6Validiert, dann von der CA geschriebenDarf vorkommen, unabhängig von der Validierungsstufe
OrganisationseinheitOU2.5.4.11Überhaupt nicht erlaubtIn einem öffentlichen Zertifikat verboten seit 1. September 2022
E-Mail-AdresseemailAddress1.2.840.113549.1.9.1Überhaupt nicht erlaubtIn einem domainvalidierten Zertifikat nicht zulässig
Gültig von, gültig bisnotBefore, notAfterKommt nie aus der AnfrageFestgelegt durch den Zeitplan, dem die Zertifizierungsstelle folgt, nie durch Ihre Anfrage

„DigiCert uses the public key embedded in the CSR to create your client certificate. All other fields in the CSR are ignored.“

DigiCert, der eigenen Dokumentation
Die Felder, über die man sich den Kopf zerbricht, und was jedes tatsächlich wert ist. Ihr Schlüssel und Ihre Namen bleiben erhalten; die Organisationseinheit darf überhaupt nicht vorkommen, eine E-Mail-Adresse bei einem domainvalidierten Zertifikat ebenfalls nicht, egal was Sie eingeben; und die Daten waren nie Ihre, um sie festzulegen.

Warum eine CA eine CSR ablehnt

Fast jede Ablehnung läuft auf einen Namen hinaus, den eine CA nicht zertifizieren darf, auf eine zu weit gefasste Wildcard, eine reservierte IP-Adresse, einen zu kleinen Schlüssel, einen zu alten Signatur-Hash oder eine Anfrage, deren Signatur sich nicht verifizieren lässt.

Eine Zertifizierungsstelle darf nicht für einen internen Namen ausstellen — einen, der „does not end with a Top-Level Domain registered in IANA's Root Zone Database“ ist. Das trifft auf server.local, intranet, einen einteiligen Namen ganz ohne Punkt und jede erfundene Endung zu. Labels dürfen nur aus Buchstaben, Ziffern und Bindestrichen bestehen, daher wird ein Unterstrich in einem Hostnamen abgelehnt, und ein Name darf nicht mit einem abschließenden Punkt geschrieben werden. Eine Wildcard darf nur das gesamte am weitesten links stehende Label ersetzen, niemals ein öffentliches Suffix: *.example.com geht, *.co.uk nicht. Eine IP-Adresse darf vorkommen, aber keine reservierte — kein 10.0.0.0/8, 192.168.0.0/16, 127.0.0.1 oder fc00::/7.

Bei Schlüsseln sind die Baseline Requirements genau: ein RSA-Modulus von mindestens 2048 Bit, glatt durch 8 teilbar, oder ein Punkt auf P-256, P-384 oder P-521, und „no other algorithms or key sizes are permitted“. Eine CA muss außerdem einen Schlüssel ablehnen, den sie faktorisieren kann, einschließlich eines, „which can be factored within 100 rounds using Fermat's factorization method“ — diese Seite führt genau diesen Test am Schlüssel in Ihrer Anfrage durch. Und obwohl der eigene Signatur-Hash einer CSR nicht der des Zertifikats ist, akzeptiert Let's Encrypt seit 2022 keine SHA-1-Eigensignaturen mehr, sodass ein altes Werkzeug, das noch mit SHA-1 signiert, mit seiner Anfrage abgewiesen wird.

Namen, die eine Zertifizierungsstelle nicht zertifiziertCA/Browser Forum TLS BR 2.3.1
  • server.local
    Ein interner NameEr endet nicht auf eine Top-Level-Domain, die in der öffentlichen Root-Zone existiert, sodass niemand beweisen kann, dass er Ihnen gehört
    Abgelehnt
  • intranet
    Ein einzelnes LabelEin Name ganz ohne Punkt fällt unter dieselbe Definition
    Abgelehnt
  • my_host.example.com
    Ein UnterstrichEin Label darf nur Buchstaben, Ziffern und Bindestriche enthalten, sonst nichts
    Abgelehnt
  • *.co.uk
    Eine Wildcard über eine ganze RegistryEine Wildcard darf nur das am weitesten links stehende Label ersetzen, niemals ein öffentliches Suffix
    Abgelehnt
  • 192.168.1.10
    Eine reservierte AdresseEine öffentliche Adresse kann zertifiziert werden; eine aus einem privaten oder Sonderbereich nie
    Abgelehnt
  • example.com.
    Ein abschließender PunktDas leere Root-Label darf nicht ausgeschrieben werden
    Abgelehnt
Sechs Namen, die jeweils gegen eine andere Regel verstoßen — und jeder eine Ablehnung, die Sie schon vor dem Versand hätten erkennen können.

Woher weiß ich, dass mein privater Schlüssel zu meiner CSR passt?

Eine Datei mit einem privaten Schlüssel trägt bereits ihren eigenen öffentlichen Schlüssel, daher ist der Abgleich ein Vergleich zweier öffentlicher Schlüssel — kein Geheimnis wird benötigt, und nichts muss irgendwohin gesendet werden.

Öffnen Sie oben Schlüssel oder Zertifikat abgleichen und fügen Sie den Schlüssel neben der Anfrage hinzu. Die Seite liest nur die öffentliche Hälfte aus der Datei — PKCS#8-, PKCS#1- und SEC1-Schlüssel werden alle verstanden —, vergleicht sie mit dem Schlüssel in der Anfrage und liefert die Antwort. Nichts wird hochgeladen, nichts wird aufbewahrt, und der Schlüssel wird gelöscht, sobald Sie das Feld verlassen. Derselbe Abgleich funktioniert auch zwischen einer Anfrage und dem Zertifikat, das von der CA zurückkam — so fällt „das Zertifikat und der private Schlüssel passen nicht zusammen“ auf, bevor ein Server den Start verweigert.

Möchten Sie lieber keinen Schlüssel in irgendeine Webseite einfügen, liefern zwei Befehle auf Ihrem eigenen Rechner dieselbe Antwort. openssl req -in request.csr -pubkey -noout gibt den öffentlichen Schlüssel aus der Anfrage aus, und openssl pkey -in private.key -pubout gibt ihn aus dem Schlüssel aus: Identische Ausgabe bedeutet, dass sie zusammenpassen. Die ältere Form -modulus funktioniert nur für RSA-Schlüssel; -pubkey funktioniert für jeden Schlüsseltyp.

Zwei Dateien, ein VergleichRFC 2986 · OpenSSL manual
Ihr Browser
  • Die Datei mit dem privaten SchlüsselDie Datei, die Sie niemals irgendwohin senden dürfenIhre öffentliche Hälfte wird ausgelesen
  • Die AnfrageDie Datei, die Sie an die Zertifizierungsstelle sendenSie trägt den öffentlichen Schlüssel bereits in sich

Sind das derselbe Schlüssel?

  • Sie stimmen übereinDas Zertifikat, das zurückkommt, lässt sich mit diesem Schlüssel installieren
  • Sie stimmen nicht übereinDas ist die Nichtübereinstimmung, die ein Webserver meldet, wenn er nicht starten will

Nichts überquert diese Linie · Der Abgleich funktioniert auch mit ausgeschaltetem NetzwerkÜberall sonst

Oder machen Sie es auf Ihrem eigenen Rechneropenssl req -in request.csr -pubkey -nooutopenssl pkey -in private.key -puboutIdentische Ausgabe bedeutet, dass sie zusammenpassen
Eine Datei mit einem privaten Schlüssel trägt bereits ihren eigenen öffentlichen Schlüssel, daher klärt sich die Frage durch den Vergleich zweier öffentlicher Schlüssel. Dafür muss kein Geheimnis seinen Ort wechseln, und keines tut es.

CSR, Zertifikat, privater Schlüssel: Was ist der Unterschied?

Der private Schlüssel ist das Geheimnis. Die CSR ist eine Anfrage, die beweist, dass Sie ihn besitzen. Das Zertifikat ist die signierte Antwort der CA, und es ist das einzige der drei, das von vornherein öffentlich ist.

Die drei Dateien liegen oft im selben Ordner mit verwirrend ähnlichen Namen. Ein privater Schlüssel beginnt mit -----BEGIN PRIVATE KEY----- oder -----BEGIN RSA PRIVATE KEY----- und darf niemals an irgendjemanden gesendet werden, auch nicht an eine Zertifizierungsstelle. Eine CSR beginnt mit -----BEGIN CERTIFICATE REQUEST-----, ist mit genau diesem Schlüssel signiert und lässt sich gefahrlos versenden. Ein Zertifikat beginnt mit -----BEGIN CERTIFICATE-----, ist von der CA signiert und wird ohnehin an jeden Besucher Ihrer Website gesendet.

Sobald das Zertifikat ausgestellt ist, hat die Anfrage keinen weiteren Nutzen mehr: Sie wird für die Installation, Verlängerung oder den Widerruf nicht gebraucht. Der Schlüssel ist das, was Sie behalten müssen — und sicher aufbewahren müssen. Fügen Sie oben eines der drei ein, und diese Seite sagt Ihnen, welches es ist.

Drei Dateien, ein Ordner, verwirrend ähnliche NamenRFC 7468
  • Der private SchlüsselGeheim

    Seine erste Zeile-----BEGIN PRIVATE KEY-----Ebenfalls weit verbreitet-----BEGIN RSA PRIVATE KEY-----

    Signiert von
    Nichts — er ist es, der signiert
    Wer es sehen darf
    Sie, und sonst niemand
    Wofür es da ist
    Beweist, dass dieser Server derjenige ist, für den das Zertifikat ausgestellt wurde
  • Die CSRÖffentlich

    Seine erste Zeile-----BEGIN CERTIFICATE REQUEST-----Ebenfalls weit verbreitet-----BEGIN NEW CERTIFICATE REQUEST-----

    Signiert von
    Sich selbst, mit dem privaten Schlüssel
    Wer es sehen darf
    Sie und die Zertifizierungsstelle
    Wofür es da ist
    Beantragt ein Zertifikat und beweist, dass Sie den zugehörigen Schlüssel besitzen
  • Das ZertifikatÖffentlich

    Seine erste Zeile-----BEGIN CERTIFICATE-----

    Signiert von
    Die Zertifizierungsstelle
    Wer es sehen darf
    Jeder Besucher Ihrer Website
    Wofür es da ist
    Sagt einem Browser, dass dieser Schlüssel zu diesen Namen gehört

.csr.pem.req.txtKeine Norm legt für eine Anfrage eine Dateiendung fest; alle diese sind in Gebrauch, und diese Seite liest den Inhalt statt des Namens

Nur die erste der drei ist ein Geheimnis. Die letzte wird ohnehin jedem Besucher ausgehändigt, und die mittlere hat keinen weiteren Nutzen mehr, sobald das Zertifikat ankommt.

Ist es sicher, eine CSR online zu decodieren?

Eine CSR enthält kein Geheimnis, daher ist es harmlos, sie irgendwo zu decodieren. Ein privater Schlüssel ist eine andere Sache, und genau mit dieser Datei wird sie oft verwechselt.

Alles auf dieser Seite läuft in Ihrem Browser ab. Die Anfrage wird von Code ausgewertet, der mit der Seite heruntergeladen wurde, die Signatur wird mit der eigenen Web Crypto Ihres Browsers geprüft, und es wird keine Anfrage mit Ihren Daten an irgendeinen Server gesendet — Sie können das Netzwerk-Panel beobachten, während Sie die Seite nutzen. Das ergibt sich daraus, wie die Seite gebaut ist, es ist kein Versprechen, dem Sie einfach vertrauen müssen.

Wichtig wird das wegen der Datei neben der CSR. Die eigene Definition des CA/Browser Forum ist gnadenlos: „A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, or an unauthorized person has had access to it.“ Kein Missbrauch ist nötig — es reicht, dass die Datei auf einem fremden Server ankommt. 2020 fand DigiCert 337 private Schlüssel, die Kunden zusammen mit ihren CSRs eingefügt hatten, und widerrief jedes betroffene Zertifikat, mit der Begründung, „by sending the private key to DigiCert along with the CSR, the customer has compromised the private key“. Liest diese Seite jemals einen privaten Schlüssel, den Sie einfügen, sagt sie das, verweigert die Decodierung und behält nichts davon.

Wohin die Datei tatsächlich gehtCA/Browser Forum TLS BR 2.3.1

Diese Seite

Ihr Browser
  1. Die Datei wird gelesen
  2. Sie wird von Code zerlegt, der mit der Seite ankam
  3. Die Signatur wird vom Browser selbst geprüft
  4. Das Ergebnis wird angezeigt

Keine Anfrage verlässt den Browser mit Ihren Daten darinÖffnen Sie das Netzwerk-Panel und beobachten Sie es während der Nutzung

Eine Seite, die sie hochlädt

Ihr Browser

Die Datei wird hochgeladen… zusammen mit allem, was daneben eingefügt wurde

Der Server von jemand anderem

Ein privater Schlüssel, der dort ankommt, ist allein dadurch kompromittiert

„A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, or an unauthorized person has had access to it.“

die Definition, die sich die Zertifizierungsstellen selbst gegeben haben

Es ist bereits passiertIm Jahr 2020 fand eine Zertifizierungsstelle 337 private Schlüssel, jeweils neben der zugehörigen Anfrage eingefügtJedes betroffene Zertifikat wurde widerrufen

Nichts in einer Anfrage ist geheim, daher ist es harmlos, sie irgendwo zu decodieren. Die Datei, mit der man sie verwechselt, ist eine andere Sache, und der Schaden braucht überhaupt keinen Missbrauch — gesehen zu werden reicht.

RSA oder ECDSA: Welchen Schlüssel sollte eine CSR verwenden?

Ein ECDSA-P-256-Schlüssel ist so stark wie ein RSA-Schlüssel mit 3072 Bit und dabei deutlich kleiner, daher ist er die bessere Standardwahl. RSA 2048 wird weiterhin überall akzeptiert.

NIST setzt P-256 und RSA-3072 auf dieselbe Sicherheitsstärke von 128 Bit, und seine Tabelle hat überhaupt keine Zeile für RSA-4096: Die nächste Zeile ist RSA-7680 mit 192 Bit, der Stufe, die P-384 erreicht. Ein 4096-Bit-RSA-Schlüssel kostet also jeden Besucher zusätzliche Handshake-Arbeit, ohne dokumentierten Gewinn gegenüber 3072. Die Baseline Requirements erlauben auch P-521, aber Let's Encrypt lehnt es ab, sodass eine P-521-Anfrage völlig zulässig sein und trotzdem bei der CA scheitern kann, die Sie nutzen wollten.

Ed25519 ist heute keine Option für ein öffentliches TLS-Zertifikat, so gut der Algorithmus auch ist: Die Baseline Requirements listen RSA und die drei NIST-Kurven auf und fügen hinzu: „no other algorithms or key sizes are permitted“. Auch ein Post-Quanten-Schlüssel ist keine Option — das Ballot, das ML-DSA in öffentlichem TLS erlaubt hätte, wurde im Oktober 2026 unangenommen geschlossen. Ed25519 und ML-DSA sind weiterhin nützlich für SSH, zum Signieren und für eine private CA, und diese Seite liest Anfragen, die sie verwenden.

Dieselbe Stärke, bei zwei sehr unterschiedlichen GrößenNIST SP 800-57 Part 1 Rev 5, Table 2
StärkeRSA-SchlüsselKurve
112 Bit Sicherheit2.048 BitJede öffentliche CAKeine Kurve, die eine öffentliche Zertifizierungsstelle erlaubt, liegt auf dieser Stärke
128 Bit Sicherheit3.072 BitJede öffentliche CAP-256Jede öffentliche CA
4.096 BitJede öffentliche CA4.096 Bit steht überhaupt nicht in der Tabelle
192 Bit Sicherheit7.680 BitJede öffentliche CAP-384Jede öffentliche CA
256 Bit Sicherheit15.360 BitJede öffentliche CAP-521Jede öffentliche CA
  • RSA-Schlüssel
  • Kurve
  • Die Stufen springen direkt von einer Größe zur nächsten und überspringen die beliebte dazwischen, sodass die zusätzliche Handshake-Arbeit, die das jeden Besucher kostet, nichts bringt, was irgendwo dokumentiert wäre
  • Akzeptiert vonLet's Encrypt

Eine Kurve trägt dieselbe Stärke in einem Bruchteil der Bytes

Der veröffentlichte Vergleich, mit den zwei Dingen, die entscheiden, ob Sie einen Schlüssel tatsächlich verwenden können: was die Regeln erlauben, und was die Zertifizierungsstelle erlaubt, die Sie nutzen wollten.

Wie Sie auf jeder Plattform eine CSR erstellen

Ein einziger OpenSSL-Befehl deckt Linux, macOS und Windows mit installiertem OpenSSL ab. IIS hat certreq, macOS hat die Schlüsselbundverwaltung, und diese Website hat einen Generator, der Ihren Schlüssel nie irgendwohin sendet.

Mit OpenSSL erzeugt openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com" den Schlüssel und die Anfrage in einem Schritt. (-nodes lässt den Schlüssel unverschlüsselt. OpenSSL 3 schreibt es auch -noenc, aber das in macOS eingebaute LibreSSL kennt nur -nodes.) Danach zeigt und verifiziert openssl req -in example.com.csr -text -verify -noout sie. Unter Windows liest certreq -new request.inf request.req eine .inf-Datei, deren alternative Namen unter der OID 2.5.29.17 mit _continue_-Zeilen stehen — es gibt keinen Schlüssel SAN=. Microsofts eigene Referenzseite warnt, dass ihr Beispiel SHA-1 verwendet, was eine CA inzwischen ablehnt, setzen Sie den Hash also selbst.

Auf einem Mac schreibt Schlüsselbundverwaltung > Zertifikatsassistent > Zertifikat von einer Zertifizierungsstelle anfordern eine CSR, wobei die Schlüsselgröße hinter dem Kästchen „Schlüsselpaarinformationen angeben“ versteckt ist. Oder nutzen Sie unseren CSR-Generator, der den Schlüssel mit der Web Crypto Ihres Browsers erzeugt und Ihnen beide Dateien übergibt, ohne dass sie einen Server berühren. Keine Norm legt eine Dateiendung für eine CSR fest: .csr, .pem, .req und .txt sind alle in Gebrauch, und diese Seite liest den Inhalt, statt dem Namen zu vertrauen.

Vier Wege, eine zu erstellenOpenSSL · Microsoft Learn · Apple Support
  1. OpenSSLLinux, macOS, Windows

    Erstellt Schlüssel und Anfrage in einem einzigen Befehlopenssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com"Dann zurücklesen und die eigene Signatur verifizierenopenssl req -in example.com.csr -text -verify -noout
  2. certreqWindows Server und IIS

    Liest eine reine Textdatei; die alternativen Namen stehen in einem Erweiterungsabschnitt, je eine Zeilecertreq -new request.inf request.req[Extensions] 2.5.29.17 = "{text}" _continue_ = "DNS=example.com&" _continue_ = "DNS=www.example.com"Microsofts eigene Beispielseite ist noch um einen Hash herum geschrieben, den eine Zertifizierungsstelle inzwischen ablehnt, setzen Sie den Hash also selbst
  3. Keychain AccessmacOS

    Keychain Access › Certificate Assistant › Request a Certificate From a Certificate AuthorityIhr Mac benennt diese Menüs in seiner eigenen SpracheSchlüsseltyp und -größe verstecken sich hinter dem Kästchen, mit dem Sie das Schlüsselpaar angeben könnenRSA-Schlüssel von 2048 bis 4096 Bit; kleinere werden nicht mehr angeboten
  4. DNS RobotJeder Browser

    Erstellt den Schlüssel mit der eigenen Kryptografie Ihres Browsers und übergibt Ihnen beide Dateien, ohne dass eine davon einen Server berührtGenerator öffnen
Ein OpenSSL-Befehl funktioniert unter Linux, macOS und Windows gleichermaßen. Die anderen drei Wege sind für Rechner gedacht, auf denen er nicht zur Hand ist.

Wie lange gilt das Zertifikat?

Ein heute ausgestelltes öffentliches TLS-Zertifikat darf 200 Tage nicht überschreiten. Das sinkt im März 2027 auf 100 Tage und im März 2029 auf 47 Tage.

Der Zeitplan stammt aus dem Ballot SC-081v3 des CA/Browser Forum, angenommen im April 2025, und eine CSR kann ihn nicht beeinflussen: Die Gültigkeit kommt nie aus der Anfrage. Jede Stufe hat zwei Zahlen, eine SHOULD NOT einen Tag unter der MUST NOT — heute 199 und 200, ab dem 15.03.2027 99 und 100, ab dem 15.03.2029 46 und 47. Für die Zählung gilt: „a day is measured as 86,400 seconds“, und jeder angefangene weitere Tag zählt als ein ganzer.

Die praktische Folge ist, dass die Verlängerung automatisch laufen muss. Wenn Sie noch jedes Jahr von Hand eine CSR erstellen, ist jetzt der Zeitpunkt, auf ACME umzusteigen, wo der Client die Anfrage für Sie erstellt — und wo übrigens tatsächlich PKCS#10 verlangt wird, obwohl die Baseline Requirements selbst nur „a certificate request in a form prescribed by the CA“ fordern.

Wie lange ein Zertifikat gelten darfCA/Browser Forum TLS BR 2.3.1 §6.3.2
  1. vor 15. März 2026Wo heute steht397 Tage398 Tage
  2. ab 15. März 2026199 Tage200 Tage
  3. ab 15. März 202799 Tage100 Tage
  4. ab 15. März 202946 Tage47 Tage
  • Der gesamte Zeitplan stammt aus einem einzigen Ballot, SC-081v3, angenommen am 11. April 2025
  • Ein Tag zählt als genau 86.400 Sekunden und jeder angefangene weitere Tag zählt als ein ganzer
  • Nichts in einer Anfrage ändert etwas daran
Vier Stufen, jede mit zwei Zahlen: die eine, von der die Regeln abraten, und die, die sie verbieten. Die Daten stehen schon fest, weshalb die automatische Verlängerung die einzig praktikable Antwort ist.

Was die rohe ASN.1-Struktur zeigt

Unter dem Base64 ist eine CSR ein DER-codierter Baum. Der Decoder zeichnet ihn mit Byte-Offsets und benennt jede Objektkennung, die er kennt — genau das, was openssl asn1parse ausgibt.

Das ist der ehrliche Weg, ein Feld zu zeigen, für das niemand einen griffigen Namen hat. Öffnen Sie Rohstruktur bei einem decodierten Element, und Sie sehen die CertificationRequestInfo, die relativen distinguished Names des Antragstellers einzeln, das SubjectPublicKeyInfo, die Menge attributes [0] und darin das Attribut extensionRequest — Objektkennung 1.2.840.113549.1.9.14, definiert nicht in RFC 2986, sondern in RFC 2985 §5.4.2 — das genau die X.509-Erweiterungen aus RFC 5280 trägt.

Das andere Attribut, dem Sie dort begegnen können, ist challengePassword (1.2.840.113549.1.9.7). Es war als gemeinsames Geheimnis für einen späteren Widerruf des Zertifikats gedacht, wird noch bei der SCEP-Registrierung verwendet und spielt bei einer gewöhnlichen Bestellung eines Web-Zertifikats keine Rolle. Diese Seite zeigt es, wenn es vorhanden ist, denn ein Feld, das Sie nicht sehen, ist ein Feld, das Sie nicht prüfen können.

Dieselbe Anfrage, als BytesRFC 2986 · RFC 2985 · RFC 5280
Bei ByteStrukturGröße
0SEQUENCE749 Bytes
4SEQUENCE469 Bytes
8INTEGER03 Bytes
11SEQUENCE108 Bytes
13SET13 Bytes
15SEQUENCE11 Bytes
17OBJECT IDENTIFIERC2.5.4.65 Bytes
22PrintableStringUS4 Bytes
26SET21 Bytes
28SEQUENCE19 Bytes
30OBJECT IDENTIFIERST2.5.4.85 Bytes
35UTF8StringCalifornia12 Bytes
47SET24 Bytes
49SEQUENCE22 Bytes
51OBJECT IDENTIFIERL2.5.4.75 Bytes
56UTF8StringSan Francisco15 Bytes
71SET22 Bytes
73SEQUENCE20 Bytes
75OBJECT IDENTIFIERO2.5.4.105 Bytes
80UTF8StringExample Inc13 Bytes
93SET26 Bytes
95SEQUENCE24 Bytes
97OBJECT IDENTIFIERCN2.5.4.35 Bytes
102UTF8Stringwww.example.com17 Bytes
119SEQUENCE294 Bytes
123SEQUENCE15 Bytes
125OBJECT IDENTIFIERrsaEncryption1.2.840.113549.1.1.111 Bytes
136NULL2 Bytes
138BIT STRING2.160 Bit30 82 01 0a 02 82 01 01 00 c5 47 47 1d 26 1c bf275 Bytes
413[0]60 Bytes
415SEQUENCE58 Bytes
417OBJECT IDENTIFIERextensionRequest1.2.840.113549.1.9.1411 Bytes
428SET45 Bytes
430SEQUENCE43 Bytes
432SEQUENCE41 Bytes
434OBJECT IDENTIFIERSubject Alternative Name2.5.29.175 Bytes
439OCTET STRING32 Bytes30 1e 82 0f 77 77 77 2e 65 78 61 6d 70 6c 65 2e34 Bytes
473SEQUENCE15 Bytes
475OBJECT IDENTIFIERsha256WithRSAEncryption1.2.840.113549.1.1.1111 Bytes
486NULL2 Bytes
488BIT STRING2.048 Bit00 57 41 c5 09 98 14 78 8c ee c3 61 d4 c0 e0 2d261 Bytes
  • Enthält andere Dinge
  • Enthält einen Wert
  • Benannt nach seiner Position
  • Das Attribut, das die Erweiterungen trägt

    1.2.840.113549.1.9.14Es ist in einem anderen Dokument definiert als dem, das die Anfrage selbst definiert, weshalb die alternativen Namen innerhalb eines Attributs reisen, statt neben dem Antragsteller zu stehen
  • Das andere Attribut, dem Sie begegnen könnenNicht in dieser Anfrage

    1.2.840.113549.1.9.7Ein gemeinsames Geheimnis, gedacht für einen späteren Antrag auf Widerruf des Zertifikats, noch verwendet, wenn sich ein Gerät selbst in einem Netzwerk registriert
Jedes Byte der Beispielanfrage, mit jeder benannten Objektkennung. Das ist, was ein Kommandozeilen-Decoder ausgibt, gezeichnet statt gedruckt, damit Sie sehen, wo ein Feld endet und das nächste beginnt.

CSR-Decoder: Fragen und Antworten

Wie decodiere ich eine CSR?

Fügen Sie die gesamte Anfrage in das Feld oben ein, einschließlich der Zeilen -----BEGIN CERTIFICATE REQUEST----- und -----END CERTIFICATE REQUEST-----, oder lassen Sie die Datei auf der Seite los. Sie wird decodiert, während Sie einfügen: der Antragsteller, der öffentliche Schlüssel, jeder Subject Alternative Name, jede angeforderte Erweiterung und die Fingerabdrücke. Sie können auch nur den Base64-Body einfügen, einen Hex-Dump, oder eine binäre DER-Datei hochladen.

Ist dieser CSR-Decoder sicher zu verwenden?

Ja, aus zwei Gründen. Eine CSR enthält kein Geheimnis — sie ist dafür gedacht, an eine Zertifizierungsstelle gesendet zu werden —, daher ist es harmlos, sie irgendwo zu decodieren. Und diese Seite erledigt die Arbeit in Ihrem Browser: Die Anfrage wird von Code ausgewertet, der mit der Seite heruntergeladen wurde, und nichts wird an irgendeinen Server gesendet. Fügen Sie aus Versehen einen privaten Schlüssel ein, sagt Ihnen die Seite das, verweigert die Decodierung und behält nichts davon.

Wie prüfe ich, ob meine CSR gültig ist?

Decodieren Sie sie hier und lesen Sie das Urteil. Die Seite prüft die eigene Signatur der Anfrage, die beweist, dass der Absender den passenden privaten Schlüssel besitzt, und wendet dann die Regeln an, die eine öffentliche Zertifizierungsstelle anwendet: Namen, die sie nicht zertifizieren darf, zu weit gefasste Wildcards, reservierte IP-Adressen, zu kleine oder faktorisierbare Schlüssel, veraltete Antragsteller-Felder und überholte Signatur-Hashes. Jeder Befund sagt, ob die CA die Anfrage ablehnt, ändert oder einfach mit den Schultern zuckt.

Warum lehnt meine Zertifizierungsstelle meine CSR ab?

Die häufigsten Ursachen sind ein interner Name wie server.local oder ein einteiliger Hostname, ein Unterstrich in einem Hostnamen, eine Wildcard über einem öffentlichen Suffix wie *.co.uk, eine private IP-Adresse unter den alternativen Namen, ein RSA-Schlüssel unter 2048 Bit, oder eine Anfrage, die noch mit SHA-1 signiert ist. Decodieren Sie die Anfrage oben, und jede davon wird ausdrücklich benannt, mit der Regel, gegen die sie verstößt.

Woher weiß ich, dass mein privater Schlüssel zu meiner CSR passt?

Nutzen Sie oben Schlüssel oder Zertifikat abgleichen: Fügen Sie den Schlüssel neben der Anfrage hinzu, und die Seite vergleicht den öffentlichen Schlüssel in der Schlüsseldatei mit dem in der Anfrage, in Ihrem Browser. Oder führen Sie es selbst aus — openssl req -in request.csr -pubkey -noout und openssl pkey -in private.key -pubout geben denselben öffentlichen Schlüssel aus, wenn sie zusammenpassen. Derselbe Vergleich funktioniert auch zwischen einem Schlüssel und einem ausgestellten Zertifikat.

Kann das auch ein SSL-Zertifikat decodieren?

Ja. Fügen Sie ein Zertifikat ein, und es wird als Zertifikat decodiert: Aussteller und Antragsteller, Seriennummer, Gültigkeitsdaten, jeder alternative Name, Schlüsselverwendung und erweiterte Schlüsselverwendung, die Schlüsselkennungen von Aussteller und Antragsteller, OCSP- und CA-Issuers-URLs, Zertifikatsrichtlinien und eingebettete Certificate-Transparency-Zeitstempel. Fügen Sie ein Zertifikat und seine Anfrage zusammen ein, und die Seite sagt Ihnen außerdem, ob sie denselben Schlüssel teilen.

Welche Felder nutzt eine Zertifizierungsstelle aus meiner CSR tatsächlich?

Zuverlässig eines: den öffentlichen Schlüssel. DigiCerts eigene Dokumentation sagt, dass der Rest ignoriert wird. Bei einem OV- oder EV-Zertifikat muss die CA Organisation und Land selbst validieren, bevor sie aufgenommen werden; Gültigkeitsdaten kommen immer aus dem Zeitplan der Baseline Requirements, nie aus der Anfrage. Zwei Felder sind in einem öffentlichen TLS-Zertifikat nicht nur ignoriert, sondern verboten: OU und, bei domainvalidierten Zertifikaten, emailAddress.

Spielt der allgemeine Name noch eine Rolle?

Nur als Kopie von etwas anderem. Browser ignorieren den allgemeinen Namen für den Hostabgleich seit 2017 und nutzen ausschließlich die Subject Alternative Names. Die Baseline Requirements markieren den allgemeinen Namen als NOT RECOMMENDED und verlangen, dass er, falls vorhanden, „MUST contain exactly one entry that is one of the values contained in the Certificate's subjectAltName extension“ erfüllt. Ein allgemeiner Name, der nicht unter Ihren alternativen Namen ist, führt zur Ablehnung, und diese Seite meldet ihn.

Kann ich mehrere Dateien auf einmal decodieren?

Ja. Fügen Sie eine Anfrage, ihr Zertifikat und die Zwischenzertifikate zusammen ein, und jeder Block wird auf seiner eigenen Karte decodiert, in der Reihenfolge, in der Sie sie eingefügt haben. Ein beschädigter Block hält die anderen nicht auf. Steckt irgendwo im Eingefügten ein privater Schlüssel, wird er benannt und übersprungen, nie decodiert. Bis zu vierzig Blöcke werden decodiert, und alles darüber hinaus wird gezählt und gemeldet, statt stillschweigend verworfen zu werden.

Was ist ein Challenge Password in einer CSR?

Ein optionales Attribut aus RFC 2985, ursprünglich ein gemeinsames Geheimnis, das Sie beim Antrag auf Widerruf des Zertifikats angeben würden. Es spielt noch bei der SCEP-Registrierung eine Rolle, wo ein Gerät nachweist, dass es fragen darf. Bei einer gewöhnlichen Bestellung eines Web-Zertifikats spielt es keine Rolle, und weil es ein Feld ist, das nur wenige Werkzeuge anzeigen, zeigt diese Seite es, sobald eine Anfrage eines trägt.

Kann ich einen Ed25519-Schlüssel für ein öffentliches Zertifikat verwenden?

Heute nicht. Die Baseline Requirements erlauben RSA und die Kurven P-256, P-384 und P-521 und legen dann fest, dass „no other algorithms or key sizes are permitted“, daher stellt keine öffentliche Zertifizierungsstelle gegen eine Ed25519-Anfrage aus. Er ist ein guter Schlüssel für SSH, zum Signieren und für eine private CA, und dieser Decoder liest Ed25519- und Ed448-Anfragen sowie Post-Quanten-ML-DSA-Schlüssel klaglos.

Wie lange ist ein Zertifikat jetzt gültig?

Ein heute ausgestelltes öffentliches TLS-Zertifikat darf 200 Tage nicht überschreiten, gegenüber 398 vor dem 15.03.2026. Es sinkt am 15.03.2027 auf 100 Tage und am 15.03.2029 auf 47 Tage, nach Ballot SC-081v3 des CA/Browser Forum. Nichts in einer CSR beeinflusst das; die Gültigkeit wird von der CA festgelegt. Bei diesen Längen muss die Verlängerung automatisiert sein, was in der Praxis ACME bedeutet.

Fehlt Ihnen etwas?Funktion oder neues Tool vorschlagen