Chain of Trust

The TLS (Transport Layer Security) digital certificate follows the X509 standard.? The certificate contains the public key used in the asymmetric encryption. In simplified form, asymmetric encryption involves separate keys for encryption and decryption, which operates in pairs. When data is encrypted with one key, it can only be decrypted with the other key; the same key used for encryption cannot decrypt the data.

The public key, as the name suggests, is meant for sharing. It is used to decrypt data encrypted by the private key or to encrypt data that can be decrypted using the private key. On the other hand, the private key, as its name implies, is always kept confidential. It's utilized to decrypt data encrypted with the public key or to encrypt data intended for decryption with the public key.

It's essential to understand that the public key alone does not equal to a certificate. The X509 standard outlines additional requirements for certificates, including further information about the certificate and hashes, beyond solely the public key.

The TLS certificate plays a crucial role in securing online experience, it is enabling the 'S' in HTTPS. When a user visits a website using HTTPS, user’s browser receives the server's public certificate as part of the response. It is a key step in the TLS handshake process, paving the way for subsequent communications to be encrypted.

The public and private keys aren't directly involved in encrypting the traffic itself. Instead, they're utilized to set up up a symmetric key. This symmetric key is then used to encrypt the actual traffic, ensuring its security during transmission.

Creating TLS certificates using free tools like OpenSSL is quite simple. These certificates, known as self-signed certificates, are completely free of charge and can be used to secure HTTP traffic.

The Issue with Self-Signed Certificates

Such certificates are commonly referred to as ‘self-signed certificate’.? The issue arises from the fact that anyone can generate a self-signed certificate for a domain. This poses a challenge because the system or user receiving the certificate from the server lacks a means to verify its authenticity.

Traffic secured using self-signed certificates is at risk of Man-in-the-Middle (MITM) attacks. In such instances, a malicious actor could produce a new certificate for the same domain, such as acme.com, and present it to the user. Since the user lacks the means to discern whether the certificate originates from the genuine acme.com or from an unauthorized source, the malicious actor gains the ability to intercept and decrypt the traffic between users and acme.com. This enables the attacker to potentially view the traffic or even manipulate the data being exchanged between the user and acme.com.

Certificate Authority

A non-self-signed certificate is not generated by the user himself, but rather by a third-party entity called ‘Certificate Authority’, or CA for short.

To obtain such a certificate from a CA, the user initiates the process by generating private and public keys. Subsequently, the user forwards the public key, along with identification details in the form of a Certificate Signing Request (CSR), to the CA. The CA then 'signs' the certificate. More about the signing later.

Certificate Authorities come in two main types: public and private CAs. The distinction lies in their scope. Certificates signed by Public CAs are universally recognized and accepted by nearly all systems worldwide. Numerous Public CAs exist globally, including names like GlobalSign, Digicert, and ISRG (Internet Security Research Group – the organization behind Let’s Encrypt).

Conversely, individual companies or entities have the option to establish their own CA, known as a Private CA. Certificates issued by Private CAs are typically utilized within the confines of an intranet, serving the internal needs of the organization.

Signing

To generate the certificate, the Certificate Authority (CA) follows a specific process. It begins by computing the hash of the public key and other information provided in the Certificate Signing Request (CSR). This hash is then encrypted using a private key, a procedure referred to as 'signing'. The resulting encrypted hash, combined with the public key and additional details, constitutes the certificate.

There are few types of certificates that the CA would need to sign.

First is the root certificate. The CA generates the CSR and the private key. The private key is then used to sign the CSR.? The certificate generated by this process is called root certificate.?In effect, the root certificate is a self-signed certificate.

Typically, the private key associated with the root certificate is not directly utilized to sign the CSR submitted by the customer. Instead, it serves the purpose of signing another certificate known as the intermediate certificate.

The private key linked with the intermediate certificate is utilized to sign certificates intended for the customer. These certificates for customers are commonly referred to as server certificate or leaf certificate.

Upon receiving both the intermediate and server certificates from the CA, the customer proceeds to install them on the web server alongside the private key.

The different level of signing in effect establishes a chain of trust. This chain of trust is pivotal as it enables browsers to verify that the server certificate was indeed signed by the CA.

When a browser accesses a system, it receives two certificates: the server certificate and the intermediate certificate. The browser proceeds to calculate the hash.

Although the certificate itself contains the hash, it is encrypted using the private key of the intermediate certificate. With the public key from the intermediate certificate, the browser decrypts the hash of the server certificate and compares it with its own calculated hash. If the values match, it confirms that the server certificate's hash was indeed signed by the private key of the intermediate certificate. This verification establishes a link or 'chain' between the server certificate and the intermediate certificate.

Similarly, using the public key of the Root CA, the browser decrypts the hash of the intermediate certificate and compares it with its own calculated hash. If they match, it signifies that the hash of the intermediate certificate was encrypted using the private key of the root certificate. This confirms that the intermediate certificate inherits trust from the root CA.

As the server certificate is linked to the intermediate certificate, and the intermediate certificate is linked to the root certificate, the validity of the server certificate is established. Since only the CA can sign its own root certificate, it confirms that the server certificate was indeed issued by the CA, thus validating the certificate's authenticity.

However, the process doesn't directly involve the transmission of the root certificate from the server to the browser. The server only provides the browser with the intermediate and server certificates. So, how does the browser obtain the root certificate?

Directly querying the root certificate over the Internet isn't a viable option due to security concerns. Without encryption, the traffic could be susceptible to MITM attacks, where malicious actors might spoof the CA's root certificate, leading the user to trust fraudulent intermediate and server certificates. Even with encryption, the browser faces a dilemma in verifying encrypted traffic without knowledge of the root certificate—a proverbial catch-22.

To circumvent this, root certificates are typically pre-installed on the browser or the operating system it runs on. By already having the root certificates available, browsers can authenticate server certificates without requiring direct transmission of the root certificate during the connection process. This ensures secure HTTPS connections, mitigating the risks associated with retrieving root certificates over the network.

Certificate Store

How does the root certificate find its way onto your browser? This is where operating systems (OS), browsers, or platform vendors step in. The Certificate Authority (CA) must have its root certificates included in the OS, browser, or platforms to avoid its signed certificates being treated as self-signed.

Every OS, including Windows, MacOS, and Android, is equipped with its own certificate store to house root certificates. Windows, for instance, stores certificates in the registry, accessible via certlm.msc. On Ubuntu, certificates are stored in the /etc/ssl/certs directory.

Applications running on these OSes can access the root certificates provided by the OS to authenticate the chain of trust. However, some systems or platforms utilize their own certificate stores. For instance, Java maintains a separate certificate store, while Mozilla browser and Google Chrome have their own root certificate stores.

For Private CAs, major vendors like Microsoft, Google, Oracle, Red Hat, or Canonical may not readily accommodate requests to add their root certificates to the store. Doing so would essentially elevate the Private CA to the status of a Public CA, enabling it to generate certificates for any domain on the internet, accepted by all computers worldwide. This stringent process underscores the importance of trust in CAs within the X509 architecture.

Instead, these systems or platforms offer users the option to add custom root certificates, either through a graphical user interface (GUI) or command line interface (CLI). Companies or organizations issuing their own certificates can add their root certificate to all computers within their network. This process can even be automated, such as by incorporating certificates into the OSs golden image, ensuring that laptops or servers utilizing this image are equipped with the necessary root certificates.

Conclusion

Installing the certificate on the server isn't adequate. Even with the certificate present, it remains vulnerable to spoofing. However, installing the root certificate on the user's computer enables the computer to authenticate and validate the certificate, safeguarding against potential spoofing attempts.

</budy>

Note: this article was originally shared internally within EDB. Published in LinkedIn after removing sensitive information and rewording to make the sentences clearer.