5
$\begingroup$

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?

Improve this question
$\endgroup$
6
  • 3
    $\begingroup$ The intermediate certificates are delivered, the ones signing those intermediates are indeed baked-in. $\endgroup$ – SEJPM♦ Dec 29 '20 at 15:54
  • 2
    $\begingroup$ I've never heard of the term "Pre-Certificate" either. It's the TBS (to be signed) part of the certificate that gets signed. Don't know how they got that particular name :) $\endgroup$ – Maarten Bodewes♦ Dec 29 '20 at 16:13
  • $\begingroup$ @SEJPM Why would the intermediate certificate be delivered? I thought the server only has its certificate which it presents. How does it also possess the intermediate certificate? $\endgroup$ – Finlay Weber Dec 29 '20 at 16:22
  • 2
    $\begingroup$ You should read moserware.com/2009/06/first-few-milliseconds-of-https.html and security.stackexchange.com/questions/20803/… $\endgroup$ – kelalaka Dec 29 '20 at 17:28
  • 2
    $\begingroup$ @MaartenBodewes: actually 'pre[-]certificate' or just 'pre[-]cert' is now used in certificate transparency (logging) and although similar to the real cert it differs critically by including a 'poison' extension but not including the SCT(s) that will go in the real cert after the precert is logged. $\endgroup$ – dave_thompson_085 Dec 30 '20 at 1:06
11
$\begingroup$

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.

Improve this answer
$\endgroup$
9
  • $\begingroup$ > To answer your question, the server sends a chain of certificates - I was not aware of this. I always thought the server only presents the end user certificates it was issued. How does it get's the chain of certificates? It is also given as part of the process that gave it the end user certificate? $\endgroup$ – Finlay Weber Dec 29 '20 at 16:25
  • $\begingroup$ The server presents a CA with a Certificate Signing Request (CSR). The CA signs it, resulting in a certificate (the end-user certificate). The server then stores this certificate, the CA certificate, etc back up to a commonly trusted root. $\endgroup$ – SAI Peregrinus Dec 29 '20 at 16:27
  • $\begingroup$ I mean in the verification process. How does the server also know all intermediate (chain) certificates to send to the verifying client? It must have it somehow? $\endgroup$ – Finlay Weber Dec 29 '20 at 16:41
  • 2
    $\begingroup$ Part of the confusion is likely that the differences in practice between a single certificate and a chain of certificates isn't always very clear. A certificate chain is often stored in a single file, with the same extension as a certificate (.pem or .der), gets used by the same programs, etc. People sometimes call something "a certificate" when it's really a file containing a chain of certificates. The distinction is often irrelevant, so it gets omitted from some explanations. $\endgroup$ – SAI Peregrinus Dec 29 '20 at 16:56
  • 2
    $\begingroup$ "Each certificate in the chain contains a public key, a domain..." - nitpick, but the leaf certificate is typically the only one that will contain a domain. Name constraints extensions are a thing for CA certificates, but they're not so common for publicly-trusted TLS server certificates (neither of the CA certificates in your example contain this extension, for instance). Also, including the root CA certificate in the chain is optional (e.g. see RFC 8446 4.4.2), so in these cases the peer will verify the chain against the root, but it won't "match" that root if one was not provided. $\endgroup$ – Crowman Dec 30 '20 at 2:51
0
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • 3
    $\begingroup$ Re: "RSA signature is just RSA encryption with public and private keys swapped": This is an oversimplification; RSA signing and RSA encryption have one step in common, but other steps that are different. See cs.cornell.edu/courses/cs5430/2015sp/notes/rsa_sign_vs_dec.php for details. $\endgroup$ – ruakh Dec 30 '20 at 7:57
  • $\begingroup$ Oh yes, I oversimplified and skipped the padding part because when we study it in class it we often mean for the message to include the padding. Thanks for bringing it up. $\endgroup$ – Manish Adhikari Dec 30 '20 at 9:09
  • $\begingroup$ The padding is critical. RSA signature isn't just decryption (or encryption with the keys swapped), any more than modular multiplication is just multiplication. They're related, there's a shared operation, but the results are very different. The RSA operation builds 6 different primitives: encryption (with OAEP), decryption (with OAEP), signing (with PSS), verifying (with PSS), encapsulation (with a random input of limited length and a KDF), and decapsulation (with a KDF). They're all using RSA, but they're all fundamentally different operations. $\endgroup$ – SAI Peregrinus Dec 30 '20 at 15:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.