Digital Certificate — CA, PKI models, Chain of Trust, Root Store
This four-part series will discuss various topics related to digital certificates / public key certificates. I have outlined the subtopics that I intend to cover in the snapshot below.
In this post, we will cover Digital Certificates, Certificate Authority, PKI models, Chain of Trust, and, Root Store.
Here are the links to other posts in this series.
Digital Certificate series — Part 2
In the previous post, I talked about Digital Certificates, Certifying Authority, PKI models, Chain of Trust, and Root…
Explained — Digital Certificate — Part 3
So far, I have covered the certificate basics in Part 1 & Part 2 of the four-part series about digital certificates.
Explained — Digital Certificate — Part 4
I will conclude four-part series about digital certificates with this post. Here are the links to previous posts, Part…
Let’s start with the basics — why do we need digital certificates?
Digital certificates secure the communication between the sender and receiver and ensure both parties can trust the information shared between them. Certificates can verify the identity of the certificate holder. The primary usage of the certificates is for
- Authenticated and encrypted web browsing (via HTTPS)
- Signed and encrypted email (via S/MIME protocol)
- Code Signing
- Digital Signature
- Server Authentication
- Client Authentication, etc.
So if a site presents a certificate to a browser, does it mean the connection is secure, and the site is legitimate?
Not always. The site can offer a self-signed certificate or a certificate signed by a private CA that the browser can’t verify the certificate chain. The browser can trust the site if the “chain of trust” maps to something it can trust. Browser trusts Public Key Infrastructure (PKI), built around certificates, the chain of trust, trust anchors, trusted methods, procedures, etc.
That single paragraph had a lot of trust in it 😊
Let’s look at the components of PKI — starting with Certifying Authority (CA) first.
Root CA is a certificate authority. Root CA certificates are part of the trust store of the major Operating Systems (OS) and browsers. Root CA certifies the intermediate CAs and Sub (subordinate) CAs. Root CAs are secured heavily and may be offline or not connected to any network to ensure security¹.
Intermediate CA can be any CA other than the Root CA. Issuing CA generally refers to the CA which issues certificates to the end entities (leaf certificates).
There are two commonly used PKI models² — hierarchical PKI and bridged PKI.
Hierarchical PKI consists of a Root CA, Intermediate CA, Subordinate CA, and end entities (leaf certificates). For Hierarchical PKIs, two-level and three-level CAs are more common. It is uncommon to see a four-level and above CA hierarchy or a one-level CA hierarchy.
In a Bridged² PKI, the bridge CA serves as the trust anchor. The browser that has to verify certificates from any two PKIs has to trust the Bridge certificate. The local trust store must add the bridge CA certificate to the local trust store of the OS & browser.
In the figure below, the Bridge CA and Root CA 1 & 2 issues cross-certificate to each other.
Federal Bridge CA is a real-life example of Bridge PKI.
So how does PKI help the browser verify the validity of the certificate?
The short answer is that when a browser presents an end-entity certificate, it attempts to construct a chain of trust. If the browser can successfully validate the chain of trust, the browser considers the certificate as valid and the connection secure⁴.
Let’s look at some finer details — generally, every device has a root store. A root store is a collection of pre-downloaded root certificates, along with their public keys, that reside on the device. The OS vendor can maintain this root store⁵ ⁶. The figure below shows Microsoft Trusted Root Program used by Windows.
The browser can use the OS root store or maintain its root store. Some applications may use OS’s root store with more stringent checks on top. The figure below shows the certificate root store for Mozilla Firefox and Chrome.
Browsers use the root stores to do both path construction and path validation for creating the chain of trust. Let’s briefly look into it.
- Path construction⁷ ⁸
The first step is for the browser to construct the certificate chain. The chain should start from the entity certificate and end at a “trust anchor,” i.e., a root certificate. The browser can work on multiple paths as the “chain” may seek to be ok, but a few of them may fail during the validation stage.
- Path Validation
Browser iterates through all the paths, starting with the root certificate down to the server certificate. If the validation of basic info (usage/policy/path length, etc.) and critical extensions result in success, the path is considered valid.
PRO TIP — who signs Root CA certificate — Root CA itself, i.e., issuer and subject are both Root CA itself.
I hope you find this article useful and stay tuned for my next blog post.
Happy Learning 😎