Theme

Popular tools

CSR Decoder and CSR Checker

Paste a certificate signing request and read every field it holds: the subject, the key, every alternative name and every extension. The page also checks the request against the rules a public CA applies, and tells you whether your private key matches it. An SSL certificate decodes here too.

Decoded in your browser with Web Crypto · nothing is uploaded, nothing is stored · CA/Browser Forum Baseline Requirements v2.3.1

Decoded in your browser. Nothing is uploaded, nothing is stored.
Drop the file anywhere on this page PEM, DER, .csr, .cer, .crt, .pem, .req, .txt

Try one

Everything on this page happens in your browser. Open your network panel and watch: no request carries your data.

What is a CSR?

A certificate signing request is a small signed file that asks a certificate authority for a certificate. It carries your public key, the names you want on the certificate, and a signature made with your private key.

The format is PKCS#10, written down in RFC 2986. The part that gets signed holds only four things: a version number, a subject name, a SubjectPublicKeyInfo holding your public key, and a set of attributes. The whole of that is then signed by the private key that goes with the public key inside it, so a CSR is self-signed. That signature is the proof of possession: anyone can read your public key, but only the holder of the private key can sign a request that verifies against it.

Your private key is not in the file and never should be. A CSR is safe to email, to paste into a CA's web form, and to decode here — which is why this page can do all of its work in your browser without sending anything anywhere.

One request, byte by byteRFC 2986 · PKCS#10

The whole file

  • Wrapper4 bytes
  • The part that gets signed469 bytes
  • Which signature algorithm15 bytes
  • The signature itself261 bytes

Inside the part that gets signed

  1. Version3 bytesAlways zero: the only version the format defines
  2. Subject name108 bytesThe distinguished name you typed into the form
  3. Your public key294 bytesAlgorithm, size and the key — the one field a certificate authority is certain to use
  4. Attributes60 bytesWhere the alternative names you asked for travel

Your private keysigns the part aboveProof that you hold the matching private key · The signature covers that part alone, not the whole file

The example request this page offers, 749 bytes of it. Four things go into the part that gets signed; the private key matching the public key inside signs exactly that part, and what comes out is the last 261 bytes.
CSR decoder result: a decoded certificate signing request with its subject, key, alternative names and CA rule findingsCSR decoder result: a decoded certificate signing request with its subject, key, alternative names and CA rule findingsPaste or dropA CSR, a certificate or a public key — PEM, base64, a hex dump or a file. Several at once is fine.The verdictWhat a public CA does with this request: issue it, change it, or refuse it, with the reason for each.The namesEvery name the certificate would cover, with the common name checked against them.The key and the signatureAlgorithm, size, curve and exponent, and whether the request's own signature holds.Match a keyAdd the private key or the issued certificate to see whether it belongs to this request. Neither leaves your browser.
A certificate signing request taken apart: the verdict, the names it asks for, the key behind it, and a place to match your own key. Select a number to see what each part shows.

How to check a CSR before you send it

Three things are worth checking: that the names are the ones you meant, that the signature verifies, and that nothing in it breaks a rule your CA applies.

Paste the request above. The page reads the subject attribute by attribute, lists every subject alternative name, shows the key's algorithm and size, and then checks the request's own signature. A request whose signature does not verify has been edited, truncated or corrupted since it was made — regenerate it rather than send it.

After that come the rules. A certificate authority applies the CA/Browser Forum's Baseline Requirements, and a request that breaks one of them is refused or quietly changed. The findings on this page are marked must fix when the CA cannot issue what you asked for, will be changed when it will issue but strip or alter a field, and worth knowing when nothing is wrong but something deserves a look.

Three checks, in the order they runCA/Browser Forum TLS BR 2.3.1
  1. The namesEvery name the certificate would cover, and whether the common name is among them
  2. The signatureVerified with your browser's own cryptography
  3. The certificate authority's rulesApplied one at a time, each with the document it comes from
  • Send itNothing in the request breaks a rule
  • It will be refusedThe file is sound; what it asks for is not allowed
  • Make it againA signature that does not verify means the file was edited, truncated or copied badly after it was made
The first two checks are about the file itself and the third is about what a certificate authority permits. A request can pass both of the first two and still be refused.

What is in a CSR — and what your CA actually uses

Of everything in a CSR, a public CA reliably uses one field: the public key. Most of the rest it validates itself, overwrites, or is forbidden to copy.

DigiCert puts it plainly in its own documentation: "DigiCert uses the public key embedded in the CSR to create your client certificate. All other fields in the CSR are ignored." On an OV or EV certificate the CA has to validate the organisation, locality and country itself before they go in; what you typed is not taken on trust. Validity dates are never taken from a request: they follow the Baseline Requirements' schedule.

Two subject fields are not merely ignored but prohibited. organizationalUnitName (OU) must not appear in a public TLS certificate — under CA/Browser Forum ballot SC047 no certificate issued since 1 September 2022 may carry it — and emailAddress is not permitted in a domain-validated certificate at all. A common name is allowed but discouraged, and if it is present it must repeat one of the subject alternative names exactly. That last rule is why this page flags a common name that is missing from the SAN list.

What a certificate authority does with each fieldCA/Browser Forum TLS BR 2.3.1
In your requestWhat becomes of itWhy
Public keySubjectPublicKeyInfoUsed as you sent itThe one thing a certificate authority is certain to take from you
Alternative namessubjectAltName2.5.29.17Used as you sent itThe CA confirms you control each name before it writes any of them down
Common nameCN2.5.4.3Validated, then written by the CADiscouraged; if it is there it must repeat one of the alternative names exactly
Organisation, locality, stateO, L, ST2.5.4.10Validated, then written by the CAOn an organisation-validated certificate these come from the CA's own validated records, not from what you typed
CountryC2.5.4.6Validated, then written by the CAMay appear, whatever the validation level
Organisational unitOU2.5.4.11Not allowed at allProhibited in a public certificate since September 1, 2022
Email addressemailAddress1.2.840.113549.1.9.1Not allowed at allNot permitted in a domain-validated certificate
Valid from, valid tonotBefore, notAfterNever comes from the requestSet by the schedule the certificate authority follows, never by your request

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

DigiCert, its own documentation
The fields people agonise over, and what each is actually worth. Your key and your names survive; whatever you type, the organisational unit cannot appear at all and an email address cannot appear on a domain-validated certificate; and the dates were never yours to set.

Why a CA rejects a CSR

Almost every rejection comes down to a name a CA may not certify, a wildcard that is too broad, a reserved IP address, a key that is too small, a signature hash that is too old, or a request whose signature does not verify.

A certificate authority may not issue for an internal name — one that "does not end with a Top-Level Domain registered in IANA's Root Zone Database". That catches server.local, intranet, a single-label name with no dot at all, and any made-up suffix. Labels must be letters, digits and hyphens, so an underscore in a host name is refused, and a name must not be written with a trailing dot. A wildcard may only replace the whole left-most label, and never a public suffix: *.example.com is fine, *.co.uk is not. An IP address may appear, but not a reserved one — no 10.0.0.0/8, 192.168.0.0/16, 127.0.0.1 or fc00::/7.

On keys, the Baseline Requirements are exact: an RSA modulus of at least 2048 bits, evenly divisible by 8, or a point on P-256, P-384 or P-521, and "no other algorithms or key sizes are permitted". A CA must also refuse a key it can factor, including one "which can be factored within 100 rounds using Fermat's factorization method" — this page runs that test on the key in your request. And although a CSR's own signature hash is not the certificate's, Let's Encrypt stopped accepting SHA-1 self-signatures in 2022, so an old tool that still signs with SHA-1 will have its request turned away.

Names a certificate authority will not certifyCA/Browser Forum TLS BR 2.3.1
  • server.local
    An internal nameIt does not end in a top-level domain that exists in the public root zone, so nobody can prove it is yours
    Refused
  • intranet
    A single labelA name with no dot at all falls under the same definition
    Refused
  • my_host.example.com
    An underscoreA label may hold letters, digits and hyphens, and nothing else
    Refused
  • *.co.uk
    A wildcard over a whole registryA wildcard may stand in for the left-most label, never for a public suffix
    Refused
  • 192.168.1.10
    A reserved addressA public address can be certified; one from a private or special-purpose range never can
    Refused
  • example.com.
    A trailing dotThe empty root label must not be written out
    Refused
Six names, each breaking a different rule — and every one a rejection you could have seen before you sent the request.

How do I know my private key matches my CSR?

A private key file already carries its own public key, so the match is a comparison of two public keys — no secret is needed and nothing has to be sent anywhere.

Open Match a key or certificate above and add the key beside the request. The page reads only the public half out of the file — PKCS#8, PKCS#1 and SEC1 keys are all understood — compares it with the key in the request, and answers. Nothing is uploaded, nothing is kept, and the key is cleared when you leave the field. The same check works between a request and the certificate that came back from the CA, which catches "the certificate and the private key do not match" before a server refuses to start.

If you would rather not paste a key into any web page, the same answer is two commands on your own machine. openssl req -in request.csr -pubkey -noout prints the public key from the request and openssl pkey -in private.key -pubout prints it from the key: identical output means they match. The older -modulus form works for RSA keys only; -pubkey works for every key type.

Two files, one comparisonRFC 2986 · OpenSSL manual
Your browser
  • The private key fileThe file you must never send anywhereIts public half is read out
  • The requestThe file you send to the certificate authorityIt already carries the public key

Are these the same key?

  • They matchThe certificate that comes back will install against this key
  • They do not matchThis is the mismatch a web server reports when it refuses to start

Nothing crosses this line · The comparison works with the network switched offAnywhere else

Or do it on your own machineopenssl req -in request.csr -pubkey -nooutopenssl pkey -in private.key -puboutIdentical output means they match
A private key file already carries its own public key, so the question is settled by comparing two public keys. No secret has to move for that, and none does.

CSR, certificate, private key: what is the difference?

The private key is the secret. The CSR is a request that proves you hold it. The certificate is the CA's signed answer, and it is the only one of the three that is public by design.

The three files are often in the same folder with confusingly similar names. A private key begins -----BEGIN PRIVATE KEY----- or -----BEGIN RSA PRIVATE KEY----- and must never be sent to anyone, including a certificate authority. A certificate signing request begins -----BEGIN CERTIFICATE REQUEST-----, is signed by that key, and is safe to send. A certificate begins -----BEGIN CERTIFICATE-----, is signed by the CA, and is sent to every visitor of your site anyway.

Once the certificate has been issued, the request has no further use: it is not needed to install, renew or revoke anything. The key is what you must keep, and keep safe. Paste any of the three above and this page will tell you which one it is. For a certificate or a whole chain you received, the certificate decoder goes further: it checks each link and whether the major browsers' root stores trust it.

Three files, one folder, confusingly similar namesRFC 7468

  • The private keySecret

    Its first line-----BEGIN PRIVATE KEY-----Also in wide use-----BEGIN RSA PRIVATE KEY-----

    Signed by
    Nothing — it is what does the signing
    Who may see it
    You, and nobody else
    What it is for
    Proves that this server is the one the certificate was issued to

  • The certificate signing requestPublic

    Its first line-----BEGIN CERTIFICATE REQUEST-----Also in wide use-----BEGIN NEW CERTIFICATE REQUEST-----

    Signed by
    Itself, with the private key
    Who may see it
    You and the certificate authority
    What it is for
    Asks for a certificate, and proves you hold the key it is for

  • The certificatePublic

    Its first line-----BEGIN CERTIFICATE-----

    Signed by
    The certificate authority
    Who may see it
    Every visitor to your site
    What it is for
    Tells a browser that this key belongs to these names

.csr.pem.req.txtNo standard assigns a request a file extension; all of these are in use, and this page reads the contents rather than the name

Only the first of the three is a secret. The last one is handed to every visitor anyway, and the middle one has no further use the moment the certificate arrives.

Is it safe to decode a CSR online?

A CSR holds no secret, so decoding one anywhere is harmless. A private key is a different matter, and that is the file people confuse it with.

Everything on this page runs in your browser. The request is parsed by code that was downloaded with the page, the signature is checked with your browser's own Web Crypto, and no request is made to any server with your data in it — you can watch the network panel while you use it. That is a property of how the page is built, not a promise we are asking you to take on trust.

The reason it matters is the file next to the CSR. The CA/Browser Forum's own definition is unforgiving: "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." No misuse is needed — reaching someone else's server is enough. In 2020 DigiCert found 337 private keys that customers had pasted in alongside their CSRs and revoked every certificate involved, writing that "by sending the private key to DigiCert along with the CSR, the customer has compromised the private key". If this page ever reads a private key you paste, it says so, refuses to decode it, and keeps none of it.

Where the file actually goesCA/Browser Forum TLS BR 2.3.1

This page

Your browser
  1. The file is read
  2. It is taken apart by code that arrived with the page
  3. The signature is checked by the browser itself
  4. The result is drawn

No request leaves with your data in itOpen the network panel and watch while you use it

A page that uploads it

Your browser

The file is uploaded…together with whatever was pasted beside it

Someone else's server

A private key that arrives there is compromised by that alone

“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.”

the definition the certificate authorities wrote for themselves

It has already happenedIn 2020 one certificate authority found 337 private keys pasted in beside a requestEvery certificate involved was revoked

Nothing in a request is secret, so decoding one anywhere is harmless. The file people confuse it with is a different matter, and the damage needs no misuse at all — being seen is enough.

RSA or ECDSA: which key should a CSR ask for?

An ECDSA P-256 key is as strong as an RSA 3072-bit key and much smaller, so it is the better default. RSA 2048 remains universally accepted.

NIST puts P-256 and RSA-3072 at the same 128-bit security strength, and its table has no row for RSA-4096 at all: the next row is RSA-7680, at 192 bits, the level P-384 reaches. So a 4096-bit RSA key costs every visitor extra handshake work for no documented gain over 3072. The Baseline Requirements allow P-521 as well, but Let's Encrypt refuses it, so a P-521 request can be perfectly legal and still fail at the CA you were going to use.

Ed25519 is not an option for a public TLS certificate today, however good the algorithm is: the Baseline Requirements list RSA and the three NIST curves and add "no other algorithms or key sizes are permitted". Nor is a post-quantum key — the ballot that would have allowed ML-DSA in public TLS was closed unmerged in October 2026. Ed25519 and ML-DSA are still useful for SSH, for signing, and for a private CA, and this page reads requests that use them.

The same strength, at two very different sizesNIST SP 800-57 Part 1 Rev 5, Table 2
StrengthRSA keyCurve
112 bits of security2,048 bitsAny public CANo curve a public certificate authority allows sits at this strength
128 bits of security3,072 bitsAny public CAP-256Any public CA
4,096 bitsAny public CA4,096 bits is not in the table at all
192 bits of security7,680 bitsAny public CAP-384Any public CA
256 bits of security15,360 bitsAny public CAP-521Any public CA
  • RSA key
  • Curve
  • The steps go straight from one size to the next and skip the popular one in between, so the extra handshake work it costs every visitor buys nothing anybody has written down
  • Accepted byLet's Encrypt

A curve carries the same strength in a fraction of the bytes

The published comparison, with the two things that decide whether you can actually use a key: what the rules permit, and what the certificate authority you were going to use permits.

How to make a CSR on any platform

One OpenSSL command covers Linux, macOS and Windows with OpenSSL installed. IIS has certreq, macOS has Keychain Access, and this site has a generator that never sends your key anywhere.

With OpenSSL, 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" makes the key and the request in one step. (-nodes leaves the key unencrypted. OpenSSL 3 also spells it -noenc, but the LibreSSL built into macOS knows only -nodes.) Then openssl req -in example.com.csr -text -verify -noout shows and verifies it. On Windows, certreq -new request.inf request.req reads an .inf file whose alternative names go under OID 2.5.29.17 with _continue_ lines — there is no SAN= key. Microsoft's own reference page warns that its example uses SHA-1, which a CA will now refuse, so set the hash yourself.

On a Mac, Keychain Access > Certificate Assistant > Request a Certificate From a Certificate Authority writes one, with the key size behind the "Let me specify key pair information" box. Or use our CSR generator, which makes the key with your browser's Web Crypto and hands you both files without them touching a server. No standard assigns a file extension to a CSR: .csr, .pem, .req and .txt are all in use, and this page reads the contents rather than trusting the name.

Four ways to make oneOpenSSL · Microsoft Learn · Apple Support

  1. OpenSSLLinux, macOS, Windows

    Makes the key and the request in a single commandopenssl 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"Then read it back and verify its own signatureopenssl req -in example.com.csr -text -verify -noout

  2. certreqWindows Server and IIS

    Reads a plain text file; the alternative names go in an extensions section, one line eachcertreq -new request.inf request.req[Extensions] 2.5.29.17 = "{text}" _continue_ = "DNS=example.com&" _continue_ = "DNS=www.example.com"Microsoft's own example page is still written around a hash a certificate authority now refuses, so set the hash yourself

  3. Keychain AccessmacOS

    Keychain Access › Certificate Assistant › Request a Certificate From a Certificate AuthorityYour Mac names these menus in its own languageKey type and size hide behind the box that lets you specify the key pairRSA keys from 2048 to 4096 bits; smaller ones are no longer offered

  4. DNS RobotAny browser

    Makes the key with your browser's own cryptography and hands you both files without either touching a serverOpen the generator
One OpenSSL command works on Linux, macOS and Windows alike. The other three routes are for machines where it is not to hand.

How long will the certificate last?

A public TLS certificate issued today may not exceed 200 days. That falls to 100 days in March 2027 and to 47 days in March 2029.

The schedule comes from CA/Browser Forum ballot SC-081v3, adopted in April 2025, and it is not something a CSR can influence: validity never comes from the request. Each step has two numbers, a SHOULD NOT one day below the MUST NOT — 199 and 200 today, 99 and 100 from 2027-03-15, 46 and 47 from 2029-03-15. For the purpose of the count, "a day is measured as 86,400 seconds", and any part of a further day counts as a whole one.

The practical consequence is that renewal has to be automatic. If you are still making a CSR by hand every year, now is the time to move to ACME, where the client makes the request for you — and where, incidentally, PKCS#10 really is required, even though the Baseline Requirements themselves only ask for "a certificate request in a form prescribed by the CA".

How long a certificate may lastCA/Browser Forum TLS BR 2.3.1 §6.3.2
  1. before March 15, 2026Where today sits397 days398 days
  2. from March 15, 2026199 days200 days
  3. from March 15, 202799 days100 days
  4. from March 15, 202946 days47 days
  • The whole schedule comes from one ballot, SC-081v3, adopted April 11, 2025
  • A day is counted as exactly 86,400 seconds and any part of a further day counts as a whole one
  • Nothing in a request changes any of this
Four steps, each with two numbers: the one the rules discourage and the one they forbid. The dates are already fixed, which is what makes automatic renewal the only workable answer.

What the raw ASN.1 shows you

Under the base64, a CSR is a DER-encoded tree. The decoder draws it with byte offsets and names every object identifier it knows, which is what openssl asn1parse prints.

It is the honest way to show a field nobody has a friendly name for. Open Raw structure on any decoded item and you can see the CertificationRequestInfo, the subject's relative distinguished names one by one, the SubjectPublicKeyInfo, the attributes [0] set and, inside it, the extensionRequest attribute — object identifier 1.2.840.113549.1.9.14, defined not in RFC 2986 but in RFC 2985 §5.4.2 — carrying the very X.509 extensions of RFC 5280.

The other attribute you may meet there is challengePassword (1.2.840.113549.1.9.7). It was meant as a shared secret for revoking a certificate later, is still used by SCEP enrolment, and plays no part in a normal web certificate order. This page shows it when it is there, because a field you cannot see is a field you cannot check.

The same request, as bytesRFC 2986 · RFC 2985 · RFC 5280
At byteStructureSize
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 bits30 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 bits00 57 41 c5 09 98 14 78 8c ee c3 61 d4 c0 e0 2d261 bytes
  • Holds other things
  • Holds a value
  • Named by its position

  • The attribute that carries the extensions

    1.2.840.113549.1.9.14It is defined in a different document from the one that defines the request itself, which is why the alternative names travel inside an attribute instead of sitting beside the subject

  • The other attribute you may meetNot in this request

    1.2.840.113549.1.9.7A shared secret, meant for asking later that the certificate be revoked, and still used when a device enrols itself on a network
Every byte of the example request, with each object identifier named. This is what a command-line decoder prints, drawn instead of printed, so you can see where one field ends and the next begins.

CSR decoder: questions and answers

How do I decode a CSR?

Paste the whole request into the box above, including the -----BEGIN CERTIFICATE REQUEST----- and -----END CERTIFICATE REQUEST----- lines, or drop the file on the page. It decodes as you paste: the subject, the public key, every subject alternative name, every requested extension and the fingerprints. You can also paste the base64 body on its own, a hex dump, or upload a binary DER file.

Is this CSR decoder safe to use?

Yes, and for two reasons. A certificate signing request contains no secret — it is meant to be sent to a certificate authority — so decoding one anywhere is harmless. And this page does the work in your browser: the request is parsed by code downloaded with the page and nothing is sent to any server. If you paste a private key by mistake, the page tells you, refuses to decode it and keeps none of it.

How do I check whether my CSR is valid?

Decode it here and read the verdict. The page checks the request's own signature, which proves the sender holds the matching private key, and then applies the rules a public certificate authority applies: names it may not certify, wildcards that are too broad, reserved IP addresses, keys that are too small or factorable, deprecated subject fields and outdated signature hashes. Each finding says whether the CA will refuse it, change it, or only note it.

Why does my certificate authority reject my CSR?

The common causes are an internal name such as server.local or a single-label host name, an underscore in a host name, a wildcard over a public suffix like *.co.uk, a private IP address in the alternative names, an RSA key under 2048 bits, or a request still signed with SHA-1. Decode the request above and every one of those is named explicitly, with the rule it breaks.

How do I know my private key matches my CSR?

Use Match a key or certificate above: add the key next to the request and the page compares the public key inside the key file with the one in the request, in your browser. Or run it yourself — openssl req -in request.csr -pubkey -noout and openssl pkey -in private.key -pubout print the same public key when they match. The same comparison works between a key and an issued certificate.

Can this decode an SSL certificate too?

Yes. Paste a certificate and it decodes as a certificate: issuer and subject, serial number, validity dates, every alternative name, key usage and extended key usage, the authority and subject key identifiers, OCSP and CA Issuers URLs, certificate policies and any embedded certificate transparency timestamps. Paste a certificate and its request together and the page also tells you whether they share a key.

What fields does a certificate authority actually use from my CSR?

Reliably one: the public key. DigiCert's own documentation says the rest is ignored. On an OV or EV certificate the CA has to validate the organisation and country itself before they go in; validity dates always come from the Baseline Requirements schedule, never from the request. Two fields are not merely ignored but prohibited in a public TLS certificate: OU and, on domain-validated certificates, emailAddress.

Does the common name still matter?

Only as a copy of something else. Browsers have ignored the common name for host matching since 2017 and use the subject alternative names alone. The Baseline Requirements mark the common name NOT RECOMMENDED and require that, if it is present, it "MUST contain exactly one entry that is one of the values contained in the Certificate's subjectAltName extension". A common name that is not among your alternative names is a rejection, and this page flags it.

Can I decode several files at once?

Yes. Paste a request, its certificate and the intermediates together and each block is decoded on its own card, in the order you pasted them. One corrupt block does not stop the others. If a private key is somewhere in the paste it is named and skipped, never decoded. Up to forty blocks are decoded and anything beyond that is counted and reported rather than quietly dropped.

What is a challenge password in a CSR?

An optional attribute from RFC 2985, originally a shared secret you would quote when asking for the certificate to be revoked. It still has a role in SCEP enrolment, where a device proves it is allowed to ask. It plays no part in an ordinary web certificate order, and because it is a field few tools show, this page displays it whenever a request carries one.

Can I use an Ed25519 key for a public certificate?

Not today. The Baseline Requirements allow RSA and the P-256, P-384 and P-521 curves and then state that "no other algorithms or key sizes are permitted", so no public certificate authority will issue against an Ed25519 request. It is a fine key for SSH, for signing and for a private CA, and this decoder reads Ed25519 and Ed448 requests, and post-quantum ML-DSA keys, without complaint.

How long is a certificate valid now?

A public TLS certificate issued today cannot exceed 200 days, down from 398 before 2026-03-15. It drops to 100 days on 2027-03-15 and to 47 days on 2029-03-15, under CA/Browser Forum ballot SC-081v3. Nothing in a CSR affects this; validity is set by the CA. At these lengths renewal has to be automated, which in practice means ACME.

Missing something?Suggest a feature or a new tool

Related tools