CSR Decoder
Decode the contents of a Certificate Signing Request (PEM format).
Reviewed by the ToolNestr Editorial Team — July 2026
What is a Certificate Signing Request?
A Certificate Signing Request (CSR) is a structured message sent to a Certificate Authority (CA) to apply for an SSL/TLS certificate. It contains the identity information of the organisation requesting the certificate — including the domain name (Common Name), organisation name, locality, and country — along with the applicant's public key. The entire request is signed using the corresponding private key to prove that the requester actually possesses the private key without revealing it.
CSRs follow the PKCS#10 standard (Public-Key Cryptography Standard #10), defined in RFC 2986. The data is encoded using ASN.1 (Abstract Syntax Notation One) with DER (Distinguished Encoding Rules) binary encoding, then wrapped in base64 with PEM header and footer lines. This is why a CSR looks like -----BEGIN CERTIFICATE REQUEST----- followed by a block of base64 text.
The three major parts of a CSR are the certification request info (version, subject distinguished name, public key, and optional attributes), the signature algorithm identifier (which algorithm was used to sign), and the digital signature value itself. The CA verifies the signature using the public key contained in the request, then issues a signed X.509 certificate.
How the CSR Decoder Works
This decoder processes the CSR entirely in your browser. When you paste a PEM-encoded CSR and click Decode, the tool strips the PEM headers, decodes the base64 content into DER binary data, and parses the ASN.1 TLV (Tag-Length-Value) structure to extract each field.
For the public key, the decoder uses the Web Crypto API (SubtleCrypto) to import the SubjectPublicKeyInfo from the CSR and export it as a JWK (JSON Web Key). This reveals the key type (RSA or EC), the key size in bits (computed from the modulus length for RSA, or the curve name for EC), and the key usage. The same approach is used by the RSA Key Generator tool on this site.
Subject fields are extracted by walking the ASN.1 structure of the Name element and matching each attribute's OID (Object Identifier) to a lookup table. Common OIDs include 2.5.4.3 for Common Name (CN), 2.5.4.10 for Organization (O), and 2.5.4.6 for Country (C). If the CSR includes a Subject Alternative Names (SANs) extension, the tool also decodes those and displays each domain name or IP address.
Use Cases
- Verifying CSR contents before submission — check that the CN, organization, and SANs are correct before sending to a CA to avoid certificate re-issuance delays.
- Debugging certificate ordering issues — when a CA rejects a CSR, decode it to verify the key size, signature algorithm, and subject fields meet the CA's requirements.
- Server administration — when taking over management of existing servers, decode the installed CSR or certificate to understand what identity information was used.
- Security audits — examine CSRs to verify key strength (minimum 2048-bit RSA) and ensure no unexpected SANs or subject fields are present.
- Education and training — learn how PKI infrastructure works by examining real CSR structures and understanding each ASN.1 field.
Tips & Common Mistakes
- Verify the CN matches your domain — the Common Name must exactly match the domain name the certificate will secure. A mismatch causes browser security warnings. For wildcard certificates, use
*.example.com. - Check key size is at least 2048 bits — many CAs reject CSRs with RSA key sizes below 2048 bits. NIST recommends 2048-bit RSA or 256-bit ECDSA as the minimum for production systems through 2030.
- Include SANs for multi-domain certificates — modern browsers expect Subject Alternative Names (SANs) even when a Common Name is present. Always include all domains the certificate should cover in the SAN extension.
- Keep your private key secure — the CSR only contains the public key, but you generated it with your private key. Never share the private key file. If the private key is compromised, anyone can create a new CSR and request a certificate for your domain from a CA.
- Use a strong signature algorithm — prefer SHA-256 over SHA-1 for the signature. SHA-1 is deprecated and most CAs no longer accept CSRs signed with SHA-1.
Typical CSR Generation Workflow
Generate Key Pair
Use OpenSSL or your server software to generate a 2048+ bit RSA or EC key pair. The private key stays on your server and must never be shared.
Create CSR
Generate the CSR using the private key. Provide your domain (CN), organization details, and optionally include SANs for multi-domain coverage.
Submit to CA
Send the CSR to a trusted Certificate Authority (Let's Encrypt, DigiCert, Sectigo, etc.). The CA verifies domain ownership and issues the signed certificate.
Install Certificate
Install the returned X.509 certificate on your server alongside the private key. The CSR is no longer needed after the certificate is issued.
The typical OpenSSL command to generate a CSR is openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr. This creates a 2048-bit RSA key pair and outputs a CSR file. The -nodes flag means the private key is not encrypted with a passphrase — omit it if you want to encrypt the key.
Privacy & Security
This tool processes everything locally in your browser using the Web Crypto API. No data is sent to any server, logged, or stored. The CSR you paste never leaves your device. You can verify this by opening your browser developer tools network tab — no network requests are made when you decode a CSR.
Related tools
Frequently asked questions
Is my CSR uploaded anywhere?
No — all decoding happens in your browser using the Web Crypto API. The CSR you paste never leaves your device.
What is a CSR used for?
A Certificate Signing Request (CSR) is sent to a Certificate Authority (CA) when ordering an SSL/TLS certificate. It contains the domain information and public key, signed by the private key to prove ownership.
Can I decode a CSR that has a passphrase?
CSRs themselves are not encrypted. The private key used to generate the CSR may be protected by a passphrase, but the CSR PEM file is always unencrypted base64-encoded DER data.
What is the difference between a CSR and a certificate?
A CSR is a request for a certificate. It contains the information you want the CA to certify (domain, organization, public key). The CA signs it and returns the actual X.509 certificate. The CSR is never installed on a server — only the final certificate is.
What key sizes are supported?
The tool works with any RSA or EC key size. NIST recommends a minimum of 2048-bit RSA or 256-bit ECDSA for production use.