A Certificate Signing Request (CSR) is a data block generated during the setup of a digital certificate. It contains a public key and identifying information such as domain name, organization, and location. The CSR is submitted to a Certificate Authority (CA) to request a signed certificate.
When a website or system needs to establish encrypted communication, it generates a private-public key pair. The public key and identity details are bundled into a CSR. This file is then sent to a trusted CA, which verifies the requester's identity and issues a signed certificate. The original private key remains secure on the server.
The CSR itself is not a certificate. It is a formal request for one. Once signed by a CA, the resulting certificate enables HTTPS encryption, browser trust, and secure authentication. Without a properly formatted CSR, the certificate issuance process cannot begin.
A CSR is created using cryptographic tools like OpenSSL or through server software such as Apache, Nginx, or IIS. The process begins with generating a private key. That key is then paired with identity data-common name (CN), organization (O), organizational unit (OU), locality (L), state (ST), and country (C)-to form the CSR.
The request is encoded in PKCS#10 format, typically in Base64-encoded PEM text. This format ensures compatibility across systems and CAs. The resulting file includes the public key and a digital signature created with the private key. The CA uses the signature to verify that the request came from the rightful owner of the private key.
For example, when setting up SSL for example.com, a server administrator runs:
openssl req -new -keyout example.key -out example.csrThis command creates a private key (example.key) and a CSR (example.csr). The user inputs required fields like CN=example.com, O=Acme Inc., L=New York, ST=NY, C=US. The resulting CSR file is then pasted into a CA's online portal.
A CSR contains several essential elements:
These components ensure that the CA can validate the requester's identity and issue a certificate that accurately reflects the entity's credentials. If any field is incorrect, the CA may reject the request or issue a certificate with mismatched details.
For instance, a CSR with CN=www.example.com but issued for example.com will trigger browser warnings. Browsers enforce strict matching between the requested domain and the certificate's Common Name field.
While CSRs are standardized, their application varies based on the environment and purpose. The most common types include:
| Type | Use Case | Example Format |
|---|---|---|
| Single Domain | Secure one website (e.g., www.site.com) | CN=www.site.com, O=Company LLC |
| Wildcard | Secure multiple subdomains (e.g., *.site.com) | CN=*.site.com, O=Company LLC |
| Multi-Domain (SAN) | Protect multiple domains in one certificate | CN=site.com, SAN=site.com,www.site.com,mail.site.com |
Wildcard CSRs are useful for organizations managing many subdomains. For example, a university might use a wildcard CSR for login.university.edu, student.university.edu, and staff.university.edu-all under one certificate.
Multi-domain CSRs require Subject Alternative Names (SANs). These are added during CSR generation and allow multiple hostnames to be included. The CA validates each listed domain before issuing the certificate.
Many people mistake a CSR for a private key or a signed certificate. A CSR is not the private key-it is derived from it. The private key must remain confidential and never shared. If leaked, attackers can impersonate the server and decrypt traffic.
Another frequent error is assuming that a CSR can be reused. Each CSR is tied to a specific private key and domain. Reusing a CSR for a different domain results in a mismatched certificate and security failures. For example, using a CSR for example.com to request a certificate for blog.example.com leads to a validation failure.
Some assume that the CA signs the CSR directly. In reality, the CA verifies the information and signs the public key with its own private key. The result is a chain of trust: client → CA root → intermediate → end-entity certificate.
Consider a small business launching a new e-commerce site at shop.mystore.com. To enable HTTPS, they follow these steps:
openssl genrsa -out mystore.key 2048.openssl req -new -keyfile mystore.key -out mystore.csr.Once installed, browsers display a padlock icon and confirm the connection is secure. The entire process hinges on a correctly formed CSR.
I once configured a CSR for a client's IIS server. The initial request failed because the Common Name included a trailing space. The CA rejected it. After removing the space and regenerating the CSR, the certificate issued within 15 minutes. This shows how sensitive formatting is-even a single character matters.
One overlooked detail is that the CSR does not contain the private key. It only includes the public key. The private key is stored separately and must be kept secure. If the private key is lost, the certificate becomes unusable and must be reissued.
Another point: CAs do not sign CSRs blindly. They perform validation checks. For Domain Validation (DV), they may send an email to [email protected] or place a file on the web server. For Organization Validation (OV) or Extended Validation (EV), they verify legal registration documents.
According to the CA/Browser Forum's Baseline Requirements (Version 1.8.3), CAs must validate the requester's control over the domain before issuing a certificate. This prevents phishing sites from obtaining valid certificates.
Also, some CAs accept CSRs in DER binary format, but most prefer PEM (Base64-encoded text). Always confirm the expected format with your CA. Using the wrong format causes upload errors and delays.
After creating a CSR, the next step is submitting it to a CA. The CA processes the request and returns a signed certificate. You then install the certificate on your server along with the private key.
Understanding what is meant by CSR is foundational to deploying secure websites, APIs, and internal services. It's not just a technical step-it's a critical component of digital trust.