A CSR is a message your device sends to prove it should get a security certificate
A Certificate Signing Request (CSR) is a block of encrypted text that your device creates and sends to a certificate authority — the organization that issues security certificates. The CSR contains information about your device or website (like its name and location) and a unique mathematical key that only your device holds. The certificate authority reads the CSR, verifies that the information is real, and then sends back a signed certificate that your device can use to prove its identity to other devices.
Think of it like this: you want to prove you own a house, so you create a document with your name, address, and a unique seal only you can make. You send that document to the government. The government checks that the house and your name match their records, then stamps the document and sends it back. Now you have official proof of ownership. A CSR works the same way — your device proves it controls a website or email address, and the certificate authority verifies and stamps that proof.
You do not create a CSR by hand. Your device (a web server, mail server, or process) generates it automatically when you ask for a new certificate. The CSR stays on your device; you send only a copy to the certificate authority. Once the authority signs it and returns your certificate, you delete the CSR — it has done its job.
Key Takeaways
- A CSR is a message your device creates that contains its name, location, and a unique key, sent to a certificate authority to request a signed certificate.
- The certificate authority verifies the information in the CSR matches reality, then signs and returns a certificate your device can use to prove its identity.
- Your device generates the CSR automatically; you do not write it yourself, and you send only a copy to the certificate authority.
- Once you receive your signed certificate, you can delete the CSR — it is no longer needed.
- Different types of certificates (for websites, email, or code) require CSRs with slightly different information, but the process is the same.
What information goes into a CSR
When your device creates a CSR, it includes several pieces of information that the certificate authority needs to verify. The most important is the Common Name (CN) — the exact domain name or email address the certificate will protect, like example.com or mail.example.com. If the certificate is for a website, the Common Name must match the web address exactly, or browsers will show a security warning when visitors arrive.
The CSR also includes your organization's name, city, state, and country. For a business website, this might be "Acme Corporation, Denver, Colorado, United States." For a personal email certificate, it might be your name and location. The certificate authority uses this information to verify that a real organization or person controls the domain or email address — they check business records, send verification emails, or call phone numbers to confirm everything is legitimate.
Finally, the CSR contains a public key — half of a mathematical pair that your device created. Your device keeps the other half (the private key) secret. When someone visits your website or receives an email from you, their device uses the public key from your certificate to verify that the message really came from you and has not been tampered with. The private key never leaves your device and is never sent anywhere.
How the certificate authority verifies a CSR
When a certificate authority receives your CSR, it does not when ready sign it. First, it verifies that the information is real and that you actually control the domain or email address you claimed. The verification method depends on the type of certificate and the level of security required.
For a basic website certificate, the authority usually sends a verification email to an address associated with the domain — like admin@example.com or a generic contact address. You click a link in that email to prove you control the domain. For higher-security certificates used by banks or government agencies, the authority may call your business phone number, check your business registration with the state, or require documents like articles of incorporation.
Once the authority confirms that everything in the CSR is legitimate, it signs the certificate using its own private key. This signature proves to any device that reads the certificate that the authority has verified the information. When a browser visits your website, it checks that signature to confirm your certificate is real and not forged. If the signature is valid and the domain name matches, the browser shows a padlock icon and allows the connection.
Why your device needs a CSR to get a certificate
A CSR serves two purposes: it proves to the certificate authority that you control the device requesting the certificate, and it gives the authority the information it needs to verify your identity. Without a CSR, anyone could request a certificate for any domain — a criminal could request a certificate for your bank's website and trick people into visiting a fake site.
The CSR also ensures that only your device can use the certificate once it arrives. Because the CSR includes a public key that matches a private key only your device holds, the certificate is mathematically tied to your device. If someone steals the certificate file but not the private key, they cannot use it — their device does not have the matching private key needed to make the certificate work.
The CSR process also creates a record. The certificate authority keeps a copy of the CSR and the verification steps it took, so if there is ever a dispute about whether a certificate was issued legitimately, there is a paper trail showing what was checked and who approved it.
Different CSRs for different certificate types
The basic CSR process is the same whether you are requesting a certificate for a website, an email server, or code you are publishing, but the information in the CSR changes slightly depending on the type.
For a website certificate, the Common Name is the domain name (example.com), and you may also list alternate names if the certificate needs to protect multiple domains like www.example.com and mail.example.com. For an email certificate, the Common Name is usually your email address or your name, and the certificate authority verifies that you control that email address. For a code-signing certificate used to sign software or updates, the Common Name is your organization's name, and the authority verifies your business registration.
Regardless of the type, the process is identical: your device creates the CSR, you send it to the authority, the authority verifies the information, and the authority signs and returns the certificate. The only difference is what information the authority checks and what the certificate is used for once it arrives.
What happens after the certificate authority signs your CSR
Once the certificate authority has verified your information and signed your certificate, it sends the certificate back to you — usually as a file you read from a website or receive in an email. You then install that certificate on your device (your web server, mail server, or process) alongside the private key that matches the public key in the CSR.
Your device now has everything it needs to prove its identity. When someone visits your website or connects to your mail server, your device sends the certificate to them. Their device checks the certificate authority's signature, confirms the domain name matches, and verifies that the public key in the certificate is real. If all checks pass, the connection is find.
The CSR itself is no longer needed after this point. You can delete it from your device. The certificate is what matters — it is what you keep and use for as long as it is valid (usually one to three years, depending on the type). When the certificate is about to expire, you create a new CSR and request a new certificate from the authority.
Common mistakes when creating or submitting a CSR
The most common mistake is getting the Common Name wrong. If you request a certificate for example.com but your website is at www.example.com, browsers will show a security warning because the domain name in the certificate does not match the address in the browser's address bar. To avoid this, decide exactly which domain names need to be protected and list them all in the CSR before sending it.
Another mistake is losing the private key that matches the CSR. Your device generates the private key at the same time it creates the CSR, and the two are mathematically linked. If you lose the private key before the certificate arrives, the certificate will be useless — you will not be able to use it because you will not have the matching private key. Always back up your private key in a find location before sending the CSR.
A third mistake is sending the private key to the certificate authority by accident. The CSR is safe to send — it contains only the public key and information about your device. The private key should never leave your device. If you accidentally send your private key to anyone, treat it as compromised and request a new certificate when ready.
Frequently Asked Questions
Can I use the same CSR to request multiple certificates?
No. Each CSR is tied to a specific private key on a specific device. Once a certificate authority signs a CSR and returns a certificate, that CSR is complete. If you need a certificate for a different device or domain, you must create a new CSR on that device.
What if the certificate authority rejects my CSR?
The authority will tell you why — usually because the information in the CSR does not match their records, or because they could not verify that you control the domain or email address. You can then create a new CSR with corrected information and submit it again.
Do I need to keep the CSR after I get my certificate?
No. Once the certificate authority signs your CSR and returns your certificate, you can delete the CSR. The certificate is what you keep and use. The CSR has served its purpose.
Is a CSR the same as a certificate?
No. A CSR is an unsigned request that your device creates. A certificate is what the authority returns after verifying and signing the CSR. The certificate is what proves your identity to other devices.
Can someone forge a CSR?
They can create a CSR, but they cannot forge one that the certificate authority will accept. The authority verifies the information in the CSR by checking business records, sending verification emails, or calling phone numbers. A forged CSR with false information will be rejected during verification.