HTTPS Certificates: The Chain of Trust

The Trust!

We do not (and perhaps we should not :) "trust" so many people! We only trust a few of them. But we can trust those who are trusted by our trusted ones! Sounds confusing right but this applies to the HTTPS certificate trust as well. Imagine a virtual landscape where identities are verified, communication is shielded, and websites are given a seal of authenticity. This is made possible through the power of certificates, the digital passports that vouch for the legitimacy of individuals and organizations.

After learning the basics of OpenSSL, key features, hashing, encryption, and decryption in the first blog, let’s see how it works:

Certificates:

A certificate is a digital document that verifies the identity of an individual or an organization. It provides assurance that the certificate holder is who they claim to be, and it can be used for secure communication over the Internet. A certificate is based on public key (asymmetric key) cryptography.

If any website is HTTPS, that means it has a valid certificate. To ensure this, the certificate must be signed (as mentioned here) by the trusted party. That’s where we need a “Certificate Authority (CA)”.

Certificate Authority:

A certificate authority is a trusted third-party organization that issues digital certificates. The CA is responsible for verifying the identity of the certificate holder and for signing the certificate with its own digital signature. Which means encrypting the certificate (containing all the related information about the website) using CA’s private key. Anyone can decrypt and verify the certificate using CA’s public key but no one can edit and re-encrypt that (of course because no one has CA’s private key).

When you access a secure website, the website will present a certificate to your browser. Your browser will check the certificate against a list of trusted CAs to ensure that the certificate was issued by a trusted authority. If the certificate is valid, the browser will establish a secure connection to the website and encrypt all information exchanged between the browser and the website.

What is contained in the “Certificate”?

You can download a certificate of any website by clicking on lock (top left on browser) -> Connection is secure -> Certificate is valid.

Below is how this certificate look like:

Below is a openssl command to download a certificate:

openssl s_client -connect <hostname>:<port> -showcerts

Example:

openssl s_client -connect www.infocusp.com:443 -showcerts

Command	Description
s_client -connect	To connect with remote host
infocusp.com:443	Host name with port
showcerts	Flag indicates to show all certificates of the chain

All of the data you need to validate the server’s identity is contained in the certificate. It contains a lot of fields, but for this article, below are the explanations of a few of them:

Issued To/Subject :

For whom (which domain/website name) is the certificate issued? Note that Certificate Authority verifies that issuer owns this domain while signing the certificate.

Issuer:

A certificate authority who has issued this certificate.

Validity:

A time when the certificate is valid. The field contains two values: start date and end date. Limited period validation is imposed to reduce the effects in case the privacy of the certificate (issuer's private key) is compromised by any means.

Certificate signature algorithm:

The algorithm used to sign the certificate. The sign means taking a hash and encrypting using the issuer's private key. So this contains a hashing algorithm and also an encryption algorithm.

Fingerprint / Signature:

The output of the signing process, the Encrypted hash value.

The chain of trust:

As explained above here, The chain of trust comes into play when a CA issues a digital certificate. To ensure that the certificate is trustworthy, the CA must be trusted by the user's browser. This trust is established by a hierarchy of CAs, where the top-level CAs are trusted by default by most web browsers, and they in turn issue certificates for lower-level CAs or directly to websites.

How does our browser verifies the "Certificate"?

Let's say the certificate of stackexchange.com is issued by R3 (Let's Encrypt) and R3's certificate is signed by ISRG Root.

• Our browser downloads this "certificate chain".
• It verifies that the leaf certificate is signed by its parent. That is: stackexchange.com's certificate is signed by R3's private key. As mentioned above this verification means decrypting the signature value using the parent's (R3's) public key.
• Browser checks if it trusts R3. That is: If the browser contains the certificate of R3 inside its trusted certificates. If so we are done!

For Chrome browser we can manage its trusted certificates from here: chrome://settings/certificates

• If not, it verifies the next hop. That is: R3's certificate is signed by ISRG and if it can trust it.
• If it reaches the end of the received certificate chain and it does not trust the last certificate, that means the browser does not trust stackexchange.com's certificate and shows the warning message.

Demo

For those who are interested here is the bash script which performs the exact same steps mentioned above for the case of stackexchange.com's Certificate verification. There are some nuances in terms of commands but the basic flow is as explained above.

Some interesting Q&A:

1 - In the certificate of "docs.google.com" why I see "*.google.com" as an organization?

Big organizations issue their certificate for a "wildcard domain".

A wildcard certificate is a type of SSL/TLS certificate that is issued to a domain and its subdomains. In this case, the wildcard certificate has been issued to the domain "*.google.com," which includes all subdomains of it like "docs.google.com."

2 - But then, In the certificate of "youtube.com" why I see "*.google.com" as an organization?

This can be done using "Certificate Subject Alternative Name" (SAN). It is an extension of digital certificates. It provides a way to include additional information in a certificate that specifies alternative names for the entity (such as a website or server) being certified.

You can view all the valid alternative entities of the ceertificate in Certificate subject alternative name field.

Below is an openssl command to print all the alternatives of Google.com's certificate

openssl s_client -connect google.com:443 < /dev/null | openssl x509 -noout -text | grep -C3 -i dns

3 - I have a valid HTTPS certificate for my website, I can also sign certificates for others?

This may seem possible at first glance because of the way "chain of trust" works. Fortunately, it is not! Thanks to the "isCA" flag in the Certificate. This Flag indicates if the certificate is a CA (certificate authority's) certificate. And browser checks that all the certificates other than of leaf should be the CA certificates (with isCA=True) This is on of the BasicConstraints of the certificate extension. More information on Basic Constraints extension here

How to check isCA flag of the certificate:

openssl x509 -noout -text -in certificate_file.pem | grep 'CA'

Output: CA:FALSE

Conclusion:

Explore the advanced security measures in TLS 1.3, its benefits, and how it functions, then let's continue this journey in our third and final installment of the OpenSSL blog series.