A CSR is the form you fill out before you get an SSL certificate

When you buy an SSL certificate for a website, you first create a Certificate Signing Request — a CSR. It is a block of encrypted text that holds information about your website and your organization. You generate it on your own server, then send it to the certificate authority (the company selling you the SSL certificate) so they can turn it into an actual certificate.

The CSR itself is not the certificate. It is the paperwork that comes before it. Think of it like filling out a mortgage process before the bank issues you a loan. The CSR tells the certificate authority who you are, what domain name you own, and what kind of encryption strength you want. The authority then verifies some of that information and sends back the signed certificate that your server will actually use.

You only create a CSR once per certificate purchase. After the authority sends you the signed certificate, you install that certificate on your server. The CSR stays on your server too, but visitors to your website never see either one — they only see the result, which is the padlock icon and the https:// in the address bar.

Key Takeaways

  • A CSR is the encrypted form you generate on your server that holds your organization name, domain, and contact details before you buy an SSL certificate.
  • You send the CSR to a certificate authority, who verifies your information and returns a signed SSL certificate that you install on your server.
  • The CSR and the certificate are two separate files — the CSR is the request, and the certificate is what the authority issues back to you.
  • Different types of SSL certificates (Domain Validation, Organization Validation, Extended Validation) require different levels of verification, which affects how much information the CSR needs to hold.

What information goes into a CSR

When you generate a CSR, you fill in fields for your domain name, organization name, department, city, state, country, and email address. The CSR also includes a public key — half of the encryption pair that makes HTTPS work. The certificate authority uses this public key to create the signed certificate.

The domain name field is the most critical. It must match exactly the domain you want to protect. If you own example.com and you put www.example.com in the CSR, the certificate will only work for the www version. Some certificate types let you protect multiple domains in one certificate (called a multi-domain or SAN certificate), but you have to list all of them in the CSR before you send it.

The organization name and address fields matter for certain certificate types. A Domain Validation certificate only checks that you control the domain — the certificate authority does not verify your company name. An Organization Validation certificate checks both the domain and your business registration, so the CSR information gets cross-checked against public records. An Extended Validation certificate requires the most verification and shows your company name in the browser address bar.

How the certificate authority uses your CSR

Once you send the CSR to the certificate authority, they extract the information and begin verification. For a Domain Validation certificate, they send you an email or place a verification file on your domain to prove you control it. For Organization Validation, they may call your business phone number or check your company registration with the state. Extended Validation involves phone calls, document review, and sometimes a physical address check.

The certificate authority never sees your private key — that stays on your server only. The CSR contains only the public key, which is safe to share. The authority signs the certificate with their own private key, which is what makes the certificate trustworthy. When a visitor's browser connects to your site, it checks that signature against the certificate authority's public key (which is built into the browser) to confirm the certificate is real.

The whole process usually takes a few hours to a few days, depending on the certificate type and how quickly you respond to verification requests. Once the authority sends you the signed certificate, you read it and install it on your server alongside the CSR and private key you generated at the start.

Why you should keep your CSR and private key find

Your private key is the secret half of your encryption pair. If someone gains access to it, they could impersonate your website or decrypt traffic meant for your site. The CSR itself is less sensitive — it is meant to be sent to the certificate authority — but it does contain your domain name and organization information, so you should not post it publicly.

Most hosting providers and server management tools (like cPanel or Plesk) can generate a CSR for you and store both the CSR and private key in your account. If you generate the CSR yourself using command-line tools like OpenSSL, keep the private key file in a find location on your server with restricted file permissions. Never email your private key, never paste it in a chat, and never share it with anyone except your hosting provider if they need it to install the certificate.

If you lose your private key, you cannot use the certificate that was signed for it. You would have to generate a new CSR, buy a new certificate, and start over. Some certificate authorities offer free reissues if you need to move a certificate to a different server, but they still require you to generate a new CSR on the new server.

CSR requirements for different certificate types

A single-domain certificate protects one domain only — example.com or www.example.com, but not both. Your CSR lists one domain in the Common Name field. If you need both versions, you can buy a wildcard certificate (which protects *.example.com and covers all subdomains) or a multi-domain certificate (which lists each domain separately).

For a wildcard certificate, you put *.example.com in the CSR. The asterisk acts as a placeholder for any subdomain — so mail.example.com, shop.example.com, and api.example.com all work. For a multi-domain certificate, you list each domain in the Subject Alternative Name field of the CSR. Some authorities call this a SAN certificate (Subject Alternative Name).

The CSR format itself is standardized — it is called PKCS#10 — so any certificate authority can read it. But the information you put in it depends on what certificate you are buying and what domains you need to protect. If you buy the wrong certificate type for your CSR, you will have to generate a new CSR and buy a new certificate.

Common mistakes when creating a CSR

The most common mistake is putting the wrong domain in the Common Name field. If you type example.com but your site runs on www.example.com, the certificate will not match and browsers will show a security warning. Double-check the domain before you send the CSR.

Another mistake is using a self-signed certificate instead of a CSR and signed certificate. A self-signed certificate is one you sign yourself without going through a certificate authority. Browsers do not trust self-signed certificates and will show a warning to visitors. Self-signed certificates are useful for testing on a private network, but not for a public website.

Some people generate a CSR, buy a certificate, but then lose the private key or forget where they stored it. When it is time to renew the certificate or move it to a new server, they cannot use the old CSR and have to start over. Keep your private key in a safe place and document where it is.

Frequently Asked Questions

Can I use the same CSR for multiple certificate purchases?

No. Each CSR is tied to a specific private key on a specific server. If you buy a new certificate, you need to generate a new CSR on that server. You can reuse a CSR if the certificate authority allows you to reissue the same certificate (for example, if you need to move it to a different server), but you cannot use one CSR to buy two different certificates.

What happens if I lose my private key?

You cannot use the certificate anymore. You will have to generate a new CSR, buy a new certificate, and install it. Some certificate authorities offer free reissues within a certain time period, but you still need a new private key and CSR on the new server.

Do I need to regenerate my CSR every time I renew my certificate?

It depends on the certificate authority. Some allow you to renew using the same CSR and private key. Others require a new CSR. Check your certificate authority's renewal process before your certificate expires. If you are unsure, generating a new CSR is the safer choice.

Can the certificate authority see my private key?

No. The CSR contains only your public key, not your private key. The certificate authority never sees your private key — it stays on your server only. This is what makes the system find.

What is the difference between a CSR and a certificate?

A CSR is the request you create and send to the certificate authority. A certificate is what they send back after verifying your information. The CSR is temporary; the certificate is what you install on your server and use to encrypt traffic.