Loading...
System Design and AI Engineering, by Roni Das. 980 interactive lessons.
Start LearningIntermediate · Security Architecture
An organisation your browser and operating system already trust to vouch for websites. It signs certificates that tie a site's public key to its domain name, and devices check that signature before trusting the site.
In short
A certificate authority (CA) is an organisation your browser and operating system already trust to vouch for websites. When a site proves to the CA that it controls its domain, the CA signs a certificate saying "this public key belongs to example.com". Your device checks that signature against a short list of trusted root certificates it ships with. Everything depends on the CA keeping its private signing key secret: in October 2026, eight eMudhra CA keys turned out to be tiny numbers that anyone could work out, and every major browser blocked them within days.
In short
A certificate authority (CA) is an organisation your browser and operating system already trust to vouch for websites. When a site proves to the CA that it controls its domain, the CA signs a certificate saying "this public key belongs to example.com". Your device checks that signature against a short list of trusted root certificates it ships with. Everything depends on the CA keeping its private signing key secret: in October 2026, eight eMudhra CA keys turned out to be tiny numbers that anyone could work out, and every major browser blocked them within days.
Learn it in the course
This page is the free part.
₹499 in India$49 everywhere elseonce, for the whole course
The System Design course covers Certificate Authority across a run of lessons, not one page. These 4 alone are about 64 minutes of step-by-step reading, every one with a quiz.
How SSL/TLS certificates prove who a website is. Compares DV, OV and EV certificates, and walks through the certificate trust chain.
The system of CAs, certificates, and trust hierarchies that enables secure communication across the internet.
Attaching permission lists directly to resources, who can do what to this specific object.
Storing, accessing, and rotating sensitive credentials. API keys, database passwords, tokens, and certificates.
all part of
System Design Masterclass
770 lessons · about 283 hours · 18 free to read
₹499in India, by UPI
$49everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with SSL/TLS Certificatespay once,
yours for life
Think of a passport. A border officer has never met you, but they trust the passport because they trust the government that issued it, and they know how to spot that government's stamp. A certificate authority is the passport office of the web.
When your browser opens https://example.com, the server sends a certificate. A certificate is a small signed document that says, in effect: "the public key inside belongs to example.com, valid until this date, signed by this CA". A public key is the half of a key pair that can be shared openly. Its matching private key stays secret on the server. Only the server that holds the private key can complete the TLS handshake, the opening exchange of an encrypted connection.
The certificate is only worth something because a CA signed it, and the CA only signs after the site proves it controls the domain. That proof is called validation. DV (domain validation) only checks control of the domain, for example by asking the site to publish a special file or DNS record. OV and EV also check that the organisation is real. The SSL/TLS certificates lesson compares the three.
Browsers do not trust thousands of CAs one by one. They trust a small set of root certificates, kept in a root store that ships with your operating system or browser. Root keys are so valuable that they are kept offline and used rarely. Day-to-day signing is done by intermediate CAs, whose certificates are signed by a root.
This is why an intermediate CA is as powerful as a root in practice. Anyone holding an intermediate's private key can sign a certificate for any name, and every device that trusts the root will accept it. The PKI lesson goes deeper into how roots, intermediates and cross-signing fit together.
Most CAs today use elliptic-curve keys. On the P-384 curve, the private key is simply a number, usually called d, and the public key is that number multiplied by a fixed starting point, G, on the curve. Multiplying forwards is fast. Working backwards from the public key to d is practically impossible, but only if d is a huge random number: there are about 2 to the power 384 choices, far too many to try.
On 17 October 2026 a researcher reported that the private keys of eight eMudhra intermediate CAs had been generated wrongly. Six were for TLS (website) certificates and two for code signing. The keys were tiny. The disclosure page says anyone could recover them from the public certificates, and that this was possible since the certificates were created in April 2025.
We checked this ourselves. We downloaded the published certificate chains and tried every value of d from 1 to 255 for each of the six TLS intermediates. All six matched. The keys were 156, 230, 115, 56, 155 and 4. The slowest one took 0.22 seconds on a laptop.
According to the disclosure page, the certificates have been blocked in Firefox and Chrome since 17 October, on Apple devices since 19 October and on Microsoft platforms since 20 October, and the CA revoked them. The intermediates never appeared in Certificate Transparency logs, the public, append-only logs that browsers require certificates to be listed in, so browsers that enforce those logs could not have been fooled.
The harder part is everything else. Many programs that make HTTPS calls, such as scripts using curl, Python, Node.js or Go, trust a bundle of root certificates on disk and do not check revocation or transparency logs by default. Two roots had signed these intermediates: eMudhra's own and the older Comodo "AAA Certificate Services" root (now run by Sectigo), which cross-signed them. Ubuntu, for example, shipped a ca-certificates update that removes both roots. Until a system gets an update like that, it can still trust the bad intermediates. The certificate revocation page explains why revoking does not reach these clients.
The practical fix is plain: update the operating system's CA package, update language-level bundles such as Python's certifi, and rebuild container images so they pick up the new bundle.
CAs come up whenever a design says "HTTPS everywhere" or "mutual TLS between services". Interviewers want to hear the chain of trust in a sentence, why intermediates exist, and how certificates are issued and renewed automatically at scale, usually with the ACME protocol (the one Let's Encrypt uses) or an internal CA for service-to-service traffic. See mTLS.
Strong candidates also know the failure modes: an expired certificate that takes a whole site down, an internal CA whose key leaks, and clients that never learn a certificate was revoked. The certificate management lesson in the System Design course covers issuance, renewal, revocation and the automation that prevents outages.
Let's Encrypt
A free, automated CA that issues domain-validated certificates through the ACME protocol, which made HTTPS the default on the web.
eMudhra
A CA whose eight intermediate keys were found in October 2026 to be tiny numbers anyone could compute. Browsers blocked them within days.
Sectigo
Runs the old Comodo AAA Certificate Services root, which had cross-signed the affected eMudhra intermediates.
Ubuntu
Shipped a ca-certificates update removing the two roots that chained to the bad intermediates, a typical fix for non-browser clients.
It is an organisation your devices already trust to vouch for websites. It checks that a site controls its domain, then signs a certificate tying the site's public key to its name. Your browser checks that signature before showing the padlock.
The site proves domain control to the CA, and the CA signs the site's certificate with an intermediate key. When you connect, your device checks the site certificate against the intermediate, and the intermediate against a root certificate already in its root store. If every signature, name and date checks out, the connection is trusted.
A root CA's certificate ships inside your operating system or browser and its key is kept offline. An intermediate CA is signed by a root and does the daily signing of website certificates. If an intermediate's key leaks, it can be revoked without replacing the root on every device.
Anyone with the key can sign certificates for any website, and devices that trust the CA will accept them. Browsers block the CA quickly with pushed lists, but other software keeps trusting it until its root bundle is updated. That is what happened with eMudhra in October 2026.
SSL/TLS
Cryptographic protocols that encrypt data in transit between client and server. TLS is the modern successor to SSL. The 'S' in HTTPS.
HTTPS
HTTP over TLS: the encrypted version of HTTP that protects data in transit. Every production site should use it; browsers flag plain HTTP as insecure.
mTLS
Mutual TLS: both client and server present certificates to authenticate each other. Standard in service mesh architectures where every service verifies its peers.
Certificate Revocation (CRL and OCSP)
Cancelling a TLS certificate before it expires. CAs publish revocations in lists (CRLs) and browsers get pushed block lists, but most non-browser clients do not check by default.
Zero Trust
A security model that never trusts any request by default, even from inside the network. Every request must be authenticated, authorized, and encrypted regardless of origin.
Throttling
Slowing down the rate of processing requests instead of rejecting them outright. The gentler cousin of rate limiting.
This page explains the idea. The "SSL/TLS Certificates" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the SSL/TLS Certificates lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Certificate Authority (CA) in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
