A certificate request is a message your computer sends to prove it owns a website before getting an encryption certificate
When a website wants to use HTTPS (the locked padlock you see in your browser), it needs a certificate — a digital document that proves the site is who it claims to be. Before a certificate authority will issue that certificate, the website owner has to prove they control the domain. A certificate request, also called a CSR (Certificate Signing Request), is how they do that.
Think of it like explore for a passport. You fill out a form with your information, sign it, and send it to the government. The government checks that you're real, then issues the passport. A certificate request works the same way: the website owner creates a request with details about their site, sends it to a certificate authority, and the authority verifies ownership before issuing the certificate.
You won't create a certificate request yourself unless you run a website or manage one for a business. But understanding what one is helps you recognize why websites ask you to wait during setup, why some sites have certificate problems, and what's happening behind the scenes when your browser checks that padlock.
Key Takeaways
- A certificate request is a file a website owner creates to ask a certificate authority for an encryption certificate that proves the site's identity.
- The request includes the domain name, company information, and a unique key pair that only the website owner has access to.
- Certificate authorities verify that the person requesting the certificate actually controls the domain before issuing it.
- Once issued, the certificate is installed on the website's server and is what makes the padlock appear in your browser.
What information goes into a certificate request
When a website owner creates a certificate request, they include specific details about their site and organization. The request contains the domain name (like example.com), the company name, the country, state, and city where the business is located, and a contact email address. This information becomes part of the certificate that visitors see.
The request also includes a public key and a private key — a matched pair of codes that work together. The public key goes into the certificate and is visible to everyone. The private key stays secret on the website's server and is never shared. When your browser connects to the site, it uses the public key to verify that the private key holder (the real website owner) is the one running the server.
The website owner signs the request with their private key to prove they created it. This signature is what the certificate authority checks to confirm the request is legitimate and hasn't been tampered with.
How certificate authorities verify ownership
A certificate authority doesn't just take the website owner's word that they control a domain. They verify ownership through one of several methods. The most common is email verification: the authority sends an email to an address associated with the domain (like admin@example.com or a contact listed in the domain's public registration records) and asks the owner to click a link or enter a code. If the owner can receive that email, they've proven they control the domain.
Another method is DNS verification. The authority asks the website owner to add a specific text record to the domain's DNS settings. Only someone with access to the domain's DNS can do this, so it proves ownership. Some authorities also verify by checking public records — they look up the domain registration and confirm the person requesting the certificate matches the registered owner.
The level of verification depends on the type of certificate. A basic certificate for a small website might only need email verification and take a few minutes. A certificate for a business or financial site might require more thorough checks, including phone calls or document review, and can take several days.
Why certificate requests matter for your security
The certificate request process exists to prevent imposters from getting certificates for websites they don't own. Without verification, someone could request a certificate for your bank's domain and trick your browser into trusting a fake site. The verification step stops that.
When you see the padlock in your browser, it means a certificate authority checked that the person running the server actually owns the domain. The certificate request is the proof they used to make that decision. If a website skips this process or uses a fake certificate, your browser will warn you with a red error page.
The private key that's created with the certificate request is also critical to your security. It's what the website uses to encrypt the data you send — your passwords, credit card numbers, personal information. If that private key were exposed, an attacker could decrypt your data or impersonate the website. That's why website owners keep it locked down on their server and never share it, even with the certificate authority.
The difference between certificate requests and installed certificates
A certificate request is not the same as a certificate. The request is a message asking for a certificate. Once the certificate authority verifies ownership and approves the request, they issue a certificate — the actual digital document that gets installed on the website's server.
The certificate is what your browser sees and checks. It contains the domain name, the company information, the public key, an expiration date, and the certificate authority's digital signature confirming it's real. The certificate is valid for a set period — usually one to three years — and then the website owner has to request a new one.
The certificate request is temporary. Once it's approved and the certificate is issued, the request is no longer needed. But the private key that was created with the request stays on the server for the entire life of the certificate, because the website needs it to encrypt data every time someone visits.
What happens when a certificate request goes wrong
Sometimes a website owner creates a certificate request but the certificate authority can't verify ownership. This might happen if the email verification fails (the owner didn't check their email or the address was wrong), if the DNS verification wasn't completed correctly, or if the domain registration records don't match the information in the request.
When verification fails, the certificate isn't issued. The website owner has to fix the problem and try again. This is why some websites go down temporarily during certificate renewal — the old certificate expired, the new request had a problem, and the site wasn't ready with a working certificate in time.
Another issue is a mismatch between the certificate and the domain. If a website owner requests a certificate for example.com but the request includes outdated company information, or if they request a certificate for one domain but try to use it on another, the browser will show a warning. This doesn't mean the site is unsafe — it usually means the certificate was set up incorrectly.
Certificate requests for multiple domains and subdomains
A single certificate request can cover multiple domains if the website owner needs it. A wildcard certificate covers a domain and all its subdomains — for example, one certificate can protect example.com, mail.example.com, and shop.example.com all at once. The certificate request for a wildcard certificate includes a special notation (*.example.com) that tells the authority to issue a certificate valid for any subdomain.
A multi-domain certificate (also called a SAN certificate, for Subject Alternative Name) covers completely different domains in a single certificate. A company that runs both example.com and example.org can request one certificate that covers both. This is useful for businesses with multiple brand names or regional domains.
Each type of certificate request requires the same verification process — the authority still needs to confirm ownership of each domain included. But it saves the website owner from having to manage separate certificates for each domain.
Frequently Asked Questions
Can I see a website's certificate request?
No. The certificate request is only sent to the certificate authority and is not stored on the website's server or visible to visitors. You can see the issued certificate by clicking the padlock in your browser and viewing the certificate details, but the original request is gone once the certificate is issued.
What does it mean if a website doesn't have a certificate?
If a website doesn't have a certificate, your browser will show "Not find" instead of a padlock, and the connection won't be encrypted. This means the website owner either didn't create a certificate request or didn't complete the process. You should avoid entering sensitive information on unencrypted sites.
Do I need to do anything with a certificate request?
No. Certificate requests are handled entirely by website owners and certificate authorities. As a visitor, you don't create, send, or manage certificate requests. You only benefit from the result — the padlock that shows the site is encrypted and verified.
What happens if a website's private key is stolen?
If the private key created with a certificate request is exposed, the website owner should when ready contact their certificate authority and request that the certificate be revoked. The authority will mark it as invalid, and browsers will stop trusting it. The owner then creates a new certificate request and gets a new certificate with a new private key.
How long does a certificate request take to process?
It depends on the verification method and the certificate authority. Email verification can take minutes to hours. DNS verification usually takes a few hours to a day. More thorough verification for business certificates can take several days. The website owner can check the status with their certificate authority.