Certificate Signing Request (CSR) Decoder

Introduction:

A certificate signing request, or CSR, is the formal request a system sends when it wants a certificate issued. In PKCS #10 form it carries the subject name, the public key that should appear in the certificate, optional requested extensions, and a self-signature made with the matching private key.

That sounds simple until a renewal fails because the wrong hostnames were requested, the key profile is out of date, or an inherited request does not match the key pair you expected. For public TLS work, the requested Subject Alternative Name list usually matters more than the common name alone, because current service-identity rules look to SAN for the DNS names or IP addresses a certificate covers.

A readable decode is useful because a CSR asks for certificate content without guaranteeing that the request is sensible. The subject can look familiar while the SAN set is incomplete. The key can parse cleanly while still falling below current policy. A request can also be self-signed correctly and still be rejected by a certificate authority because the names, extensions, or validation evidence do not meet issuance rules.

The safest mental model is simple: a CSR is a signed request, not an issued certificate. A good review checks what identity is being asked for, what public key is attached, and which extra constraints or usages are being requested before the request leaves your system.

Technical Details:

A PKCS #10 request has three high-level pieces. The first is the certification request information, which contains the subject name, the SubjectPublicKeyInfo block, and a set of attributes. The second names the signature algorithm. The third is the signature itself. That structure matters because most human review questions map directly to one of those parts: who the certificate is meant to represent, which public key is being bound, what extra extensions were requested, and whether the request was signed by the holder of the private key.

The attribute set is where many practical surprises live. A common attribute is extensionRequest, which can carry Subject Alternative Name values, key usage bits, extended key usage values such as serverAuth, and basic constraints. Another possible attribute is challengePassword. That password is defined in PKCS #9, but many current web PKI workflows do not depend on it, so its presence is something reviewers often want surfaced rather than ignored.

Identity review also has an important boundary. The subject distinguished name can include fields such as common name, organization, organizational unit, locality, state, country, and email address, but those fields do not all carry the same weight in every certificate profile. For publicly trusted TLS server certificates, current rules require SAN to be present with DNS names or IP addresses in the issued certificate, and modern service-identity guidance treats SAN as the authoritative source for host coverage. In private PKI or non-TLS uses, the local policy can be different, which is why a missing SAN is a strong warning for web server work but not universal proof of a bad request.

Fingerprint fields answer a different question from the subject and SAN fields. They do not describe identity at all. They help you compare requests and public keys exactly. A whole-request digest changes whenever any part of the CSR changes. A SubjectPublicKeyInfo digest changes only when the public key changes. That makes the SPKI value useful when you want to confirm key continuity across a renewal even if the subject or SAN list has been edited.

The request review cues surfaced here are advisory rather than absolute policy checks. A weak hash or a small RSA key is a strong sign that the request should be regenerated. A missing SAN or a common name that does not appear in SAN is a strong sign of trouble for web server certificates. A present challenge password is not automatically invalid, but it is worth noticing because many teams did not intend to include it.

Everyday Use & Decision Guide:

Start with the exact CSR you plan to submit, not a copied summary from another system. If you already have a standard PEM block, paste it directly. If you only have the base64 body, the decoder can wrap it in the normal certificate-request boundaries and try the parse from there.

The fastest first pass is to decode once, read the CSR Overview, then move through Request Anatomy and Subject Alternative Names. For a server certificate, the SAN tab deserves more trust than a familiar-looking common name. A request for www.example.com that leaves out example.com will still look neat at a glance while asking for the wrong coverage.

• If you inherited the request from another person or system, compare Key Algorithm, Key Size (bits), and SPKI SHA-256 (hex) with your expected inventory before you reuse it.
• If the warning count is not zero, read the warning condition before exporting or filing the request. A structurally valid CSR can still be a bad submission candidate.
• If the request is meant for public TLS, treat missing SAN values, a common name absent from SAN, weak digest warnings, or a small RSA key as reasons to regenerate the request rather than push it forward.
• If you need to hand results to another system or teammate, the page can copy or download CSV summaries, export DOCX tables, save the CSR as PEM or DER, save the public key as SPKI DER, and expose a JWK when the public key is RSA or EC.

This is a review surface, not a certificate-ordering workflow. The practical next step is to line up the SAN list and the public-key fingerprint with your issuance plan before you send the CSR to any issuer or automation pipeline.

Step-by-Step Guide:

1. Paste the request into CSR input, drop a text CSR file on the field, or use the upload control. If the field is empty, the page stops and asks for a PEM-encoded CSR.
2. Click Decode CSR. When the parse succeeds, CSR Overview shows the common name, signature state, SAN count, and warning count.
3. Open Request Anatomy and read Subject CN, Subject DN, Key Algorithm, Key Size (bits), Signature Alg., and the fingerprint rows first.
4. Open Subject Alternative Names and confirm that every intended DNS name or IP address is present. If the list is empty or incomplete for your use case, stop there and rebuild the CSR.
5. Use JSON when you want the full structured decode, and use the copy or download actions when you need a CSV, DOCX, PEM, DER, or JWK artifact for follow-up.
6. If the decode fails, normalize the request to a standard PEM block with BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST, or paste only the base64 body and try again. Raw binary DER uploads are not the dependable path here because the upload flow reads files as text.

Interpreting Results:

The three most important result groups are the identity fields, the warning list, and the fingerprint fields. Verified = Yes is a useful floor because it shows the request was signed with the matching private key, but it does not say anything about domain control, organizational approval, or whether an issuer will accept the request.

The common overread is to stop once the subject looks right and the signature verifies. The safer habit is to compare the SAN list and the SPKI fingerprint before making any trust decision. Those two checks catch many of the mistakes that turn into wrong-certificate deployments later.

Worked Examples:

Routine renewal with the expected host set

A request for www.example.com decodes with SAN values for www.example.com and example.com, an RSA 2048 key, a SHA-256 signature digest, and no warnings. That is the pattern most teams hope to see during an ordinary web renewal: the requested names are explicit, the key profile is current enough, and the request is self-signed correctly.

Inherited request with the right common name but the wrong coverage

A teammate hands over a CSR whose Subject CN is api.example.com. The request verifies, but the SAN list contains only internal-api.example.net, and the warning list notes that the common name is not listed in SAN. The fix is not to trust the familiar common name. The fix is to regenerate the request with the real service identities you intend to certify.

Upload that looks plausible but still fails

A file named request.der is uploaded and the decode does not succeed. The corrective path is to convert the request to a standard PEM block or paste the base64 body directly, then decode again and confirm that CSR Overview appears. In this flow, file uploads are read as text, so raw binary DER is the common reason a seemingly correct request still fails to parse.

FAQ:

Glossary:

CSR

A certificate signing request that carries identity data, a public key, and a self-signature.

Subject distinguished name

The ordered subject fields such as common name, organization, locality, state, and country.

SAN

The Subject Alternative Name extension that lists DNS names or IP addresses for certificate identity coverage.

SPKI

The SubjectPublicKeyInfo structure that wraps the public key and its algorithm identifier.

Extended Key Usage

An extension that signals intended certificate purposes such as TLS server authentication.

JWK

A JSON Web Key object used to represent key material in JSON form.

References:

• RFC 2986, PKCS #10: Certification Request Syntax Specification Version 1.7
• RFC 2985, PKCS #9: Selected Object Classes and Attribute Types
• RFC 7468, PKIX Textual Encodings
• RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• RFC 7517, JSON Web Key (JWK)
• RFC 9525, Service Identity in TLS
• CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates
• NIST SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths