Understanding Certificate Signing Requests (CSRs)
Comprehensive reference guide to PKCS#10 Certificate Signing Requests
A Certificate Signing Request (PKCS#10 format) is a standardized cryptographic message sent from an applicant to a Certificate Authority (CA) to apply for a digital X.509 certificate. It binds identity information to a public key.
What Information Does a CSR Contain?
A standard CSR includes: (1) Subject Information (Common Name, Organization, Organizational Unit, Country, State, Locality, Email), (2) Public Key Information (Algorithm type such as RSA or EC, key size, or curve parameters), (3) Requested Extensions (such as Subject Alternative Names, Key Usage, and Basic Constraints), and (4) The Applicant's Digital Signature generated with their private key to prove key ownership.
What is a Subject Alternative Name (SAN)?
Subject Alternative Name (SAN) is an X.509 extension (OID 2.5.29.17) that specifies additional hostnames, IP addresses, URIs, or email addresses secured by a single certificate. Modern web browsers require domain names to be specified in SAN fields rather than relying solely on the Common Name (CN).
Difference Between a CSR and a Certificate
A CSR is an unfulfilled application created locally by the server administrator containing only the public key. An X.509 Certificate is the published credential signed by a Certificate Authority's private key containing validity dates, CA signature, serial number, and trust chain details.
How CSRs Work in SSL/TLS Deployment
1. Server Admin generates a private key & matching CSR on the local web server. 2. Server Admin submits the CSR text to a CA (e.g. Let's Encrypt, DigiCert, Sectigo). 3. CA verifies domain control and identity credentials. 4. CA signs the public key and returns the X.509 Certificate file. 5. Server Admin installs the Certificate alongside the private key generated in step 1.