5

I am reading this article in my attempt to understand how the TLS verification and chain of trust works. In the piece I come across a section that I am not sure I understand.

In the simplified description of how the browser validates a certificate you have this:

The client, which is a browser for ease of explanation here, has two processes that it must complete to validate the signature. The first process is to take the signature on the bottom of the certificate and decrypt it with the CA's public key. This public key comes from the CA's intermediate certificate which should be delivered by the server during the connection at the start of the TLS handshake. This tells us that if the CA's public key can decrypt it, the CA's private key must have encrypted it. This means it definitely came from the CA in question because only they posses the private key. The second process is for the browser to calculate its own hash of the Pre-Certificate to compare to the hash stored in the signature and determine if they are identical

But not sure if this portion is correct:

The first process is to take the signature on the bottom of the certificate and decrypt it with the CA's public key. This public key comes from the CA's intermediate certificate which should be delivered by the server during the connection at the start of the TLS handshake.

Is the portion that says the public key is delivered by the server correct? I would have assumed that the browser uses the pre-installed public key of the CA in this step.

Is the article wrong? Or am I the one who has got things wrong?

fgrieu
  • 149,326
  • 13
  • 324
  • 622
Finlay Weber
  • 504
  • 1
  • 3
  • 12

2 Answers2

12

The article is wrong, but not there. It's the previous sentence that's incorrect. "The first process is to take the signature on the bottom of the certificate and decrypt it with the CA's public key." Emphasis mine: signatures aren't encryption, decrypting them isn't what the client does, the client verifies the signature. This is unrelated to your question, but it's important not to confuse encryption/decryption with signing/verification, since doing so can lead to major security issues. Such confusion is only really possible with RSA, many other public-key systems don't have any real notion of encryption/decryption to begin with. Confusing basic terminology like this is good reason to stop reading any article about public key cryptography. Confusing signing and encryption is like confusing addition and division: vaguely related, sort of swapped (signing is closer to decryption in RSA though still different), and generally a sign that the article wasn't written by anyone competent.

To answer your question, the server sends a chain of certificates. Each certificate in the chain contains a public key, a name (a domain for the server, an organization name for a CA), some extra information, and a signature covering all that. The signature was created by the private key of the next certificate in the chain, and can be verified by that certificate's public key. At one end there's the certificate of the web site, which doesn't sign any further certificates, and at the other end there's a "root" certificate. This "root" is the only thing that gets preinstalled by the browser. The browser can verify that the named root in the chain has a pre-installed certificate. Then the browser can verify that the next certificate's signature was made by that root, etc down the chain. If all the signatures verify, the final website certificate can be trusted to belong to that domain's owner.

In practice those certificate chains can be short. Lots of CAs are trusted as roots for these chains. For example, this site has (at this time) a certificate for *.stackexchange.com which is signed by the Let's Encrypt R3 certificate (Let's Encrypt is a CA), which is in turn signed by the Internet Security Research Group ISRG Root X1 certificate (ISRG is the organization that runs the Let's Encrypt CA). Browsers trust ISRG Root X1 directly, and verify that it signed the Let's Encrypt R3 certificate. Then they verify that the Let's Encrypt R3 signed the certificate for *.stackexchange.com. Only 3 levels in the chain.

SAI Peregrinus
  • 5,968
  • 20
  • 27
0

I don't have enough reputation to comment but I would like to clarify SAI Peregrinus's answer about what's wrong with the article. While some signature schemes do involve some sort of "decryption" (RSA signature is just RSA encryption with public and private keys swapped), others like (EC)DSA any many quantum-resistant signatures don't: they can't be used to encrypt anything either. They are like sort of equations which the verifier verifes (using a public key) whether or not some two calculated quantities match which they should iff they are produced using the valid private key.

Manish Adhikari
  • 661
  • 5
  • 13