How certificates actually work
From an offline Root CA and browser trust stores to intermediates, leaf certificates, issuance, installation and renewal — the whole chain, illustrated.
Where trust starts
From a Root CA to the certificate in your browser
A Root CA is not trusted merely because it calls itself a root or signs its own certificate. Public trust comes from browser and operating-system vendors accepting its public certificate into a root store after policy review and audits. From that one local trust anchor, signatures delegate authority down through an intermediate CA to the leaf certificate on a website.
-
The CA creates a root key in a controlled ceremony
The operator generates a key pair in tightly controlled hardware, commonly an offline Hardware Security Module (HSM), with witnessed procedures, multiple authorised people and protected backups. The private key is the dangerous half: whoever controls it can create new CA certificates beneath that root. It is therefore kept offline and used only during rare, planned ceremonies.
The operator also creates a Root CA certificate containing the public key, a CA identity, validity dates and extensions such as
Basic Constraints: CA=trueand certificate-signing key usage. It normally signs that certificate with its own private key, making it self-signed. That self-signature proves the certificate is internally consistent; it does not make anyone else trust it. -
The root earns distribution through root-store programs
For public websites, the CA applies separately to browser and operating-system root programs. It supplies the public root certificate, its Certificate Policy and Certification Practice Statement, key-generation evidence, independent audit reports and details of every subordinate CA. The application may be reviewed publicly, and each vendor makes its own inclusion decision.
Inclusion is ongoing permission, not a permanent badge. The CA must keep passing audits, disclose incidents and operate every intermediate beneath the root within policy. A vendor can constrain or remove a root. A private company CA takes a different route: administrators install its root manually on managed devices, so it is trusted only inside that environment.
-
Your browser receives the public root, not the root's private key
Once approved, the root program distributes the public root certificate and trust settings in a browser or operating-system update. That local collection is the trust store. Some browsers use their own store; others use or integrate with the platform store, so two clients can make different trust decisions about the same chain.
The root certificate is public and safe to copy. The root private key is never shipped and is not reachable through a website or TLS request. During an ordinary connection the browser normally does not contact the Root CA to ask whether it trusts the site; it begins with the trust anchors already installed locally.
-
The root delegates day-to-day work to an intermediate CA
During another controlled signing ceremony, the offline root signs an intermediate CA certificate. Its
CA=trueconstraint permits further signing, while path-length, name, policy and key-usage constraints can narrow what it may issue. The root then goes back offline.The intermediate's private key can live in an online, strongly protected issuing system, where it is practical to process normal certificate orders. Separate intermediates isolate products and risk: one can be rotated or revoked without replacing the root already installed on millions of devices. Browsers do not trust an intermediate merely because it says
CA=true; its signature and every constraint must lead back to an accepted root. -
The intermediate validates a subscriber and signs the leaf
The website operator generates its own key pair and sends only a CSR containing the public key and requested names. The issuing CA checks domain control, CAA permission and any OV/EV identity requirements, then signs a leaf certificate. A TLS leaf normally has
CA=false, a server-authentication purpose, Subject Alternative Names, a serial number and a short validity period.The CA also makes public issuance observable through Certificate Transparency. The resulting leaf can identify the named server but cannot issue another certificate. Its private key remains with the website operator; neither the intermediate nor the root needs to see it.
Generate the key and CSR locally · See issued leaves in CT logs
-
The browser builds and verifies the path locally
During TLS, the server presents its leaf followed by the intermediate certificate or certificates. It normally omits the root because the browser must already possess and trust that root; sending an unfamiliar root cannot create trust. The TLS handshake also makes the server prove possession of the leaf's matching private key.
The browser finds a path from leaf to intermediate to a local trust anchor, verifies every signature, then checks hostname/SAN matching, validity times, CA and path constraints, key usages, policies, algorithm strength, Certificate Transparency and applicable revocation information. The chain is accepted only if all of those checks agree. No signature alone is enough, and the Root CA is not contacted to approve the connection in real time.
Inspect the chain a server actually presents · Open every field in a certificate
Primary references: RFC 5280 path validation, Mozilla Root Store Policy, and the Chrome Root Program Policy.
The lifecycle
How a certificate actually gets issued
Every certificate, whether it cost nothing and took nine seconds or cost hundreds and took a week, is issued by the same five movements. The differences between a free Let's Encrypt certificate and an expensive organisation-validated one are all in step 3.
-
You generate a key pair
Two mathematically linked numbers, made on your own machine or server. The private half stays there for the rest of the certificate's life; anything that asks you to upload it — or offers to generate it for you server-side — has quietly changed what the certificate proves.
-
You send a signing request, not a key
The CSR carries your public key, the names you are claiming, and a signature made with the private key. That signature is the proof that you hold the private half of the key you are asking to have certified — it is why a CA never needs to see the key itself.
-
The CA checks you control the name
The CA picks a token and asks you to put it somewhere only the domain's operator could: a DNS TXT record (
dns-01) or a file under/.well-known/acme-challenge/(http-01). It then fetches it back itself. How much more it checks is what separates DV from OV and EV — the table below.Your CAA records are read at this point too: if your DNS names a different CA, this one must refuse, whatever your paperwork says.
-
The CA signs, and publishes
You get back a leaf certificate and the intermediates that connect it to a root the browser already trusts. Since 2018 every publicly trusted certificate is also submitted to the Certificate Transparency logs — append-only, public, permanent. That is why a certificate issued for your domain by mistake, or without your knowledge, is findable rather than invisible.
-
You install the full chain
Leaf first, then each intermediate. The root is never sent — the client already has it. Serving only the leaf is the classic error: it works in the browser you tested with, because that browser cached the intermediate from another site, and fails on phones and API clients.
Step 3, in detail
DV, OV and EV — the only step that differs
All three produce the same encryption and the same padlock. What you are buying above DV is a check on your organisation, not a better certificate.
| Type | What the CA verifies | How long | What a visitor sees |
|---|---|---|---|
| DV domain validation |
That you control the name, by a token in DNS or on the web server. No human involved. | Seconds to minutes | A padlock. |
| OV organisation validation |
The above, plus that your organisation exists in a public registry and the request came from it. | 1–5 days | A padlock. The organisation name is in the certificate, where nobody looks. |
| EV extended validation |
The above, plus documented legal, physical and operational existence, and a verified callback. | 1–3 weeks | A padlock. Browsers removed the green bar in 2019. |
Worth knowing before paying: the visual distinction EV once bought disappeared from every major browser in 2019. OV and EV still have real uses — procurement rules, insurance requirements, and code signing, where a DV certificate is not accepted at all — but "more secure for visitors" is not among them.
After you buy
The files the CA sends back, and what to do with them
A reseller order ends with a download link or an email attachment: usually a ZIP holding three or four files with names nobody explains. They are always the same three things — your certificate, the intermediates above it, and (sometimes) the root you should ignore. The private key is not among them, because it never left your machine.
.pfx.Which file is which
Naming is not standardised, and every CA does it differently. These are the patterns you will actually see:
| What you got | What it is | What to do with it |
|---|---|---|
| example_com.crt also .cer, .pem |
Your leaf certificate. Subject is your domain. | First line of the fullchain. |
| *.ca-bundle also chain.crt, intermediate.crt |
One or more intermediate CA certificates, already concatenated. | Append after the leaf. |
| SectigoRSA…CA.crt a CA's own name |
A single intermediate. Two or three of these is normal. | Append after the leaf, nearest-first. |
| AAACertificateServices.crt "root", "trusted" |
The root. Subject and issuer are the same name. | Leave it out. Clients that do not have it will not trust it because you sent it. |
| example_com.p7b also .p7c |
The whole chain in one PKCS#7 container, no key. | Unpack it first — the format converter splits it into PEM files. |
| example_com.pfx also .p12 |
Chain and private key in one encrypted file. Only appears if the reseller generated the key for you. | Usable as-is on Windows. Anywhere else, extract the PEM parts. If a reseller generated your key, they have held it — treat it as compromised for anything that matters, and re-issue from your own CSR. |
If the names tell you nothing, the contents will. Paste each file into the certificate decoder and read the subject:
- Subject is your domain — the leaf. There is exactly one.
- Subject is a CA name, issuer is a different CA — an intermediate.
- Subject and issuer are identical — a root. Not needed, and harmless only because clients ignore it.
Building the fullchain
A fullchain file is nothing more sophisticated than the files concatenated in order — leaf first, then each intermediate working upward toward the root. No blank lines needed, no root at the end.
cat example_com.crt example_com.ca-bundle > fullchain.pemOn Windows, PowerShell does the same job:
Get-Content example_com.crt, example_com.ca-bundle | Set-Content fullchain.pemOrder is the only thing that can go wrong here. Leaf first: a chain assembled the other way round is rejected by clients that check, and silently accepted by the ones that do not.
If you would rather not do it by hand — or you only have the leaf and no bundle at all — the chain builder takes the leaf, downloads the intermediates from the CA itself, verifies every signature and hands back the finished file.
Where each file goes
| Server | What it wants | Guide |
|---|---|---|
| nginx | ssl_certificate fullchain.pem and ssl_certificate_key example.com.key | nginx |
| Apache 2.4.8+ | SSLCertificateFile fullchain.pem and SSLCertificateKeyFile. Older builds split the chain into SSLCertificateChainFile. | Apache |
| HAProxy | One file with fullchain and key concatenated together. | HAProxy |
| IIS / Windows | A .pfx. Build one from the PEM files with the PFX builder. | IIS |
| Tomcat | A PKCS#12 file, or the same imported into a keystore. | Tomcat |
| Node.js | The fullchain and key read as files at startup. | Node.js |
Then check it from outside
Reloading the server and seeing a padlock in your own browser proves less than it appears to: your browser has cached intermediates from other sites and will quietly repair a chain that is broken for everyone else. Check it from somewhere that has no such cache.
And then again
What renewal actually repeats
A renewal is not a top-up of the certificate you have: it is the entire sequence again, from a fresh CSR. Whether you reuse the same key pair is your choice — reusing it keeps any public key pins valid, generating a new one limits how long a leaked key stays useful.
The reason this matters more each year: certificate lifetimes are dropping to 100 days in 2027 and 47 in 2029, and the reuse period for the step 3 check shrinks alongside them, to 10 days. A CA that can currently lean on a validation you passed months ago will have to re-run it almost every time. Done by hand that is a calendar reminder every six weeks; done with ACME it is a cron job that either works or pages you, which is the only version of this that survives someone being on leave.
The concepts
What the words actually mean
What a certificate proves
An SSL/TLS certificate binds a public key to an identity (a domain name, mostly) and is signed by a Certificate Authority. When a browser connects, the server proves it holds the matching private key — that proof, plus the CA's signature, is what the padlock represents. The certificate itself contains no secret; the private key never leaves the server.
The chain of trust
Browsers ship a small set of trusted root certificates. A root rarely signs your certificate directly — instead it signs an intermediate, and the intermediate signs your leaf certificate. Your server needs to present the full chain (leaf + intermediates); the root itself is never sent, since the client already has it. A missing intermediate is the single most common cause of "works on my machine, breaks for some visitors."
Where the CSR fits
You generate a key pair first, then a Certificate Signing Request: a small signed document containing your public key and the identity you're claiming (common name, SANs). You send the CSR — never the private key — to a CA, and it comes back countersigned as a certificate. The Key Matcher tool exists because it's easy to send the CA a CSR built from the wrong key, or to lose track of which private key belongs to which certificate.
PEM, DER, and the archive formats
PEM is just base64 of the underlying DER (binary ASN.1) with a header/footer line — the format you can paste into a text box. DER is the same bytes, unencoded, used where a binary blob is expected. PKCS#7 (.p7b) bundles a certificate chain without any keys. PKCS#12 (.pfx/.p12) bundles a certificate and its private key together, encrypted with a password. That one needs real decryption rather than a re-framing of bytes, which is why it took its own machinery to support — the converter opens one and the PFX builder writes one, both in the browser tab, so the key inside never travels.