From key pair to issued certificate

You never send your private key to a CA. You send a certificate signing request (CSR). A CSR contains your public key, the names you want on the certificate, and a signature made with your private key proving that you hold it.

1. 1

   Generate the key pair locally

   On the server, or in an HSM, so the private key never exists elsewhere.

2. 2

   Build the CSR

   Public key plus requested subject and SANs, signed with the private key.

3. 3

   Send the CSR to the CA

   Only public information travels.

4. 4

   CA validates the request

   It checks the signature, the names, and — depending on the product — the organisation behind them.

5. 5

   CA issues the certificate

   The CA signs your public key and requested names into a new certificate.

openssl req -new -newkey rsa:3072 -nodes -keyout server.key -out server.csr \
  -subj "/CN=shop.example.com" -addext "subjectAltName=DNS:shop.example.com,DNS:www.example.com"
openssl req -in server.csr -noout -text

Certificates are grouped by how strongly the CA verified the requester. The label is printed on the certificate and reflects a real difference in process.

Most certificates today are issued without a human. ACME is the protocol behind that: a client asks for a certificate for a name, the CA issues a challenge, the client proves control of the name, and the certificate is returned.

1. 1

   Ask

   The client tells the CA which names it wants.

2. 2

   Challenge

   The CA returns a token to be served at a specific HTTP path (HTTP-01) or published as a DNS record (DNS-01).

3. 3

   Prove control

   The client publishes the token. The CA fetches or resolves it to confirm control.

4. 4

   Issue

   The certificate is returned, usually valid for a short period.

5. 5

   Renew

   The same loop runs again well before expiry, ideally without a human noticing.

DNS-01 is the more powerful option because it can issue wildcard certificates and does not require the service to be reachable from the internet. HTTP-01 is simpler but ties issuance to a running web server.

• Deciding which internal names are allowed to exist as certificates at all
• Approving issuance for high-value or customer-facing identities
• Owning the automation: renewal schedules, monitoring and rollback
• Handling the cases automation cannot: new domains, mergers, exceptions