What's the difference between a CSR and a certificate?

A CSR (Certificate Signing Request) is what you generate and send to a certificate authority, containing your public key and the subject/SAN details you're requesting a certificate for. It's self-signed by your own private key to prove you control it, but it isn't a trusted certificate itself; the CA verifies the request and issues an actual certificate back, which is what this tool's companion SSL Certificate Decoder reads.

Why would I want to inspect a CSR before submitting it?

To catch mistakes before they become an issued certificate you have to reissue: a wrong domain in the Subject Alternative Name list, an unexpectedly weak key size, or a typo in the subject fields are all much cheaper to fix in the CSR than after a CA has already issued a certificate from it.

Does this tool verify the CSR's self-signature?

No. It decodes and displays the CSR's structure and content; it doesn't cryptographically verify that the enclosed public key actually produced the signature.

Where does the requested Subject Alternative Name come from?

Modern CSRs include SAN (and other extensions) inside a PKCS#9 "extensionRequest" attribute, using the same Extensions structure a real certificate uses. This tool looks specifically for that attribute and decodes any extensions found inside it.

CSR Decoder - Inspect a PKCS#10 Certificate Request

Overview

Introduction

A CSR generated with OpenSSL or another tool is easy to get subtly wrong, a missing SAN entry, an unexpectedly small key, and those mistakes are cheapest to catch before a CA issues a certificate from it.

This tool decodes a PEM CSR's real structure directly in your browser and shows its subject, key, and requested extensions.

What Is CSR Decoder?

A PKCS#10 (RFC 2986) Certificate Signing Request decoder built on the same hand-written DER reader as this category's SSL Certificate Decoder.

It extracts the subject, the public key's algorithm and size, and any extensions requested via the standard PKCS#9 extensionRequest attribute, most commonly a Subject Alternative Name list.

How CSR Decoder Works

The PEM's base64 body is decoded to raw DER bytes, then the outer CertificationRequest SEQUENCE is split into CertificationRequestInfo, signature algorithm, and signature.

CertificationRequestInfo is walked field-by-field for version, subject, and subjectPKInfo, and its optional attributes set is scanned for an extensionRequest attribute (OID 1.2.840.113549.1.9.14), whose contents are parsed with the same Extensions decoder the SSL Certificate Decoder uses.

When To Use CSR Decoder

Use it right after generating a CSR (with OpenSSL, this site's RSA/ECDSA Key Generator plus external CSR tooling, or any other method) to confirm it requests exactly what you intended before submitting it to a CA.

It's also useful for inspecting a CSR someone else sent you, to see what domains and key type it's actually requesting.

Often used alongside SSL Certificate Decoder & Inspector and RSA/ECDSA Key Generator.

Features

Advantages

Decodes real PKCS#10 structure with no external tooling required.
Specifically surfaces requested extensions like Subject Alternative Name, the field most CSR mistakes actually involve.
Shares its ASN.1 reader and extension decoder with the SSL Certificate Decoder, so results are consistent between requesting and receiving a certificate.

Limitations

Doesn't verify the CSR's self-signature against its enclosed public key.
Only decodes the extensionRequest attribute among possible CSR attributes; other, less common PKCS#9 attributes aren't parsed.

Examples

Decoding a CSR's requested SAN

Input

a CSR with an extensionRequest attribute listing example.com and www.example.com

Output

Subject Alternative Name: DNS:example.com, DNS:www.example.com

The extensionRequest attribute's Extensions SEQUENCE is decoded the same way a certificate's own extensions block would be.

Best Practices & Notes

Best Practices

Verify every domain you intend to secure actually appears in the decoded Subject Alternative Name list before submitting the CSR; CAs increasingly ignore the subject CN for hostname validation.
Check the reported key size/algorithm matches your intended security level before submission; regenerating a CSR after issuance means starting over.
Keep the private key that generated this CSR secure; the CSR itself only contains the public half, but the CA-issued certificate will be useless without the matching private key.

Developer Notes

Reuses this category's `parseDerChildren`/`parseDerSiblings` DER walker, `parseName`, `parsePublicKeyInfo`, and `parseExtensions` functions, the same ones the SSL Certificate Decoder uses, since a CSR's Name, SubjectPublicKeyInfo, and Extensions structures are byte-for-byte the same ASN.1 definitions RFC 5280 certificates use.

CSR Decoder Use Cases

Verifying a freshly generated CSR requests the correct domains and key type before submitting it to a certificate authority
Inspecting a CSR received from someone else to see what it's actually requesting
Debugging a CSR-generation script or pipeline by checking its output structure

Common Mistakes

Assuming the subject CN alone reflects every domain being requested, when the actual hostname list lives in the Subject Alternative Name extension.
Submitting a CSR to a CA without checking its key size first, only to receive a certificate with weaker security than intended.

Tips

Decode the certificate a CA eventually issues with the SSL Certificate Decoder and compare its subject/SAN/key against this tool's CSR output to confirm nothing changed unexpectedly during issuance.

CSR Decoder