CSR Decoder
Decode and verify Certificate Signing Request (CSR) fields locally.
CSR Decoder
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The CSR Decoder reads a Certificate Signing Request back into its component fields — the Distinguished Name being requested, the public key algorithm and size, the signature algorithm used for the request's self-signature, and any additional attributes included, such as a requested SAN extension or a challenge password. It's the natural companion to the CSR Generator: one produces a request, the other verifies exactly what that request actually says before it's submitted anywhere.
- This matters most when a CSR arrives from somewhere other than a tool you fully control — a colleague's submission, an automated pipeline's output, or a request you're reviewing before approving internal issuance — where confirming the actual requested identity and key parameters before signing anything is a real safeguard, not a formality.
How It Works
- The CSR's PEM wrapper (CERTIFICATE REQUEST headers) is stripped and the base64 body is decoded into the underlying PKCS#10 structure.
- The subject Distinguished Name is extracted, showing exactly what identity (Common Name, Organization, Country, and similar) the request is asking a CA to certify.
- The public key algorithm and size are read from the request, confirming what cryptographic material the eventual certificate would bind to that identity.
- Any additional attributes are surfaced — most commonly a requested extension (like a SAN list) or a legacy challenge password field, both defined as optional PKCS#9 attribute types a CSR can carry.
Usage
- Paste the PEM-formatted CSR you want to decode.
- Run the decode to extract its fields.
- Review the subject Distinguished Name, public key algorithm and size, and signature algorithm.
- Check any additional attributes present for a requested extension or legacy challenge password field.
Examples
- Decoding a CSR received from a colleague to confirm the Organization and Common Name fields match what was actually agreed on before approving issuance.
- Verifying a CSR generated by an automated certificate-renewal script contains the expected Common Name after a configuration change.
- Checking the key size of an incoming CSR against a minimum-strength policy (e.g. rejecting anything below RSA 2048-bit) before it's ever signed.
- Round-tripping a freshly generated CSR through the decoder immediately, as a sanity check that the CSR Generator's output matches what was actually entered.
Real-World Use Cases
- Reviewing a CSR submitted by a colleague or automated pipeline before approving internal certificate issuance, to confirm the requested identity fields are actually correct.
- Verifying that a generated CSR contains the exact Distinguished Name and key parameters you intended, before submitting it to a Certificate Authority.
- Checking the public key algorithm and size a CSR requests, to confirm it meets a security policy's minimum requirements before it's ever signed into a certificate.
- Inspecting a CSR's requested extensions (such as a SAN attribute) to confirm every hostname a multi-domain certificate should cover is actually present in the request.
Best Practices
- Always decode and review a CSR's actual contents before signing it into a certificate, especially in an internal PKI where you act as the CA — a CSR asserts whatever identity it was built with, and nothing forces it to match what was verbally agreed.
- Check the public key size and algorithm against your organization's minimum security policy before issuance, since a CSR itself imposes no minimum strength.
- Cross-reference any requested SAN attribute against the domains you actually intend to authorize — a CSR can request more (or different) hostnames than were originally discussed.
- Don't rely on a legacy challenge password attribute as a real authentication mechanism — it's a PKCS#9 holdover largely unused in modern CA workflows and provides no meaningful assurance on its own.
Common Mistakes
- Assuming a CSR's contents have been validated in any way before decoding it — a CSR only proves the requester holds the matching private key, not that the requested identity fields are accurate or authorized.
- Overlooking a CSR's requested key size, and issuing a certificate for a key weaker than current security guidance recommends (e.g. RSA below 2048 bits).
- Missing a requested SAN attribute entirely because it's not part of the core Distinguished Name fields — reviewing subject fields alone can miss additional hostnames the request is actually asking to cover.
- Treating a decoded CSR's self-signature validity as proof of the requester's identity — it only proves key possession, not who the requester actually is.
Limitations
- This tool decodes and displays a CSR's fields; it does not verify the self-signature cryptographically or check the requested identity against any external authority.
- Attribute support covers the common cases (requested extensions, challenge password); highly customized or vendor-specific CSR attributes may not all be individually surfaced.
- This is a read-only inspection tool — it does not modify, re-sign, or issue a certificate from the decoded request.
Technical Reference Guide
- The CSR structure this tool decodes, including the subject Distinguished Name and public key fields, is defined by RFC 2986 (PKCS #10).
- Optional CSR attributes such as the extension request (commonly used to request a SAN list) and the legacy challenge password field are defined as PKCS #9 selected attribute types in RFC 2985.
- Distinguished Name field semantics (Common Name, Organization, Country, and similar) follow the X.520 conventions referenced by RFC 5280.
FAQ
What's the difference between this tool and the CSR Generator?
The CSR Generator builds a new request from Distinguished Name fields you provide. This tool does the reverse: reads an existing CSR — your own or one someone else submitted — back into its component fields for review.
Does decoding a CSR confirm the requester's identity?
No — a CSR's self-signature only proves the requester holds the private key matching the enclosed public key. It says nothing about whether the requested identity fields are accurate or the requester is authorized to claim them.
What is the challenge password attribute, and do I need to worry about it?
It's a legacy PKCS #9 attribute originally intended for authenticating revocation requests. It's rarely used meaningfully in modern CA workflows and shouldn't be relied on as a real authentication mechanism.
Can a CSR request multiple hostnames?
Yes, through a requested extension attribute (typically a SAN list) rather than the core Common Name field alone — check the attributes section of a decoded CSR to see if one is present.
Why would I decode a CSR I just generated myself?
As a sanity check — confirming the tool that generated it actually produced a request with the exact Distinguished Name and key parameters you intended, before submitting it anywhere.
Does this tool check if the requested key size meets security best practices?
It surfaces the key algorithm and size for you to review, but doesn't enforce a policy — you (or your organization's issuance process) need to decide whether a given size meets your minimum requirements before signing it into a certificate.
Part of this Developer Hub
This utility is part of our comprehensive Certificate & PKI topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the Certificate & PKI Lab workshop for complementary engineering workflows.
View all Certificate & PKI Lab tools