A certificate signing request is a message you send to a certificate authority asking them to issue you a security certificate
When you want to use encryption on a website or secure a server, you do not go directly to a certificate authority with your encryption key. Instead, you create a Certificate Signing Request (CSR) — a file that contains your public key and information about your organization. You send this file to a certificate authority like DigiCert, Let's Encrypt, or Sectigo, and they use it to create your certificate.
The CSR itself is not your certificate. It is the paperwork you submit. The certificate authority reads it, verifies that you own the domain or organization you claim to own, and then issues you an actual certificate — a separate file that proves your identity to anyone who connects to your server.
You create a CSR on your own server or computer using command-line tools or your hosting control panel. The process takes a few minutes and produces two files: the CSR (which you send to the certificate authority) and a private key (which you keep secret and never share).
Key Takeaways
- A CSR is a file containing your public key and organization details that you send to a certificate authority to request a security certificate.
- You generate a CSR using tools like OpenSSL on Linux, Certbot for Let's Encrypt, or your hosting provider's control panel.
- The certificate authority verifies your identity using the information in your CSR, then issues you a certificate to install on your server.
- Your private key, created alongside the CSR, must stay on your server and never be sent to anyone, including the certificate authority.
- Different types of certificates (domain validation, organization validation, extended validation) require different levels of verification before the certificate authority issues your certificate.
What information goes into a CSR
When you create a CSR, you provide details about yourself or your organization. The certificate authority uses these details to verify your identity and to populate your certificate. The most important field is the Common Name (CN) — the domain name you want to secure, like example.com or mail.example.com.
You also provide your organization name, department, city, state, and country. For a personal website or a small operation, you can leave some of these fields blank or use generic entries. For a business certificate, the certificate authority may verify that your organization actually exists and that you have authority to request a certificate on its behalf.
The CSR also contains your public key — the half of your encryption key pair that you can safely share. The certificate authority does not need your private key; in fact, you should never send it. The certificate authority uses your public key to create a certificate that proves the private key belongs to you.
How to generate a CSR on different systems
The method depends on where your server or website is hosted. Most hosting providers offer a CSR generator in their control panel — usually under a section called SSL, Security, or Certificates. You fill in a form with your domain name and organization details, click generate, and the control panel creates your CSR and stores your private key on the server.
If you manage your own server, you can generate a CSR using OpenSSL, a command-line tool available on Linux and macOS. The command looks like this: openssl req -new -key private.key -out request.csr. You provide your domain name and organization details when prompted, and OpenSSL creates both your private key and your CSR file.
For Let's Encrypt certificates, you typically use Certbot, a tool that automates the entire process — generating the CSR, sending it to Let's Encrypt, receiving the certificate, and installing it on your server. You run a single command and Certbot handles the rest.
Windows servers use a different tool called IIS (Internet Information Services) Manager, which has a built-in CSR generator. You open IIS Manager, navigate to your server name, and use the "Create Certificate Request" option to generate your CSR.
What the certificate authority does with your CSR
Once you send your CSR to a certificate authority, they read the information you provided and verify it. The level of verification depends on the type of certificate you requested. For a domain validation (DV) certificate, they simply confirm that you control the domain by sending you an email to an address listed in the domain's WHOIS record, or by asking you to add a temporary DNS record to your domain.
For an organization validation (OV) certificate, the certificate authority does more work. They verify that your organization actually exists, that you work there, and that you have authority to request a certificate. This might involve calling your business phone number or checking business registration records.
For an extended validation (EV) certificate, the verification is even more thorough. The certificate authority may require legal documents, proof of business ownership, and verification of your physical address. These certificates are more expensive and take longer to issue, but they provide the highest level of trust.
Once the certificate authority verifies your information, they use your public key (from the CSR) to create your certificate and send it back to you. You then install this certificate on your server alongside your private key.
Why you should never share your private key
Your private key is the secret half of your encryption pair. Anyone who has your private key can impersonate your server, decrypt traffic meant for you, or forge certificates in your name. This is why you never send your private key to the certificate authority, even though they ask for your public key.
When you generate a CSR, your server creates both the public key (which goes into the CSR) and the private key (which stays on your server). The certificate authority only needs the public key to create your certificate. Your private key should remain on your server, protected by file permissions that prevent other users from reading it.
If your private key is ever compromised — stolen, leaked, or accidentally shared — you should revoke your certificate immediately and request a new one. Most certificate authorities allow you to revoke a certificate through their website, and you can then generate a new CSR and private key to request a replacement certificate.
Common mistakes when creating a CSR
One frequent error is creating a CSR for the wrong domain. If you want to secure both example.com and www.example.com, you need to specify both names when creating your CSR, usually in a field called Subject Alternative Names (SAN). If you only list example.com, your certificate will not be valid for www.example.com, and visitors will see a security warning.
Another mistake is losing your private key after you generate it. Some hosting providers delete old private keys when you request a new certificate, so you cannot reuse the same CSR later. If you need to move your certificate to a different server, you have to request a new certificate with a new CSR and private key.
A third error is providing incorrect organization information in your CSR. If the name or address in your CSR does not match your business registration or the information the certificate authority finds when they verify you, they may reject your request or issue a certificate with incorrect details.
When you need to create a new CSR
You create a new CSR whenever you request a new certificate. This happens when your current certificate is about to expire, when you want to add new domains to your certificate, or when you are moving your website to a different server or hosting provider.
You do not need a new CSR if you are simply renewing a certificate with the same domain and organization information. Many certificate authorities allow you to renew using your existing certificate, which is faster than requesting a new one from scratch.
If you change your domain name, add subdomains, or move to a different organization, you need a new CSR because the information in the old one no longer matches your situation. The certificate authority will ask you to provide a new CSR before they issue your new certificate.
Frequently Asked Questions
Can I use the same CSR to request certificates from multiple certificate authorities?
Yes, you can send the same CSR to different certificate authorities and they will each issue you a certificate. However, each certificate will be valid only for the domain and organization information in that CSR. If you later change your domain or organization, you will need a new CSR.
What happens if I lose my private key after my certificate is issued?
You cannot recover a lost private key. You will need to revoke your current certificate, generate a new CSR with a new private key, and request a new certificate from your certificate authority. This is why backing up your private key in a secure location is important.
Do I need a CSR if I use Let's Encrypt?
Technically, Certbot (the Let's Encrypt client) generates a CSR for you automatically, but you do not need to create one manually. Certbot handles the entire process, including CSR generation, certificate request, and installation. You only interact with Certbot, not the CSR directly.
Can I edit a CSR after I create it?
No, you cannot edit a CSR once it is created. If you need to change the domain name, organization information, or any other detail, you must generate a new CSR. This is why it is important to double-check your information before submitting your CSR to a certificate authority.
Why does my certificate authority ask for a CSR instead of just issuing a certificate?
The certificate authority asks for a CSR because it proves you control the private key. By sending them a CSR containing your public key, you prove that you have the corresponding private key on your server. This prevents someone else from requesting a certificate for your domain using a different key.