> csr | certificate | request <
// Decode and verify a PKCS#10 (RFC 2986) Certificate Signing Request before sending it to a CA
Subject DN Breakdown
Parse CN, O, OU, C, ST, L, and email from the Subject Distinguished Name so you can verify every attribute before a CA re-issue cycle.
SAN Inspection
Lists every Subject Alternative Name and key usage extension defined in RFC 5280, so you can confirm all hostnames will be covered.
Key & Signature Detail
Reveals the public-key algorithm and size or curve (RSA/EC/Ed25519) plus the signature algorithm used to self-sign the PKCS#10 request.
// ABOUT CSRs
How Decoding Works:
A CSR is a PKCS#10 structure (RFC 2986) wrapped in -----BEGIN CERTIFICATE REQUEST----- markers and Base64-encoded. It contains the Subject Distinguished Name, the Subject Public Key Info, requested X.509 extensions (RFC 5280, most commonly subjectAltName and keyUsage), and a signature proving control of the matching private key. PKI.js parses the ASN.1 tree client-side and exposes every attribute.
Example:
openssl req -new -newkey rsa:2048 -nodes -keyout key.pem -out csr.pem produces a CSR you can paste here to confirm the values.
Common Use Cases:
- >Verify CN and SANs before submitting to a public CA (RFC 5280)
- >Catch typos in O, OU, C, ST, L attributes
- >Confirm the public-key algorithm and bit length
- >Audit CSRs generated by automation pipelines and Terraform
- >Inspect renewal CSRs from cert-manager, certbot, or step-ca
>> frequently asked questions
Q: What is a CSR?
A: A Certificate Signing Request is a PKCS#10 structure (RFC 2986) you generate locally and submit to a Certificate Authority. It carries your public key, the Subject Distinguished Name you want bound to it, optional X.509 extension requests such as subjectAltName from RFC 5280, and a self-signature proving you hold the matching private key.
Q: Does this tool see my private key?
A: No. A CSR contains only your public key, identity metadata, and a signature. Furthermore, parsing happens entirely in your browser — the CSR text never leaves your machine, no upload occurs, and the decoder is fully client-side. You can paste internal infrastructure CSRs without leaking anything to a server.
Q: Can I decode a .p10 or binary .req file?
A: If the file is text-form PKCS#10 (PEM with -----BEGIN CERTIFICATE REQUEST----- markers) paste it directly. For binary DER, convert first with `openssl req -inform der -in foo.req -out foo.csr`, then paste the resulting PEM contents into this decoder. Both .csr and .p10 extensions are commonly used; the wrapping markers are what matter, not the filename.
Q: Why does my CSR not have SANs?
A: Subject Alternative Names are an optional X.509 extension defined in RFC 5280. Most public CAs require them today — if your CSR lacks SANs, regenerate it with an OpenSSL config that includes a `subjectAltName = DNS:example.com,DNS:www.example.com` line, or use `-addext` on the command line.
Q: What signature algorithm should I use?
A: For new certificates prefer ECDSA on P-256 with SHA-256, or RSA 2048+ with SHA-256. Avoid SHA-1 and RSA-1024 — the CA/Browser Forum baseline requirements and most root programs reject them outright. Ed25519 is increasingly supported but check your CA's policy first.