CSR Explained

A Certificate Signing Request, commonly called a CSR, is a request for a digital certificate. CSRs are primarily used when obtaining TLS certificates for HTTPS, but the same concept can be used for other types of public-key certificates. A CSR contains identity information, a public key and a digital signature proving that the requester controls the corresponding private key.

A CSR is not a certificate itself. It is a structured request that is submitted to a Certificate Authority, or CA. The CA validates the request according to its issuance rules and, if approved, creates and signs a certificate containing the requested public key and certificate information.

What Is a CSR?

CSR stands for Certificate Signing Request. It is a standardized data structure, commonly based on PKCS#10, that allows a requester to provide a public key and identifying information to a certificate authority.

The CSR is normally generated together with a private key. The private key stays under the control of the requester, while the CSR contains the corresponding public key. The CSR is then submitted to the CA for certificate issuance.

Private Key
     ↓
Generate public key
     ↓
Create CSR
     ↓
Submit CSR to CA
     ↓
CA validates request
     ↓
Certificate issued

What Does a CSR Contain?

A CSR contains several important pieces of information. The exact fields depend on the request and the certificate authority, but a typical TLS CSR includes a subject, a public key and requested certificate extensions such as Subject Alternative Names.

CSR and Private Keys

The private key is one of the most important parts of the CSR process, but the private key itself is not normally included in the CSR. Instead, the requester uses the private key to create a digital signature over the CSR data.

The corresponding public key is included in the CSR. This allows the CA to associate the requested certificate with the public key while the private key remains under the requester's control.

How CSR Signing Works

A CSR is digitally signed by the requester. The signature demonstrates that the requester possesses the private key corresponding to the public key contained in the request.

CSR data
   ↓
Hash CSR data
   ↓
Sign hash with private key
   ↓
CSR contains public key + signature
   ↓
CA verifies signature with public key

This mechanism helps prevent someone from submitting a certificate request using a public key they do not actually control. However, a valid CSR signature does not by itself prove that the requester owns a domain or organization. Domain and identity validation are separate parts of certificate issuance.

What Is PKCS#10?

PKCS#10 is a standard format for certificate signing requests. Many CSRs generated by OpenSSL and other certificate-management tools use the PKCS#10 structure.

A PKCS#10 request contains a certification request information structure together with a signature. The request information includes the subject, public key and optional attributes.

CSR File Format

CSRs are commonly stored in PEM format. A PEM-encoded CSR is a text representation containing Base64-encoded data between BEGIN and END markers.

-----BEGIN CERTIFICATE REQUEST-----
MIIC...
...
-----END CERTIFICATE REQUEST-----

The same underlying CSR can also be represented using DER, which is a binary encoding. PEM is convenient for configuration files, command-line tools and text-based transmission, while DER is commonly used when a binary representation is required.

Common CSR File Extensions

The file extension does not guarantee the actual encoding. A CSR should be identified by its contents and PEM markers when necessary rather than relying only on its filename.

Subject Fields in a CSR

Traditional CSR subjects can contain distinguished name attributes such as Common Name, Organization, Organizational Unit, Locality, State or Province and Country. The fields used depend on the certificate type and the CA's requirements.

Common Name vs Subject Alternative Name

For modern TLS certificates, Subject Alternative Name, or SAN, is the important extension for identifying hostnames. The Common Name field is still present in many certificates and CSRs, but clients generally rely on SAN when determining whether a certificate matches a hostname.

Subject:
  CN = example.com

Subject Alternative Name:
  DNS:example.com
  DNS:www.example.com

What Is SAN?

Subject Alternative Name is a certificate extension used to specify identities for which a certificate is valid. For TLS certificates, SAN commonly contains DNS names and may also contain IP addresses or other supported identity types.

DNS:example.com
DNS:www.example.com
DNS:api.example.com

A single CSR can request multiple SAN entries. The CA decides which names are ultimately included in the issued certificate after completing its validation process.

Generating a CSR with OpenSSL

OpenSSL can generate a private key and CSR from the command line. A basic example using an RSA key is shown below.

openssl req -new -newkey rsa:2048 -nodes \
  -keyout private.key \
  -out request.csr

This command creates a new RSA private key and a CSR. The -nodes option prevents the private key from being encrypted with a passphrase during generation. In production environments, whether to use an encrypted private key depends on the deployment and secret-management strategy.

Generating a CSR with SANs

For modern HTTPS certificates, the CSR should normally specify the required DNS names through Subject Alternative Name extensions. OpenSSL can generate such requests using a configuration file.

[req]
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no

[req_distinguished_name]
CN = example.com

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = api.example.com

openssl req -new \
  -key private.key \
  -out request.csr \
  -config openssl.cnf

Generating a CSR with an Existing Private Key

A CSR can be generated from an existing private key. This is useful when renewing a certificate while intentionally keeping the same key, although generating a new key can also be preferable depending on the security policy and lifecycle strategy.

openssl req -new \
  -key private.key \
  -out request.csr

The private key remains local. Only the resulting CSR should normally be submitted to the certificate authority.

RSA vs Elliptic Curve CSRs

A CSR can contain a public key based on different cryptographic algorithms. RSA and elliptic curve keys are both commonly used for TLS certificates.

The certificate authority generally does not generate the private key for a normal CSR workflow. The requester generates the key pair and submits a CSR containing the public key.

How a Certificate Authority Processes a CSR

Submitting a CSR starts a certificate issuance workflow. The CA first processes the request and then performs the validation required for the requested certificate type.

CSR submitted
     ↓
CSR syntax checked
     ↓
Signature verified
     ↓
Domain / identity validation
     ↓
Certificate generated
     ↓
CA signs certificate
     ↓
Certificate delivered

The exact process depends on the certificate authority and validation level. For domain-validated certificates, the CA typically verifies control over the requested domain. Other certificate types may require additional organization or identity validation.

CSR Does Not Prove Domain Ownership

A valid CSR only proves that the requester possesses the private key corresponding to the public key in the request. It does not prove that the requester controls a particular domain.

For example, anyone can generate a CSR containing example.com as a requested hostname. The CA must separately verify that the requester is authorized to obtain a certificate for that domain before issuing a trusted certificate.

CSR Validation

Inspecting a CSR before submitting it can reveal configuration mistakes such as an incorrect hostname, missing SAN entries, unexpected subject information or an unsuitable public key.

openssl req -in request.csr -text -noout

The command displays the CSR's human-readable fields, public key information, requested extensions and signature information without modifying the request.

Checking the CSR Signature

A CSR contains a signature that can be verified against the public key contained in the request. This confirms the internal cryptographic relationship between the request and its key pair.

openssl req -in request.csr -verify -noout

A successful verification indicates that the CSR's signature is valid for the public key contained in the request. It does not replace the certificate authority's domain or identity validation.

CSR vs Certificate

CSR vs Private Key

A CSR and private key serve completely different purposes. The CSR is a request that can be shared with the CA, while the private key is secret cryptographic material that must remain under the control of its owner.

Does a CSR Expire?

A CSR does not have the same validity period as an issued certificate. It is a request containing information and a signature rather than a trusted certificate with a not-before and not-after validity period.

A CA may impose its own requirements on how long a request remains useful, but the CSR itself should not be confused with the expiration date of the certificate eventually issued from it.

Can a CSR Be Reused?

A CSR can sometimes be reused if the same public key and requested information remain appropriate, but generating a new CSR is often straightforward. When a new private key is generated, a new CSR is required because the CSR must contain the corresponding public key and signature.

When certificate requirements change, such as adding or removing SAN entries, a new CSR is normally generated to represent the updated request.

Common CSR Errors

• Missing required SAN entries.
• Incorrect domain names.
• Using an unsupported key algorithm.
• Using a key size that does not meet CA requirements.
• Submitting an incomplete CSR.
• Generating the CSR from the wrong private key.
• Accidentally exposing the private key.
• Using incorrect subject information when it is required.
• Providing a malformed PEM file.
• Forgetting to verify the CSR before submission.

CSR and SAN Mismatch

One of the most common practical problems is requesting the wrong hostname. For example, a CSR containing only example.com does not automatically request a certificate for www.example.com or api.example.com.

Requested:
DNS:example.com

Not automatically requested:
DNS:www.example.com
DNS:api.example.com

CSR and Wildcard Certificates

A CSR can request a wildcard hostname such as *.example.com when the certificate authority supports wildcard certificates and the requested validation requirements are satisfied.

DNS:*.example.com

A wildcard certificate generally covers one level of subdomain. For example, *.example.com can cover www.example.com and api.example.com, but it does not normally cover api.dev.example.com.

CSR and IP Addresses

A CSR can request IP address identities through the appropriate SAN entries when supported by the certificate authority and certificate type.

IP:192.0.2.10
DNS:example.com

When a client connects using an IP address, the certificate must contain an appropriate IP SAN rather than relying on a DNS name that happens to resolve to that address.

CSR and Certificate Renewal

Certificate renewal does not necessarily require the same CSR or private key. Organizations can choose whether to reuse an existing key or generate a new key pair as part of the renewal process.

Generating a new key during renewal can provide key rotation and reduce the lifetime of individual private keys. The appropriate strategy depends on the organization's security requirements and operational processes.

CSR Security Best Practices

• Generate the private key on a trusted system.
• Keep the private key secret.
• Use strong, modern key algorithms and sizes.
• Include the correct SAN entries.
• Verify the CSR before submitting it.
• Protect private key files with restrictive permissions.
• Avoid storing private keys in source control.
• Use secure secret-management systems for production keys.
• Rotate compromised private keys immediately.
• Destroy unnecessary private-key copies securely.

Why the Private Key Should Stay Local

The security model of a CSR workflow depends on the private key remaining under the requester's control. The CA does not need the private key to create a certificate. It signs a certificate containing the public key supplied in the CSR.

The CSR can be shared; the private key should remain private.

CSR Generation Workflow

A reliable CSR workflow starts by determining the required certificate names and choosing an appropriate key type. The private key is generated first, followed by the CSR containing the public key and requested certificate information.

1. Determine certificate names
        ↓
2. Generate private key
        ↓
3. Generate CSR
        ↓
4. Add SAN entries
        ↓
5. Inspect CSR
        ↓
6. Submit CSR to CA
        ↓
7. Complete validation
        ↓
8. Receive certificate
        ↓
9. Install certificate + private key

Best Practices

• Use SAN entries for all required DNS names.
• Generate keys using current, secure cryptographic algorithms.
• Keep private keys outside source control.
• Inspect CSRs before submitting them.
• Verify that the CSR signature is valid.
• Confirm that the requested hostnames are correct.
• Keep certificate and private-key files organized.
• Use secure permissions and secret storage.
• Generate a new CSR when certificate requirements change.
• Consider key rotation during certificate renewal.

Frequently Asked Questions

Helpful Certificate Tools

A CSR Generator creates Certificate Signing Requests from the required certificate information, a CSR Decoder displays the contents of existing CSRs, a PEM Certificate Viewer helps inspect PEM-encoded certificates, a Certificate Chain Viewer displays certificate chain information, and a Certificate Expiration Checker helps determine when certificates need to be renewed.

Conclusion

A Certificate Signing Request is an essential part of the certificate issuance process. It connects a public key with requested certificate information and includes a digital signature proving control of the corresponding private key. The CSR itself is not a certificate and does not establish domain ownership or trust.

For reliable HTTPS configuration, generate the private key securely, include all required SAN entries, inspect the CSR before submitting it and keep the private key protected throughout the entire certificate lifecycle. Understanding the difference between a CSR, certificate, public key and private key makes certificate management much easier and helps prevent common TLS configuration and security mistakes.