How to Decode and Validate SSL Certificate Signing Requests (CSR): The Complete Guide

When provisioning an SSL/TLS certificate for your website, web application, or corporate VPN, the very first step in the deployment pipeline is generating a Certificate Signing Request (CSR).

Generating a CSR packages your public key and identity information into a standardized format defined by PKCS#10 (RFC 2986). Before you paste this request into a Certificate Authority (CA) such as DigiCert, Sectigo, AWS ACM, or Let's Encrypt, you need to verify that all domains, key lengths, and cryptographic parameters are accurate. Submitting a flawed CSR can lead to certificate mis-issuance, downtime, or immediate rejection.

In this guide, you will learn how CSRs work, what information they contain, why Subject Alternative Names (SANs) are mandatory in modern web standards, and how to validate your requests without compromising security.

1. What is Inside a PKCS#10 CSR?

A CSR is typically presented in PEM format: a base64-encoded block wrapped between -----BEGIN CERTIFICATE REQUEST----- and -----END CERTIFICATE REQUEST-----.

When decoded from its binary ASN.1 DER structure, a CSR contains three distinct components:

CertificationRequest ::= SEQUENCE {
    certificationRequestInfo CertificationRequestInfo,
    signatureAlgorithm AlgorithmIdentifier,
    signature BIT STRING
}

1. CertificationRequestInfo

• Version: Usually 0 (representing PKCS#10 v1.7).
• Subject Distinguished Name (DN): Contains your organizational and domain details:
  • CN (Common Name): The primary Fully Qualified Domain Name (FQDN), e.g., www.example.com.
  • O (Organization): Legal business name, e.g., Acme Technologies Inc..
  • OU (Organizational Unit): Internal department, e.g., Security Operations.
  • L (Locality / City): E.g., San Francisco.
  • ST (State / Province): E.g., California.
  • C (Country): Exactly two uppercase letters (ISO 3166-1 alpha-2), e.g., US, GB, IN, DE.
• SubjectPublicKeyInfo: The applicant's public key (e.g., 2048-bit RSA modulus and exponent 65537, or 256-bit ECDSA curve).
• Attributes & Extensions: Crucial modern certificate attributes, including Subject Alternative Names (SANs), Key Usage, and Extended Key Usage.

2. SignatureAlgorithm

Identifies the cryptographic hash and cipher used to sign the request, such as sha256WithRSAEncryption (OID 1.2.840.113549.1.1.11) or ecdsa-with-SHA256 (OID 1.2.840.10045.4.3.2).

3. Signature (Self-Signature)

The applicant signs the entire CertificationRequestInfo block with their private key. This serves as a cryptographic Proof of Possession (POP), proving to the Certificate Authority that the entity requesting the certificate genuinely controls the matching private key without revealing the private key itself.

2. Why Subject Alternative Names (SANs) are Mandatory

One of the most frequent reasons modern web certificates fail in production is missing Subject Alternative Names (SANs).

Historically, browsers checked the Common Name (CN) attribute to decide whether a certificate was valid for a domain. However:

• In 2011, RFC 6125 formally deprecated the use of Common Name for domain verification.
• In 2017, Google Chrome 58 dropped fallback support for Common Name entirely.
• Today, all major browsers (Chrome, Edge, Safari, Firefox) strictly validate domains against the subjectAltName extension.

If you purchase a certificate with CN=www.example.com but your CSR does not include DNS:www.example.com and DNS:example.com in the SAN extension, browsers will trigger an immediate ERR_CERT_COMMON_NAME_INVALID warning.

Always ensure your CSR contains all desired hostnames in the SAN extension.

3. Cryptographic Key Length Requirements

Certificate Authorities follow baseline requirements established by the CA/Browser Forum and NIST:

Any CSR with an RSA key length below 2048 bits or an obsolete signature algorithm (SHA-1/MD5) will be immediately rejected during CA submission.

4. Top OpenSSL Commands for Inspecting CSRs

If you prefer verifying CSRs on a Linux terminal or macOS terminal, use these OpenSSL commands:

1. View Complete Decoded Text

openssl req -in request.csr -noout -text

This outputs the full Subject DN, public key parameters, exponent, and extension requests.

2. Verify Cryptographic Self-Signature

openssl req -in request.csr -noout -verify

If the signature is intact and valid, OpenSSL prints: verify OK.

3. Check if a CSR Matches a Specific Private Key

A common sysadmin mishap is generating multiple CSRs and losing track of which private.key matches which request.csr.

You can verify the cryptographic modulus match by hashing both with MD5:

openssl req -noout -modulus -in request.csr | openssl md5
openssl rsa -noout -modulus -in private.key | openssl md5

If both MD5 hash strings match exactly, the private key and CSR belong to the same key pair.

5. Decode and Validate Your CSR 100% In-Browser

Need to inspect a CSR quickly without firing up a terminal or uploading sensitive organizational domain details to a cloud vendor?

Use the KitWharf SSL CSR Decoder & Validator. It runs completely client-side in your web browser, extracting Subject DN attributes, verifying SAN domains, auditing RSA/ECDSA key bit lengths, and flagging security vulnerabilities in real time with zero server uploads.