One of the crucial steps in the TLS handshake is for the server to prove its identity to the client. While there is plenty of content explaining the principles of the handshake, there's less information about certificates, which are a critical component of TLS/SSL. This series of articles aim to explain what certificates are used for, how Google prevents others from impersonating Google, and why certificate issues frequently arise, among other topics.

(Postscript: It took me a full 10 hours to write these articles. It's quite straightforward, with no mathematical content, just a few OpenSSL commands. It's a long read, so feel free to grab a beer and take your time.)

What Problem Do Certificates Solve?

Imagine there is a bank called super-bank.com that holds billions of dollars in customer funds, allowing users to transfer money via its website.

Now, a hacker walks into a Starbucks, connects to the WiFi, and uses a fake DHCP service to tell other users on the Starbucks WiFi: "I am the gateway, let me forward your internet traffic if you want to go online!" This allows him to see all usernames and passwords of the users.

Some readers might say, "You can use TLS encryption!"

However, the hacker somehow obtains a certificate issued to super-bank.com, then sets up a fake server and tells users, "Trust me, I am the bank!"

Thus, he steals users' passwords again...

So, where does the problem lie? It lies in the certificate. The role of the certificate is: only the holder of the certificate is the real super-bank.com.

In other words, it proves "I am who I claim to be."

A common misconception is that only certificate authorities can issue certificates. In fact, anyone can issue certificates. I can create a Root certificate myself and issue certificates to any domain. There can be many certificates, but clients must only trust those that are valid.

So, which certificates are trustworthy? The ones issued by authoritative certificate authorities (CAs).

The complexity of this topic arises because these three participants—client, CA, and website—are interconnected yet each has its own responsibilities. During discussions, it’s easy to confuse their roles, leading to misunderstandings. Therefore, this series of articles will discuss the issues and actions of these participants separately, hoping to clarify the matter.

Their relationship is:

The client trusts the CA.
The CA issues certificates to websites.
When a client visits a website, the website presents its certificate. Since the client trusts the CA, it also trusts the certificate issued by the CA.

It's similar to dining at a restaurant: how do you know it's not a scam? You check if the restaurant has a business license issued by the regulatory authority. If the restaurant has a license issued by the authority, you trust the restaurant.

Now, the problem seems simple, but if we think about ways to break this chain of trust, we realize that solving this "trust" issue is not straightforward.

For example, can I apply to a CA for a certificate issued to super-bank.com? Why wouldn’t the CA issue this certificate to me?

Certificate Authorities

Certificate Authorities (CAs) have three main responsibilities:

To Websites: When someone applies for a certificate, I must verify the applicant's identity. If they are not super-bank.com, I cannot issue the certificate to them.
To Themselves: Protect the private key of their root certificate.
To Clients: Be trusted by clients.

Verifying Website Identity

We cannot issue certificates to the wrong person, as this would allow the certificate holder to impersonate others. Therefore, for all applicants, we must ensure they indeed have control over the domain before issuing a certificate. This means verifying the applicant's identity.

The industry standard for this is called the ACME Challenge. The basic principle is: to prove to me (the CA) that you are super-bank.com, you need to make the URL super-bank.com/.well-known/acme-challenge/foo return the text bar. This demonstrates your control over the domain, and I will issue the certificate to you. (There are other methods supported as well, such as DNS TXT records.)

Safeguarding the Private Key

CAs must protect their private key because if it is leaked, they can no longer fulfill their role. The holder of the leaked key can issue certificates at will. If a private key is compromised, it would be catastrophic for the CA. All certificates issued by the CA would need to be revoked, websites would need to redeploy new certificates, and if clients do not promptly revoke the compromised CA, they could be at risk of accessing fraudulent servers, leading to potential account theft and fraud.

Given the numerous websites that need certificates (including reissuance upon expiration), it would be highly inefficient for the CA to access the private key from a secure vault for each certificate issuance.

Use of Intermediate Certificates

To address this, the CA Root certificate usually does not directly issue certificates to websites. Instead, it issues an intermediate certificate, which is then used to issue certificates to websites.

This is where x509 comes in: if a client trusts the CA, then the client should trust certificates issued by the CA, and should trust certificates issued by those certificates, and so on. However, does this mean that a certificate issued to me by the CA can be used by me to issue other certificates? That would mean anyone could use the CA's credibility to issue certificates.

Certificate Signing

Of course not. CA-issued certificates include an X509v3 Basic Constraints: critical field, with the value CA:FALSE. By downloading the certificate for this blog and using the OpenSSL tool to parse it, you can see that in this certificate chain, both the Root and Intermediate certificates have CA:TRUE, while my certificate has CA:FALSE.

The CA:FALSE value on certificates issued to entities means that even if they issue a certificate, it won't be trusted. Can we modify this field to issue certificates?

The answer is yes, but if I modify my own certificate, the modified certificate will no longer be trusted.

Trust Chain

Client –trust–> Root CA –trust–> Intermediate CA –NOT trust –> kawabangga.com — NOT trust –> super-bank.com signed by kawabangga.com

Why is the modified certificate not trusted?

Certificate Issuance Process

The certificate issuance process is straightforward, utilizing the characteristics of private and public keys:

Data signed with a private key can be verified with the public key.
Data encrypted with the public key can be decrypted with the private key.

Simplified, it means data encrypted with one key can only be decrypted with the other key. One key is released as the public key, and the other is kept private.

The process of signing essentially involves encryption:

Hash the entire certificate, then encrypt the hash value with the private key.
The verifier hashes the entire certificate, obtains the hash value, then uses the public key to decrypt the encrypted hash value. If the values match, it confirms the private key holder performed the encryption.

Client Verification Process

The client verifies the certificate by comparing the hash value decrypted with the public key to the hash value it calculates.

This ensures:

The signer cannot deny their actions, as only the private key holder can sign.
The signed content cannot be altered; any modification will cause the verification to fail.

Thus, after the CA signs the certificate, no part of the certificate can be modified, including CA:FALSE and the validity period. If expired, the certificate must be re-signed. Simply changing the date to extend its use is not possible.

Many people mistakenly believe that certificate issuance involves the CA signing with its certificate. In reality, the CA only uses its private key to append an encrypted hash value to the original certificate.

Certificate Authorities Must Be Trusted by Clients

The foundation of everything is that clients must trust the CA. The trust in all other certificates stems from the trust in the CA Root certificate.

Building trust is a long process.

So how does a client trust a CA? The answer is that clients store the CA locally. The specific location depends on the client: for example, on Linux, it’s in /etc/ssl/certs, on Mac, it can be viewed using Keychain. Chrome’s trusted certificates are here, Mozilla’s are here.

Given the vast number of clients in the world, adding a new CA seems difficult!

Actually, it’s not. a group of ambitious people created an organization called Let’s Encrypt in 2013: "We want to issue free certificates to all websites needing TLS/SSL! In a friendly manner! Because we want a safer and more private internet."

Where does trust come from for a new CA? In fact, this CA doesn’t need to spend many years slowly gaining the trust of all clients. As mentioned earlier, it only needs a single Root CA’s trust. If a client trusts an old CA, and the old CA signs the new CA, the client will trust the new CA. In this case, the old CA is DST Root CA X3. Following this logic, clients trust DST Root CA X3, and thus trust certificates signed by DST Root CA X3 for Let’s Encrypt, and also trust intermediate certificates signed by Let’s Encrypt, but not further down. Remember CA:FALSE?

With so many certificates, how does a client verify them? It sounds troublesome, and it’s unclear who to trust.

Let's explore the role of clients next:

Reference: https://www.kawabangga.com/posts/5330