A Certificate Signing Request (CSR) is the digital handshake that lets you prove your server’s identity to a Certificate Authority (CA) so they can issue you an SSL/TLS certificate.
Let’s see this in action. Imagine you’re setting up a new web server and want to secure it with HTTPS. Your server needs a digital identity, which is the SSL/TLS certificate. But you can’t just create one yourself; a trusted third party, the CA, has to vouch for you.
Here’s the flow:
- Generate a Key Pair: On your server, you generate a public and private key. The private key stays secret on your server. The public key is what gets embedded in the certificate.
- Create the CSR: You then bundle your public key with identifying information (like your domain name, organization name, location) into a CSR file.
- Submit to CA: You send this CSR to a CA (e.g., Let’s Encrypt, DigiCert, Sectigo).
- CA Verification: The CA verifies your identity and your control over the domain.
- Issue Certificate: If verification passes, the CA signs your public key and identifying information with their own private key, creating your SSL/TLS certificate.
- Install Certificate: You install the signed certificate (along with the CA’s intermediate certificates) on your web server. Your server can now use its private key to decrypt traffic that was encrypted with the public key from the certificate.
This process ensures that when a browser connects to your server, it can trust that your server is who it claims to be, because a trusted CA has verified it.
The core problem a CSR solves is trust delegation. You can’t directly prove to every user on the internet that your server is legitimate. Instead, you rely on a pre-established system of trust. Browsers and operating systems come with a list of trusted CAs. When your server presents a certificate signed by one of these CAs, the browser can verify the CA’s signature using the CA’s public key (which is already in the browser’s trust store). If the signature matches, the browser trusts that the CA performed its due diligence and the certificate is valid.
Internally, a CSR is a structured text file, typically in PEM format. It’s essentially a public key and a set of distinguished name (DN) attributes. The most crucial DN attribute is the Common Name (CN), which must match the fully qualified domain name (FQDN) of the server you intend to secure. For example, if you’re securing www.example.com, your CN should be www.example.com. Wildcard certificates also use a wildcard in the CN, like *.example.com.
Here’s a peek at what a CSR might look like (simplified):
-----BEGIN CERTIFICATE REQUEST-----
MIIBvzCCAQQCAQAwRTELMAkGA1UEBhMCVVMxEzARBgNVBAoMCkV4YW1wbGUgSW5jMRMw
EQYDVQQKDApFeGFtcGxlIEluYzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
ALp7QyH+Xw3s3j/U... (lots of encoded data) ...zBqgK2TqY2j
-----END CERTIFICATE REQUEST-----
The data within is encoded using ASN.1 (Abstract Syntax Notation One) and then Base64 encoded for transport. When you generate a CSR using tools like OpenSSL, you’re creating this structure.
The exact command to generate a CSR with OpenSSL involves creating a private key first, then using that key to sign the CSR.
# Generate a private key
openssl genrsa -out server.key 2048
# Create the CSR, prompting for details
openssl req -new -key server.key -out server.csr
During the openssl req command, you’ll be prompted for information like:
- Country Name (2 letter code):
US - State or Province Name (full name):
California - Locality Name (eg, city):
San Francisco - Organization Name (eg, company):
Example Inc - Organizational Unit Name (eg, section):
IT Department - Common Name (e.g. server FQDN or YOUR name):
www.example.com - Email Address:
admin@example.com
The CA uses the Common Name (CN) to bind the certificate to a specific domain. If you create a CSR for www.example.com but later try to use the issued certificate on mail.example.com, it will fail validation. Many modern CAs also support Subject Alternative Names (SANs) within the CSR, which allows you to list multiple domain names (e.g., www.example.com, example.com, blog.example.com) that the certificate should be valid for. This is often specified in a configuration file passed to OpenSSL, rather than through interactive prompts.
# Example of creating a CSR with SANs using a config file
openssl req -new -key server.key -out server.csr -config openssl.cnf
The openssl.cnf file would contain a section like this:
[ req ]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[ req_distinguished_name ]
C = US
ST = California
L = San Francisco
O = Example Inc
OU = IT Department
CN = www.example.com
[ v3_req ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = www.example.com
DNS.2 = example.com
DNS.3 = blog.example.com
This ability to specify multiple SANs within the CSR is critical for securing multiple hostnames with a single certificate, a common requirement for modern web infrastructure.
The most surprising thing about the CSR’s role is that the request itself isn’t cryptographically secure in transit to the CA. It’s just a piece of data containing your public key and identity claims. The security comes from the fact that only you have the corresponding private key. When the CA issues the certificate, they sign your public key with their trusted private key. The browser later verifies the CA’s signature using the CA’s public key. The CSR’s job is done once the CA has verified your request and issued your certificate.
The next step after obtaining your signed certificate is to install it on your web server, which involves configuring your web server software (like Apache or Nginx) to use the certificate file and its corresponding private key.