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.
Wird in Ihrem Browser decodiert. Nichts wird hochgeladen, nichts wird gespeichert.
Lassen Sie die Datei irgendwo auf dieser Seite los PEM, DER, .csr, .cer, .crt, .pem, .req, .txt
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.
- Hülle4 Bytes
- Der signierte Teil469 Bytes
- Welcher Signaturalgorithmus15 Bytes
- Die Signatur selbst261 Bytes
- Version3 BytesImmer null: die einzige Version, die das Format definiert
- Antragsteller-Name108 BytesDer Distinguished Name, den Sie in das Formular eingegeben haben
- Ihr öffentlicher Schlüssel294 BytesAlgorithmus, Größe und der Schlüssel — das eine Feld, das eine Zertifizierungsstelle garantiert nutzt
- 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

Einfü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.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.
- Die NamenJeder Name, den das Zertifikat abdecken würde, und ob der allgemeine Name darunter ist
- Die SignaturGeprüft mit der eigenen Kryptografie Ihres Browsers
- 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
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.
| In Ihrer Anfrage | Was damit geschieht | Warum |
|---|---|---|
| Öffentlicher SchlüsselSubjectPublicKeyInfo | Übernommen, wie gesendet | Das eine, das eine Zertifizierungsstelle garantiert von Ihnen übernimmt |
| Alternative NamensubjectAltName2.5.29.17 | Übernommen, wie gesendet | Die CA bestätigt, dass Sie jeden Namen kontrollieren, bevor sie auch nur einen davon aufschreibt |
| Allgemeiner NameCN2.5.4.3 | Validiert, dann von der CA geschrieben | Nicht empfohlen; wenn vorhanden, muss er exakt einen der alternativen Namen wiederholen |
| Organisation, Ort, BundeslandO, L, ST2.5.4.10 | Validiert, dann von der CA geschrieben | Bei einem organisationsvalidierten Zertifikat stammen diese aus den eigenen validierten Datensätzen der CA, nicht aus dem, was Sie eingegeben haben |
| LandC2.5.4.6 | Validiert, dann von der CA geschrieben | Darf vorkommen, unabhängig von der Validierungsstufe |
| OrganisationseinheitOU2.5.4.11 | Überhaupt nicht erlaubt | In einem öffentlichen Zertifikat verboten seit 1. September 2022 |
| E-Mail-AdresseemailAddress1.2.840.113549.1.9.1 | Überhaupt nicht erlaubt | In einem domainvalidierten Zertifikat nicht zulässig |
| Gültig von, gültig bisnotBefore, notAfter | Kommt nie aus der Anfrage | Festgelegt 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.“
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.
server.localEin interner NameEr endet nicht auf eine Top-Level-Domain, die in der öffentlichen Root-Zone existiert, sodass niemand beweisen kann, dass er Ihnen gehörtAbgelehntintranetEin einzelnes LabelEin Name ganz ohne Punkt fällt unter dieselbe DefinitionAbgelehntmy_host.example.comEin UnterstrichEin Label darf nur Buchstaben, Ziffern und Bindestriche enthalten, sonst nichtsAbgelehnt*.co.ukEine Wildcard über eine ganze RegistryEine Wildcard darf nur das am weitesten links stehende Label ersetzen, niemals ein öffentliches SuffixAbgelehnt192.168.1.10Eine reservierte AdresseEine öffentliche Adresse kann zertifiziert werden; eine aus einem privaten oder Sonderbereich nieAbgelehntexample.com.Ein abschließender PunktDas leere Root-Label darf nicht ausgeschrieben werdenAbgelehnt
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.
- 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
openssl req -in request.csr -pubkey -nooutopenssl pkey -in private.key -puboutIdentische Ausgabe bedeutet, dass sie zusammenpassenCSR, 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.
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
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.
Diese Seite
- Die Datei wird gelesen
- Sie wird von Code zerlegt, der mit der Seite ankam
- Die Signatur wird vom Browser selbst geprüft
- 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
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.“
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
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.
| Stärke | RSA-Schlüssel | Kurve |
|---|---|---|
| 112 Bit Sicherheit | 2.048 BitJede öffentliche CA | Keine Kurve, die eine öffentliche Zertifizierungsstelle erlaubt, liegt auf dieser Stärke |
| 128 Bit Sicherheit | 3.072 BitJede öffentliche CA | P-256Jede öffentliche CA |
| 4.096 BitJede öffentliche CA4.096 Bit steht überhaupt nicht in der Tabelle | ||
| 192 Bit Sicherheit | 7.680 BitJede öffentliche CA | P-384Jede öffentliche CA |
| 256 Bit Sicherheit | 15.360 BitJede öffentliche CA | P-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
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.
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 -nooutcertreqWindows 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 selbstKeychain 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 angebotenDNS 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
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.
- vor 15. März 2026Wo heute steht397 Tage398 Tage
- ab 15. März 2026199 Tage200 Tage
- ab 15. März 202799 Tage100 Tage
- 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
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.
| Bei Byte | Struktur | Größe |
|---|---|---|
| 0 | SEQUENCE | 749 Bytes |
| 4 | SEQUENCE | 469 Bytes |
| 8 | INTEGER0 | 3 Bytes |
| 11 | SEQUENCE | 108 Bytes |
| 13 | SET | 13 Bytes |
| 15 | SEQUENCE | 11 Bytes |
| 17 | OBJECT IDENTIFIERC2.5.4.6 | 5 Bytes |
| 22 | PrintableStringUS | 4 Bytes |
| 26 | SET | 21 Bytes |
| 28 | SEQUENCE | 19 Bytes |
| 30 | OBJECT IDENTIFIERST2.5.4.8 | 5 Bytes |
| 35 | UTF8StringCalifornia | 12 Bytes |
| 47 | SET | 24 Bytes |
| 49 | SEQUENCE | 22 Bytes |
| 51 | OBJECT IDENTIFIERL2.5.4.7 | 5 Bytes |
| 56 | UTF8StringSan Francisco | 15 Bytes |
| 71 | SET | 22 Bytes |
| 73 | SEQUENCE | 20 Bytes |
| 75 | OBJECT IDENTIFIERO2.5.4.10 | 5 Bytes |
| 80 | UTF8StringExample Inc | 13 Bytes |
| 93 | SET | 26 Bytes |
| 95 | SEQUENCE | 24 Bytes |
| 97 | OBJECT IDENTIFIERCN2.5.4.3 | 5 Bytes |
| 102 | UTF8Stringwww.example.com | 17 Bytes |
| 119 | SEQUENCE | 294 Bytes |
| 123 | SEQUENCE | 15 Bytes |
| 125 | OBJECT IDENTIFIERrsaEncryption1.2.840.113549.1.1.1 | 11 Bytes |
| 136 | NULL | 2 Bytes |
| 138 | BIT STRING2.160 Bit30 82 01 0a 02 82 01 01 00 c5 47 47 1d 26 1c bf | 275 Bytes |
| 413 | [0] | 60 Bytes |
| 415 | SEQUENCE | 58 Bytes |
| 417 | OBJECT IDENTIFIERextensionRequest1.2.840.113549.1.9.14 | 11 Bytes |
| 428 | SET | 45 Bytes |
| 430 | SEQUENCE | 43 Bytes |
| 432 | SEQUENCE | 41 Bytes |
| 434 | OBJECT IDENTIFIERSubject Alternative Name2.5.29.17 | 5 Bytes |
| 439 | OCTET STRING32 Bytes30 1e 82 0f 77 77 77 2e 65 78 61 6d 70 6c 65 2e | 34 Bytes |
| 473 | SEQUENCE | 15 Bytes |
| 475 | OBJECT IDENTIFIERsha256WithRSAEncryption1.2.840.113549.1.1.11 | 11 Bytes |
| 486 | NULL | 2 Bytes |
| 488 | BIT STRING2.048 Bit00 57 41 c5 09 98 14 78 8c ee c3 61 d4 c0 e0 2d | 261 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 stehenDas 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
CSR-Decoder: Fragen und Antworten
Wie decodiere ich eine CSR?
-----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?
Wie prüfe ich, ob meine CSR gültig ist?
Warum lehnt meine Zertifizierungsstelle meine CSR ab?
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?
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?
Welche Felder nutzt eine Zertifizierungsstelle aus meiner CSR tatsächlich?
OU und, bei domainvalidierten Zertifikaten, emailAddress.Spielt der allgemeine Name noch eine Rolle?
Kann ich mehrere Dateien auf einmal decodieren?
Was ist ein Challenge Password in einer CSR?
Kann ich einen Ed25519-Schlüssel für ein öffentliches Zertifikat verwenden?
Wie lange ist ein Zertifikat jetzt gültig?
Fehlt Ihnen etwas?Funktion oder neues Tool vorschlagen
Verwandte Tools
CSR-Generator
Zertifikatsignierungsanforderung und privaten Schlüssel im Browser erstellen: RSA oder ECDSA, mit SANs und passendem OpenSSL-Befehl
SSL-Zertifikat-Check
Gültigkeit und Sicherheitsdetails des SSL-Zertifikats überprüfen
DNS-Health-Check
DNS einer Domain bewerten: Delegation, Nameserver, SOA, DNSSEC, Mail · 40 Tests
DMARC-Check
DMARC-Richtlinie und Alignment-Einstellungen für jede Domain prüfen
DNS-Abfrage
Alle DNS-Einträge direkt von den Nameservern der Domain, neben dem Cache von Google und Cloudflare
WHOIS-Abfrage
Domain-Registrierung, Registrar und Inhaberdetails über RDAP nachschlagen
