One of the main problems in online communication is trust. Let’s say you communicate with your bank through their website: how can you be the bank’s page is real and it’s not a third party imitating the bank’s page and attempting to steal your data?
Your device and the bank’s page need to establish trust. Trust is based on the fact that we can have a method to correctly identify an entity. When communicating over the internet, entities can use digital certificates as their identities.
A digital certificate, defined in the Internet-standard X.509, is a secure method to guarantee the identity of the entities that communicate online. It works with advanced and secure cryptography providing an efficient way to work with the identity of users. Their complex cryptography ensures that users are protected from outside threats when online.
It is common, however, for many organizations to feel overwhelmed by the task involved in implementing the certificates and end up, in the long run, avoiding this task. To simplify certificates, this article will cover the basics of root vs. intermediate certificate, certificate authorities (CA’s), and why SSL/TLS certificates are widely used for internet browsing.
Client vs Server Certificates
Before we get into Root and Intermediate CAs and certificates, let’s cover the difference between a client certificate and a server, or SSL, certificate. It’s pretty straightforward, as the client certificate verifies the identity of the end user device and the server certificate verifies the identity of the server.
If we take into account how the architecture of a web application works, it usually has a server where the application is stored and the functions to be executed behind it, as well as probably a database, among other elements. The web page, the visual elements, and everything with which the end-user interacts is part of the web client. This server-client relationship is also present in the way certificates are defined.
With this setup, we have a certificate at the server level and the certificate for the client. In this way, each certificate verifies the respective identity of both the server and the client. The client certificate verifies the identity of the end-user and the server certificate authenticates the owner of the site we are communicating to.
For example, if we search Wikipedia, the domain name “www.wikipedia.com” has an SSL/TLS certificate that your web browser can use to verify that you are connecting to the Wikipedia page and not elsewhere. By knowing who the certificates are assigned to, we can unravel the types of certificates that exist and how they are generated.
What are Certificate Trust Chains?
In a public key infrastructure or PKI, certificates are issued in a very specific order, in what is known as a Trust Chain.
Every certification chain begins with the root certificate issued by the CA, then goes through intermediate certificates, which can be one or more. The chain ends with the last certificate, also known as the Trust anchor. The diagram below shows us a certificate chain and how each aspect is featured.
What is a Root Certificate?
The Trust chain begins with the certificate issued by the certification authority or CA, this first certificate is called the root certificate.
Also known as a trusted root, it’s issued by a trusted CA and can be used to issue intermediate certificates. Root certificates can be taken from root stores, and most devices contain root stores specific to their operating system.
Since the root certificate must be well guarded, its transmission is not adequate, which is why in order to guarantee the adequate use of the root certificate, it comes by default in most of the devices that will connect to the network, as is installed beforehand in all internet browsers.
What is a Root Store?
The place where the root certificate is stored is called the Root Store. In order to begin the certification process properly, the protocol that verifies certificates begins with the root certificate.
Each major browser has their own root stores that contain all the public keys they trust. When a client connects to a server, the server will send over their public key and the client can verify if that public key is trusted. Root certificates are imperative for security because a certificate signed by a CA is automatically trusted by web browsers.
The reliability of the communications depends on access to the root certificate. If this verification process is not performed, then the secure communication can’t be established. This is why browsers have the public keys of the websites they trust thanks to the storage of the root certificate.
When the communication protocol starts, the root certificate verification function is executed. The protocol also includes verification of the CA’s signature. In this sense, we can say that the root certificate is essential for the functioning of web communications in general.
What is an Intermediate Certificate?
CAs don’t issue end user/client certificates from their root certificate because it’s too much of a security risk. CAs use their roots to sign and issue intermediate certificates, which are subsequently used to sign end user certificates, essentially adding a “middleman” between the trusted root and end user.
The protocol that verifies certificates is supposed to protect the root certificate. So, the more intermediate certificates you issue, the more secure the protocol. The main goal is to prevent root certificates from being revoked.
Root vs Intermediate CAs
In a PKI, all certificates must be issued by a valid CA. The process for issuing a certificate begins when the client generates the cryptographic keys using their credentials. In this way, the CA takes this information and generates a certificate, where the cryptographic public key and the user’s profile are input.
An interesting question is how trust is established between different CAs? Trust is given precisely because root CAs exist and the identity of all entities is known by a specific agreement in the internet community. This being the case, this is the first step of trust. Then the CA’s can be divided into two categories: root CAs and intermediate CAs.
Root CAs are CAs that serves as the “root” in a chain of trust and all certificates can be traced back to it. They issue intermediate certificates so they are protected. The root CA does not issue end-user or server certificates. Instead, Intermediate CAs have their certificates issued by the root CA and are used to sign end-user and server certificates. Multiple intermediate CAs can be configured between the root CA and the end-user certificate, creating the certificate trust chain.
How Do Web Browsers Authenticate SSL/TLS Certificates?
All web browsers have their own list of trusted roots that have passed their criteria for inclusion. When a web browser connects to a web page, the web page sends over its SSL/TLS certificate, which the browser then examines.
Here’s a basic overview of what the browser checks:
- The web browser verifies the integrity of the certificate with the digital signature, proving the server is legitimate.
- The web browser then verifies the certificate’s validity period, ensuring the certificate is still active.
- The web browsers checks if the certificate has been revoked before it expired. CAs maintain a list of revoked certificates, aptly named the Certificate Revocation List (CRL).
Once verified, the web browser and server initiated the TLS handshake, encrypting the connection and ensuring no outside threats can get in. The user can safely access the web page.
How Do CAs Sign Certificates?
Before a CA can sign a certificate, the client needs to generate a public/private key pair and a Certificate Signing Request (CSR). Here’s an in-depth guide for generating key pairs and here’s one for CSRs. The CSR contains the public key and user information, which will then be sent to a CA.
The CA will verify the user information and sign the certificate with its private key, establishing trust. The client can now import their signed certificate into the server.
CAs and Certificates Provide Strong Network Security
Digital certificates and CAs are imperative for secure online communication because they can verify the identities of users and servers alike. Trusted root CAs issue and sign intermediate roots for intermediate CAs, which in turn issue end user and server certificates, establishing a chain of trust and protecting root CAs from being compromised through insulation.
All of these factors require a PKI, and SecureW2 provides a turnkey managed cloud PKI at an affordable price that can be set up in less than an hour. Check out our pricing page for more information.