A certificate signing request is a message you send to a certificate authority asking them to issue you a digital certificate
When you need a digital certificate — whether for a website, email, or internal server — you don't ask the certificate authority to create the whole thing. Instead, you create a certificate signing request (CSR), which is a block of encrypted text that contains your information and a public key. You send this request to the certificate authority, they verify who you are, and then they sign it with their private key to create your actual certificate.
Think of it like applying for a passport. You fill out the application form (your CSR), include proof of identity, and send it to the government office (the certificate authority). They check your documents, add their official seal (their signature), and send back your passport (your certificate). The certificate authority never sees your private key — you keep that completely secret. Only the public key goes into the request.
You generate a CSR on your own server or computer using tools like OpenSSL, your web hosting control panel, or your application's built-in certificate management. The certificate authority then uses that CSR to create a certificate that matches your server's configuration.
Key Takeaways
- A certificate signing request contains your public key and identifying information, but never your private key, which you keep secret on your server.
- You generate the CSR yourself using OpenSSL, your hosting control panel, or your application's certificate tools before contacting a certificate authority.
- The certificate authority verifies your identity, signs the CSR with their private key, and returns a certificate that proves your identity to visitors or clients.
- If you lose the private key that matches a CSR, you cannot use the resulting certificate, so back up your keys in a secure location.
- Different types of certificates (domain validation, organization validation, extended validation) require different verification steps before the authority will sign your CSR.
What information goes into a certificate signing request
A CSR contains several pieces of information about you and your organization. The most important are the common name (usually your domain name like example.com), your organization name, your location (country, state, city), and your email address. It also includes a public key that the certificate authority will embed into your certificate.
When you generate a CSR, your system creates a matching private key at the same time. This private key stays on your server and never leaves it — not in the CSR, not in emails, not anywhere. The CSR only holds the public key, which is safe to share. The certificate authority uses both the public key from your CSR and their own private key to create your certificate.
The exact fields required depend on the type of certificate. A domain validation certificate might only need your domain name. An organization validation certificate requires your legal business name, address, and phone number so the authority can verify you actually own that business.
How to generate a certificate signing request
The easiest route depends on what you're securing. If you use a web hosting control panel like cPanel, Plesk, or WHM, there is usually a certificate management section where you can generate a CSR with a form. Fill in your domain name, organization name, and location, click generate, and the system creates both the CSR and the private key.
If you're working on a Linux or Mac server, you can use OpenSSL from the command line. The command looks like this: openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr. This creates both a private key file (yourdomain.key) and a CSR file (yourdomain.csr). You then copy the contents of the CSR file and paste it into your certificate authority's order form.
On Windows servers, you can use IIS (Internet Information Services) to generate a CSR through the certificate request wizard, or use OpenSSL if you have it installed. Some applications like Apache or Nginx have their own certificate management tools. The principle is always the same: you provide your information, the tool generates a CSR and a private key, and you send only the CSR to the certificate authority.
What the certificate authority does with your CSR
Once you submit your CSR, the certificate authority verifies the information you provided. For a domain validation certificate, they usually send you an email at the domain's administrative address asking you to confirm you control that domain. You click a link or enter a code, and that's enough verification.
For an organization validation certificate, they go further. They might call your business phone number, check business records, or verify your address. This takes longer — sometimes a week or more — but the certificate carries more weight because the authority has actually confirmed your organization exists and is legitimate.
Once verification is complete, the authority signs your CSR with their private key. This signature proves that the certificate authority has verified the information and issued the certificate. They send you back the signed certificate, which you install on your server alongside the private key you generated earlier. The certificate and private key must match — if you lose the private key, the certificate becomes unusable.
Common mistakes when creating a certificate signing request
The most damaging mistake is losing your private key. If you generate a CSR and its matching private key, then delete the private key or lose access to it, the resulting certificate is worthless. You cannot use it on any server because you have no way to prove you own it. Always back up your private key in a secure location — encrypted storage, a password manager, or a hardware security module if you're handling many certificates.
Another common error is entering the wrong domain name in the common name field. If you enter www.example.com but your certificate authority issues a certificate for example.com (without the www), browsers will show a security warning when visitors go to www.example.com. Check your CSR details carefully before submitting, because fixing this usually means generating a new CSR and paying for a new certificate.
Some people try to reuse a CSR for multiple domains. A single CSR creates a certificate for one domain (or a wildcard domain like *.example.com). If you need to secure multiple domains, you need either a multi-domain certificate (also called a SAN certificate) with a separate CSR, or individual certificates for each domain. Trying to use one CSR for multiple domains will not work.
Certificate signing requests for different certificate types
A domain validation certificate requires only that you prove you control the domain. The CSR needs your domain name and email address. The authority sends a verification email to an administrative address at your domain, you confirm it, and they sign your CSR. This is the fastest and cheapest option, usually issued within hours.
An organization validation certificate requires proof that your organization is real and legitimate. Your CSR must include your legal business name, address, phone number, and the name of an authorized representative. The authority verifies this information against business records and may call your phone number. This takes days or weeks but shows visitors that a real organization stands behind the certificate.
An extended validation certificate requires the most thorough verification. The authority conducts background checks, verifies your legal status, confirms your physical address, and may require documents like articles of incorporation. The CSR process is the same, but the verification that follows is much more rigorous. Browsers display these certificates with a green address bar or company name, signaling maximum trust.
A wildcard certificate secures a domain and all its subdomains (like *.example.com). The CSR uses the wildcard domain name instead of a specific subdomain. This is useful if you have many subdomains but want one certificate instead of dozens.
What happens after you install your certificate
Once the certificate authority signs your CSR and sends you the certificate, you install it on your server alongside the private key. Your web server (Apache, Nginx, IIS, or whatever you use) is configured to use both files together. When a visitor connects to your website, your server sends the certificate to prove its identity, and uses the private key to encrypt the connection.
The visitor's browser checks that the certificate was signed by a trusted certificate authority, that the domain in the certificate matches the domain they typed, and that the certificate has not expired. If all these checks pass, the browser shows a lock icon and establishes an encrypted connection.
Certificates expire — usually after one year, though some last longer. Before expiration, you generate a new CSR, send it to the certificate authority, and install the new certificate. Many hosting providers and certificate authorities send reminders before expiration so you do not accidentally let your certificate lapse.
Frequently Asked Questions
Can I use the same CSR for multiple certificate authorities?
Yes. A CSR is just a request — you can send the same CSR to multiple authorities and get different certificates. However, this is rarely useful. You typically choose one authority, submit your CSR, and use the certificate they issue. If you need a new certificate from a different authority later, you can generate a new CSR.
What if I generate a CSR but never use it?
An unused CSR is harmless. It sits on your server taking up a few kilobytes of space. The private key that matches it is still secret. If you decide not to use the CSR, you can delete both the CSR and the private key. There is no expiration or penalty for generating a CSR and not submitting it.
Can I see what is inside a CSR file?
Yes. You can view a CSR's contents using OpenSSL with the command openssl req -in yourdomain.csr -noout -text. This shows you the domain name, organization, location, and public key before you send it to the certificate authority. Always check this to make sure the information is correct.
What if the certificate authority rejects my CSR?
Rejection usually means the information in your CSR does not match what the authority verified. For example, if you entered your company name as "Acme Inc" in the CSR but business records show "Acme Incorporated," they may reject it. You generate a new CSR with the correct information and resubmit. There is no penalty — you just create another CSR.
Do I need a CSR for every certificate I install?
Yes. Each certificate requires its own CSR and private key pair. If you secure ten domains, you generate ten CSRs (or one CSR for a multi-domain certificate covering all ten). The CSR ties the certificate to a specific private key on a specific server, so you cannot reuse one CSR across multiple servers or domains.