CSR Decoder

How to Use the CSR Decoder

1. Generate or obtain CSR: Create a CSR using OpenSSL, web server software, or export from your certificate management system.
2. Paste CSR: Copy and paste the entire CSR in PEM format including the BEGIN and END CERTIFICATE REQUEST lines.
3. Decode: Click "Decode CSR" to parse and display all information including subject details, public key algorithm, and key size.
4. Verify details: Check that all subject information is correct before submitting the CSR to a Certificate Authority for signing.

What is a Certificate Signing Request?

A Certificate Signing Request (CSR) is a block of encoded text that contains information about the entity requesting a certificate and the public key that will be included in the certificate. When you apply for an SSL/TLS certificate, you generate a CSR on your server along with a private key pair. The CSR is sent to a Certificate Authority (CA), which validates the information and issues a signed certificate. Once issued, analyze your certificate with our SSL Certificate Decoder.

The CSR contains your public key and identifying information such as domain name, organization name, locality, and country. It's digitally signed using your private key to prove you possess the corresponding private key. The CA verifies this signature and the provided information before issuing the certificate. Your private key never leaves your server and should never be shared.

CSR Contents and Structure

Subject Distinguished Name (DN): Contains identifying information about the entity requesting the certificate. Required fields vary by certificate type and CA, but typically include:

Common Name (CN): The fully qualified domain name (FQDN) the certificate will protect, such as www.example.com or *.example.com for wildcard certificates. This is the most critical field and must exactly match the domain where you'll install the certificate.

Organization (O): Legal name of the organization requesting the certificate. Required for OV and EV certificates, optional for DV certificates.

Organizational Unit (OU): Department or division within the organization, such as "IT Department" or "Web Security". Optional and increasingly deprecated by CAs.

Locality (L): City or locality where the organization is legally located. Required for OV and EV certificates.

State/Province (ST): State, province, or region. Required for OV and EV certificates. Must be spelled out fully, not abbreviated.

Country (C): Two-letter ISO country code (e.g., US, GB, CA). Required for all certificate types.

Public Key Information

The CSR contains your public key, which will be included in the final certificate. Modern CSRs typically use RSA keys of 2048 or 4096 bits, or ECDSA keys with 256 or 384 bits. The public key algorithm and key size are critical for security—2048-bit RSA is the current minimum standard, while 4096-bit provides additional security at the cost of performance. ECDSA keys offer equivalent security with smaller key sizes and better performance.

The CSR's signature algorithm (like SHA-256 with RSA or ECDSA) proves you control the private key. When the CA receives your CSR, it verifies this signature before proceeding with validation. Never generate CSRs with deprecated algorithms like MD5 or SHA-1, as CAs will reject them.

Subject Alternative Names (SAN)

Modern CSRs include a SAN extension that allows a single certificate to secure multiple domain names. While the Common Name field traditionally held the primary domain, browsers now rely on the SAN extension. A SAN can include multiple DNS names, IP addresses, or email addresses. For example, a single certificate can protect www.example.com, example.com, mail.example.com, and ftp.example.com.

When generating a CSR, you can specify multiple SANs to create a multi-domain certificate. Wildcard certificates use a SAN like *.example.com to protect all subdomains. Most CAs require the Common Name to also appear in the SAN extension.

How to Generate a CSR

OpenSSL (command line): openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr - This generates a new 2048-bit RSA private key and CSR. You'll be prompted for subject information. The private key is saved in server.key (keep this secure!) and the CSR in server.csr.

Web servers: Apache, Nginx, IIS, and other web servers include built-in tools for CSR generation. These typically create both the CSR and private key in the appropriate format for that server.

Control panels: cPanel, Plesk, and other hosting control panels provide web-based CSR generators that guide you through the process.

Certificate management tools: Organizations often use dedicated certificate management platforms that automate CSR generation and certificate lifecycle management.

CSR Best Practices

Use strong keys: Generate CSRs with at least 2048-bit RSA keys or 256-bit ECDSA keys. Anything smaller is deprecated and may be rejected by CAs or browsers.

Verify before submitting: Always decode and verify your CSR before sending it to a CA. Mistakes in the subject information will be permanently embedded in the issued certificate.

Protect private keys: The private key generated with your CSR must be kept secure. Set appropriate file permissions (typically 600 on Unix systems). Never share your private key or include it in the CSR submission.

Keep backups: Maintain secure backups of both your CSR and private key. If you lose the private key, the certificate issued from that CSR becomes useless.

Use meaningful filenames: Name CSR and key files descriptively, like example.com-2024.csr and example.com-2024.key, especially if managing multiple certificates.

Common CSR Generation Errors

Mismatched Common Name: The CN must exactly match the domain where you'll use the certificate. www.example.com and example.com are different. Wildcard certificates use *.example.com.

Abbreviated states: Use the full state/province name (California, not CA). Many CAs reject abbreviations.

Special characters: Avoid special characters, accents, or unusual punctuation in subject fields. Stick to standard alphanumeric characters.

Weak key sizes: 1024-bit RSA keys are deprecated. Always use 2048-bit or larger.

After Decoding Your CSR

Once you've verified your CSR contains correct information, submit it to your chosen Certificate Authority. The CA will validate your information according to the certificate type (DV, OV, or EV) and issue a signed certificate. You'll then install both the issued certificate and the original private key on your server. Never generate a new private key when installing the certificate—it must be the same key pair created with the CSR.

Browser Limitations

Note: This tool provides basic CSR information extraction. Complete parsing of all CSR extensions and attributes requires specialized ASN.1 parsing libraries. For production CSR verification, use OpenSSL: openssl req -text -noout -verify -in server.csr for complete details including signature verification.