3 ms·

> A user wants to get the public key for a certain domain. So he knows he is talking to a server by the domain owner and not some man in the middle. > So he as

by dom0 9y ago

> A user wants to get the public key for a certain domain. So he knows he is talking to a server by the domain owner and not some man in the middle. > So he asks a third party whos public key he already has. In this case Let's Encrypt. Ok. It works quite differently -- the browser doesn't have to talk to Let's Encrypt at all to verify correctness. How it works: 1. Browser connects to the server 2. TLS handshake, crypto-stuff 3. The server cryptographically presents the browser his certificate 4. The server's certificate is the server's public key, some attributes (like what domain names the cert is valid for) and a digital signature of all that stuff 5. The browser has a list of certificate authorities 6. The browser checks whether the digital signature on the server's certificate is valid and was made by a CA the browser trusts 7. The browser checks that the certificate is valid for the site it's currently accessing 8. Connection legit The problem that the CAs (including Let's Encrypt) solve is not distribution of public keys, but rather trusting public keys presented by someone. > But how did Let's Encrypt get the public key from the domain owner? > I know they make the domain owner install some software on his server What the ACME clients do is two-fold: 1. They put up some sort of challenge response mechanism. This is used by Let's Encrypt to test whether a client is authorized to rule over a domain. 2. They generate (or use) a "Certificate Signing Request" (CSR). A CSR is basically a digital "sign here" field. The CSR contains the server's public key, what domains it wants to represent etc.. The CA checks the CSR using the challenge-response mechanism from (1) and then signs it digitally. The result is a certificate, which is sent back to the client and installed by the client. The private key of the certificate never left the server. > If so, why is the Let's Encrypt software so complicated and not just a 5 line script or something? Well it doesn't have to be complicated. acme.sh is only five (thousand) lines of shell :) There are a bunch of ways the challenge-response mechanism can work, and there are also a lot of other options, which add to the complexity, as well as installation routines for certificates, which support a bunch of different servers. A specific case with "static" challenge-response could conceivably boil down to just a dozen lines of shell or so.

tialaramex 9y ago
Nit pick: Although toy systems work by "just" signing the CSR a real CA like Let's Encrypt basically throws the CSR away after verifying its integrity. The CSR is a signed data structure that says "Hi, here's my public key K1, and I want you to issue me a certificate with properties P1, P2, P3 for names N1, N2, N3" and it's signed using a private key K2. Using K1 (which is right there in the document) we can check that the K2 signature matches. If not, we can't be sure the real owner of K2 even wanted this certificate and we must reject it. Then we can look at the list of P1... and N1... and decide if we want to issue a certificate at all. If we do, we can choose to issue any certificate we want, we don't need to issue exactly the one described in the CSR. This is important because many CSRs, whether generated by well-meaning admins or automatically by an appliance or service, are full of crap that Let's Encrypt doesn't want to, or isn't permitted by the Baseline Requirements to sign. [ e.g. it's very common for CSRs to claim that London is in a County called Middlesex. Nope, that county was abolished decades ago, London isn't in a county at all, but people see a field labelled "State or County" and they figure they should write something in the box. If a CA signs that, they're claiming Middlesex still exists. ] By constructing each certificate from first principles after examining the CSR, Let's Encrypt can ensure they sign only certificates for exactly the things they've validated, nothing else.
- dom0 9y ago
  Thank you, that's a good and important point. It also has the angle that the CA can't accidentally "miss" anything, since the certificate is not constructed from client-supplied data (=> voila, we're at Langsec :)

by dom0 9y ago

tialaramex 9y ago

Nit pick: Although toy systems work by "just" signing the CSR a real CA like Let's Encrypt basically throws the CSR away after verifying its integrity. The CSR is a signed data structure that says "Hi, here's my public key K1, and I want you to issue me a certificate with properties P1, P2, P3 for names N1, N2, N3" and it's signed using a private key K2. Using K1 (which is right there in the document) we can check that the K2 signature matches. If not, we can't be sure the real owner of K2 even wanted this certificate and we must reject it. Then we can look at the list of P1... and N1... and decide if we want to issue a certificate at all. If we do, we can choose to issue any certificate we want, we don't need to issue exactly the one described in the CSR. This is important because many CSRs, whether generated by well-meaning admins or automatically by an appliance or service, are full of crap that Let's Encrypt doesn't want to, or isn't permitted by the Baseline Requirements to sign. [ e.g. it's very common for CSRs to claim that London is in a County called Middlesex. Nope, that county was abolished decades ago, London isn't in a county at all, but people see a field labelled "State or County" and they figure they should write something in the box. If a CA signs that, they're claiming Middlesex still exists. ] By constructing each certificate from first principles after examining the CSR, Let's Encrypt can ensure they sign only certificates for exactly the things they've validated, nothing else.

dom0 9y ago
Thank you, that's a good and important point. It also has the angle that the CA can't accidentally "miss" anything, since the certificate is not constructed from client-supplied data (=> voila, we're at Langsec :)