A certificate request is a message your computer sends to prove it is who it claims to be

When your computer needs a digital certificate — the credential that proves its identity on encrypted connections — it first creates a certificate request. This request contains information about your computer or server, a public key (part of the encryption pair), and a digital signature proving you created it. You then send this request to a certificate authority, an organization that verifies your identity and issues the actual certificate.

The certificate request itself does not prove anything yet. It is a form saying "I am this device, with this public key, and I want you to verify that claim." The certificate authority checks whether your claim is true, and if it is, they sign the request and return a certificate. That certificate is what actually gets used on encrypted connections.

Most of the time you never see a certificate request. Your browser, email client, or server software creates one automatically when you need a certificate, sends it to the authority, and installs the result without asking you. But if you are setting up a web server, securing email, or managing certificates for a business, you will create and handle certificate requests directly.

Key Takeaways

  • A certificate request contains your device information, a public key, and proof that you created it, but it is not yet a valid certificate.
  • You send the request to a certificate authority, which verifies your identity and returns a signed certificate if your claim is legitimate.
  • Most software creates certificate requests automatically in the background, but servers and business systems often require manual creation.
  • The request itself proves nothing — only the certificate authority's signature on the returned certificate proves your identity to others.

What information goes into a certificate request

A certificate request includes several pieces of information about the device or person requesting the certificate. The most important are the common name (usually a domain name like example.com or a person's name), the organization name, location, and country. These details tell the certificate authority who or what is asking for the certificate.

The request also includes a public key, which is half of an encryption pair. This public key will be included in the final certificate and used by other computers to encrypt messages that only your device can decrypt. The request proves you have the matching private key by including a digital signature — a mathematical proof that you created the request and possess the private key.

Different types of certificates request different information. A certificate for a web server needs a domain name. A certificate for a person's email needs their name and email address. A certificate for a business server might need department information. The certificate authority uses these details to verify that you actually own or control the thing you are claiming to be.

How a certificate authority processes your request

When you send a certificate request to a certificate authority, they perform several checks. First, they verify that the information in the request is accurate — for a domain, they might check that you control the domain by asking you to add a specific file to your website or by sending a verification email to an address at that domain. For a person, they might check government ID or business records.

Once the authority confirms your identity, they sign the request with their own private key. This signature is what transforms the request into a valid certificate. The signature proves that the certificate authority has verified the information and vouches for it. When another computer receives your certificate, it checks the certificate authority's signature to confirm that the authority really did verify you.

The time this takes varies. A straightforward domain verification might take minutes. A business certificate that requires checking company records might take days. Some certificate authorities offer faster verification for higher fees, while others offer free certificates with slower verification.

The difference between a request and a certificate

A certificate request is unsigned — it is your claim about who you are, but nobody has verified it yet. A certificate is signed — a trusted authority has checked your claim and added their signature to prove they believe it. The signature is the crucial difference. Without it, other computers have no reason to trust the information in the request.

Think of it like a passport process versus a passport. The process is your request: you fill in your information and sign it to prove you created it. The government agency is the certificate authority. They verify your identity, check your documents, and if everything is correct, they sign and issue the actual passport. The signature is what makes it official.

Once you have a certificate, you install it on your device or server. The certificate request is no longer needed — you can delete it. The certificate is what gets used for encrypted connections. Other computers will ask to see your certificate, verify the certificate authority's signature on it, and then trust the information inside.

When you create a certificate request manually

Most people never create a certificate request because their software does it for them. But if you are setting up a web server, you will need to create one. On a Linux or Unix server, you typically use the openssl command-line tool. On Windows, you might use Internet Information Services (IIS) or a third-party tool. The process involves specifying the domain name, organization, and location, then running a command that generates the request and saves it to a file.

Once you have created the request file, you send it to a certificate authority through their website. You paste the request into a form, choose what type of certificate you want, and select how they should verify your identity. The authority then processes it and sends back a certificate file, which you install on your server.

If you are managing certificates for a business, you might create dozens of requests — one for each server, domain, or service that needs encryption. Some organizations use certificate management software that automates the process, creating and renewing requests on a schedule so certificates never expire without being replaced.

Why certificate requests include a signature

The signature in a certificate request proves that you possess the private key that matches the public key in the request. This prevents someone else from creating a request in your name and sending it to a certificate authority. Without the signature, an attacker could request a certificate for your domain, and if the authority was not careful, they might issue it.

The signature is created using your private key, which only you have. The certificate authority can verify the signature using the public key in the request, confirming that the request really came from whoever has the private key. This does not prove your identity — it only proves that you created the request. The certificate authority still needs to verify that you actually own the domain or are who you claim to be.

Certificate requests and certificate renewal

Certificates expire — typically after one year, though some last longer. When your certificate is about to expire, you create a new certificate request and send it to the certificate authority. You can use the same private key (creating a request with the same public key) or generate a new key pair and create a request with a new public key.

Most people keep the same private key when renewing because it is simpler. The certificate authority verifies your identity again, signs the new request, and sends back a new certificate with a later expiration date. You install the new certificate on your server, and encrypted connections continue to work without interruption.

Some certificate authorities offer automated renewal, where they periodically create new requests on your behalf, verify your identity through an automated process, and install the new certificate without you having to do anything. This prevents the common mistake of letting a certificate expire and breaking encrypted connections.

Frequently Asked Questions

Can someone else use my certificate request to get a certificate in my name?

Not easily. The request includes a signature that proves you have the private key. An attacker would need your private key to create a valid request. However, if an attacker obtains your request file and sends it to a certificate authority, the authority might issue a certificate if they do not verify your identity carefully. This is why you should keep your private key secret and only send requests to trusted certificate authorities.

What happens if I lose my private key after sending a certificate request?

You can still receive and use the certificate — the private key and the certificate request are only needed to create the request. However, you will not be able to renew the certificate later using the same key, and you will not be able to decrypt messages encrypted with that certificate's public key. You would need to create a new request with a new key pair.

Do I need to keep my certificate request after I receive the certificate?

No. Once the certificate authority signs your request and returns the certificate, you can delete the request file. You only need to keep the certificate and the private key. The request was just the intermediate step to get the certificate issued.

Why do some certificate authorities verify identity differently?

Different types of certificates require different verification levels. A domain validation certificate only needs to prove you control the domain, so the authority sends a verification email or asks you to add a file to your website. A business certificate might require checking company records. An extended validation certificate requires in-person verification or notarized documents. Higher verification levels take longer but provide stronger proof of identity.

Can I create a certificate request without a private key?

No. The request must include a signature created with a private key, which proves you have the key. The process of creating a certificate request automatically generates a private key (if you do not already have one) and uses it to sign the request. You cannot separate these steps.