How to get an SSL certificate: three routes, one process

9 min readUpdated Oct 2026

Getting an SSL certificate follows the same process whoever runs it: ask an authority to certify some names, prove you control them, send a signing request built from your key, install what comes back. Knowing how to create an SSL certificate is mostly knowing your route, since the route decides who performs each step: your host or CDN, an ACME client on your server, or you, with a paid authority.

Steps: four after account setup: order the names, prove control, finalize with a CSR, download the certificate (RFC 8555 §4) ^[1]
Signing request: a CSR carries a name, your public key and optional attributes, signed by the requester (RFC 2986) ^[2]
Who checks: a publicly trusted certificate authority, which must validate control of every name (Baseline Requirements §3.2.2.4) ^[3]
CAA records: where published, only an authority they permit may issue (RFC 8659 §3) ^[4]
Maximum lifetime: 200 days for certificates issued since 15 March 2026 (Baseline Requirements §6.3.2) ^[3]

Three routes compared

The protocol does not change between routes. What changes is who holds the key, who proves control, and who repeats the work at renewal.

Three routes to a certificate compared, attribute by attribute
Attribute	Your host or CDN	ACME client on your server	Paid authority, by hand
Key and CSR created by	the platform	the client, automatically	you, with OpenSSL or a generator
Control proved by	the platform	the client: a file or a DNS record	you: a DNS record, a file, or an email to the domain contact
Validation	domain validation when issued through ACME	domain validation	DV, OV or EV
Renewal	the platform	the client, on a schedule	a new order each time
Fits when	the platform already terminates HTTPS for the site	you run the server and can schedule a job	a requirement names organisation validation, or a device cannot be automated

Route 1: your host or CDN issues it

If a platform terminates HTTPS for your site, it can get the SSL certificate itself, and the private key stays with it. Let's Encrypt, a free certificate authority, puts this question first in its getting-started guide: will your hosting provider get and manage certificates for you, or do you need to run an ACME client yourself ^[5]? A provider that does it is running that client on your behalf.

Your part:

Add the domain and every hostname you serve to the platform.
Point DNS at the platform, or let it publish the validation record if it manages your zone.
Once it is live, check the names, issuer and expiry date from outside.

Confirm two things before relying on it. Are both the bare domain and www covered? And how is expiry watched, by something independent of the platform? A check run by the renewing system reports success until that system is the part that fails.

Bridge SSL is the certificate layer of Bridge CDN and works this way: issuance and renewal happen as part of serving your site, and no certificate file sits on your server. It works only for hostnames Bridge CDN serves, and it has no import path for a certificate bought elsewhere. If a paid certificate is required, use route 3.

Route 2: an ACME client on your server

An ACME client is the program that does the work when you generate an SSL certificate on your own server. It runs the whole exchange against a free certification authority, or any authority that speaks the ACME protocol. It suits a server where you can install software and schedule a job.

Install a client, register an account. The account has its own key pair, separate from the key in the certificate ^[1].
Order the names. List every hostname, the bare domain and www included.
Prove control. For HTTP-01 the authority fetches a token from /.well-known/acme-challenge/ over TCP port 80; for DNS-01 the client publishes a TXT record at _acme-challenge.<name> ^[1]. A wildcard such as *.example.com needs a DNS method: the Baseline Requirements do not allow the website-file methods for wildcard names ^[3].
Finalize. The client generates a private key and a certificate signing request, and submits the request ^[1].
Download the certificate with its chain, install it, and reload the server.
Schedule renewal. Renewal repeats the same exchange, and most clients generate a new key each time.

The client also has to keep running. Automation that was set up once and then stopped fails in silence, which is why the expiry check from route 1 applies here too.

Route 3: a paid certificate authority

Buying an SSL certificate from a paid authority is the same process done by hand, and it is the only route to organisation or extended validation.

Generate a private key and a certificate signing request on the server that will use the key. Put every name in the subject alternative name field; browsers ignore a name that appears only in the common name.
Choose the validation level, place the order and paste in the CSR.
Prove control of each name with a method the authority offers: a DNS record, a file on the website, or an email to a domain contact ^[3].
For OV, wait while the authority verifies the organisation and its address, through a government agency, a reliable third-party database, a site visit or an attestation letter ^[3]. EV applies a stricter version of the same check.
Receive the certificate and its intermediate certificates, install them with the key, and reload.
For renewal, place a new order before expiry with a fresh key and CSR. Reusing an old request reuses the old key.

Paying is the only way to the organisation check, and it adds a support contract and often warranty terms. The encryption is the same as on the free routes.

Making a self-signed certificate is not getting one

You can use OpenSSL to create a certificate in one command, with no authority involved. That certificate is signed by its own key, so nobody independent vouches for it, and browsers refuse it on public sites. It is the right tool for development and for internal systems where the people connecting can verify the server by other means. For anything a stranger might visit, take one of the three routes above.

Before you request: three checks

These apply on every route, before you create or order an SSL certificate.

Every name is listed. Put every hostname in the certificate signing request. Browsers read only the subject alternative names, and adding a forgotten name later means a reissue. Include the bare domain and www.

CAA allows your certificate authority. Look up the domain's CAA records before ordering:

$ dig +short CAA example.com
0 issue "ca1.example.net"

If issue records come back and none of them names your authority, it must refuse ^[4]. For a wildcard, any issuewild record takes precedence over issue. Add a record for your authority, or order from one that is listed.

The key has a home. Decide where the private key will live before you generate it: on the machine that terminates TLS, readable only by the account that needs it. On route 1 the platform holds it. On routes 2 and 3 it is a file you are responsible for, replaced at each renewal if you generate a fresh one, and it never goes to the authority.

After issuance: install, check, renew

A new SSL certificate is useful only once it is served with its chain. Install the certificate, the intermediate certificates and the private key together, reload the service, and then check how the hostname presents it from outside your network:

$ openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -issuer -dates

The issuer and dates printed should match the new certificate from your certificate authority.

Renewal is part of how you get a certificate, not a separate job. The Baseline Requirements cap a publicly trusted certificate at 200 days if issued since 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029 ^[3]. At those lifetimes manual renewal turns into a recurring task with a hard deadline, which the platform or the ACME client takes over on routes 1 and 2. On route 3 you generate a new key and CSR by hand each time, and every manual repeat is a chance to forget.

FAQ

How do I create an SSL certificate?

For a public site you do not create the SSL certificate yourself. You create a key and a signing request, and a certificate authority signs the certificate after you prove control of the names; an ACME client or your hosting platform can do all of it. Making one entirely on your own produces a self-signed certificate, which browsers refuse on public sites.

How do I get an SSL certificate for free?

Use a platform that issues certificates for the sites it serves, or run an ACME client against a free authority such as Let's Encrypt. Either way you get a domain-validated certificate that browsers trust, on the condition that renewal runs automatically.

How do I apply an SSL certificate to my site?

Install the certificate, its intermediate certificates and the private key on the server or service that terminates HTTPS, then reload it. On the platform route there is nothing to apply, because the platform serves the certificate itself.

How do I generate a private key for an SSL certificate?

Generate it together with the CSR, on the machine that will use it; the openssl req command on the CSR page writes both in one step. ACME clients and platforms generate the key for you. In every case it stays where it was generated and never goes to the authority.

Where can I buy an SSL certificate?

From a publicly trusted certificate authority. Paying is the only way to organisation or extended validation, and it adds support and often warranty terms; the encryption matches that of a free certificate.

Sources

RFC 8555, Automatic Certificate Management Environment (ACME): §4 Protocol Overview, §8.3 HTTP Challenge, §8.4 DNS Challenge.
RFC 2986, PKCS #10: Certification Request Syntax Specification, version 1.7.
CA/Browser Forum Baseline Requirements, version 2.3.1: §3.2.2.1, §3.2.2.4, §4.2.2.1, §6.3.2.
RFC 8659, DNS Certification Authority Authorization (CAA) Resource Record, §3.
Let's Encrypt: Getting Started.