b2KIT

CSR Decoder

Decode and inspect Certificate Signing Request (CSR) files to view subject, key details, and extensions.

Tested tool guide Tested browser tools Checked August 16, 2026

What CSR Decoder does and how it behaves

A CSR is a signed request for a certificate, not a certificate itself. CSR Decoder opens its PKCS #10 contents and organizes the subject distinguished name, public-key details, and requested extensions for inspection. This is useful before submitting the request or when diagnosing why a certificate order does not match expectations. The usual surprise is that subject alternative names are only requests: the issuing authority may reject or change them. A standard CSR does not contain the corresponding private key.

How the result is produced

1

Request structure

CSR Decoder interprets the PKCS #10 request structure and presents fields from CertificationRequestInfo: its version, distinguished-name subject, subject public-key information, and attributes. When the attributes include an extensionRequest, it expands the requested X.509 extensions, including subject alternative names when supplied. Processing stays in the browser, so the submitted CSR is not uploaded.

2

Field interpretation

The subject and requested extensions remain separate parts of the result. A commonName value is a distinguished-name component; a dNSName value belongs to subjectAltName. Key information describes the public key carried by the request. Extension information describes what the requester asked a certificate authority to include, not what any issued certificate necessarily contains.

Good uses

  • Verify that a newly generated CSR names the intended organization, common name, and SAN hostnames before sending it to a certificate authority.
  • Check the public-key type and size while investigating a CSR rejected for key policy or format reasons.
  • Compare a replacement CSR with the previous request to catch omitted hostnames or stale subject attributes.

Limits and checks

  • Decoding establishes what fields are encoded, not whether the named person, organization, or domain has been validated.
  • Requested extensions are proposals. Compare them with the issued certificate instead of assuming the authority copied them unchanged.
  • The subject commonName and subjectAltName extension are distinct; an expected hostname can be absent from the SAN list even when it appears as CN.

Common questions

Does a successful decode mean the CSR is ready for issuance?

No. It means the request was readable enough to display. The decoder does not establish domain control, organization identity, approval under an authority's policy, or whether every requested extension will be honored. Review the subject, key details, and requested extensions, then rely on the issuing authority's validation and final certificate for the issuance outcome.

Can this decoder recover the private key from a CSR?

No. In PKCS #10, SubjectPublicKeyInfo contains the public key, and the request's signature is created with the corresponding private key. That signature does not embed the private key. If the private key has been lost, decoding the CSR cannot reconstruct it; generate a new key pair and a new request.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools