5 ms·

Based on what I know of a high level overview of ACME: The client says "Hey, i have a cert here, and I want to verify i control domain.com" The server says "O

by bisby 10y ago

Based on what I know of a high level overview of ACME: The client says "Hey, i have a cert here, and I want to verify i control domain.com" The server says "Ok, take this [set of challenge data], encrypt it with your cert, and put it at .well-known/acme-challenge." The client takes the challenge data. encrypts it. puts it at the challenge point and informs the server. The server verifies that the encrypted data matches what they were expecting to get. They then sign the cert because only a person with the webserver/domain and the cert could pull off this magic. The important part here, is that since the client already has the cert in hand when the verification is taking place - it can be used as part of the verification. Use the cert to do cert stuff. Only that cert can do those things. If I can't even get a cert until AFTER I've proven I control a location, then this obviously doesnt work and another "proof" has to be made - hence godaddy's issue.

deleted 10y ago
[deleted]
EGreg 10y ago
Google Apps just asked you to upload random text files to certain locations or add DNS TEXT records to verify you own the domain. So does Amazon with SES. You just make an account with them and they give you the stuff. Why isn't that good enough? No need to use a cert to verify it.
- closeparen 10y ago
  Well, this is "upload random text files to certain locations." Let's Encrypt is meant to be renewed by cronjob, and most web servers probably don't have programatic control over their DNS records.
- bisby 10y ago
  That would work. The point of ACME is to not need to generate certs. They just verify them. That removes a bit of computational burden from them. the acme challenge is probably "random text files" too, just generated using the certificate at hand to verify ownership of domain and certificate. Certbot basically is just a client to do all those things you described for you. The difference between "prove you own this domain and we will provide you a signed certificate for it" and "prove you own this domain and this certificate at the same time, and we will sign it for you" It's really not that different, except they have opted to make it such a way that it is easily automated. And it's open source, so if they wanted to google, amazon, or even godaddy could set up an ACME server that validates SSL/TLS certs... but would they be able to charge for it if you had to use the lets-encrypt process anyway?
  - tialaramex 10y ago
    What you wrote about not needing "to generate certificates" is quite wrong, though I suppose I get what made you think this. ACME uses public key cryptography in (at least) three separate places, the keys pairs are different in each place. Like completely different - one could be 2048-bit RSA, one could be a shiny Elliptic Curve key, and one 4096-bit RSA. 1. Access to HTTPS ACME service over SSL/TLS. Let's Encrypt has a private key, users of their ACME service get a public key, this allows them to be confident they are dealing with the genuine Let's Encrypt ACME service 2. ACME accounts and associated challenges. Every would-be subscriber using an ACME service must create an account, this account has a private key (which they know, usually stored in a file on their computer) and a public key, which they send to the ACME service. The ACME private key is used to sign data in ACME challenges. This proves that whoever is passing the challenges (e.g. by putting files on a web server) is also making the ACME requests. This provides the confidence to issue certificates to the account holder. 3. The SSL certificates have a public key baked inside them, which corresponds to a private key owned by the subscriber. The subscriber proves they control the private key and want a certificate by signing a Certificate Signing Request, CSR with their private key. The Certbot software often used with Let's Encrypt automates most of this, making the key pair for (2) automatically and just requesting you OK a PDF describing the rules for Let's Encrypt. By default it will make the key pair for (3) as well BUT if you're getting a certificate for some device that issues its own CSRs, you can hand over a CSR and it will use that one. If it didn't allow this, you couldn't get the right certificate for a device that only issues CSRs, because those devices provide no way to upload a different private key. -- Finally, we expect that third parties will want to offer ACME services where a mandatory challenge is like "Fax us all the paperwork and pay $50 verification fee" and then you get an EV certificate instead of the DV certificates that Let's Encrypt issues. Also, never underestimate the willingness of big businesses to pay money for things.
    - bisby 10y ago
      I see how what I said may have been confusing, but I meant that the ACME server does not generate a certificate for each user. They have their own cert for validating their service (not generated per user). And the user/client generates the certificate. The server isn't (necessarily?) generating the keys, the client is.
rtkwe 10y ago
That does show a fairly easy way that this could have been prevented in GoDaddy's case though. Simply provide both a chunk of data as a token and a location that it should be placed.
- peteretep 10y ago
  My understanding is specifically that wouldn't have helped, because all locations that didn't already have content would have shown the token -- the token being present in the 404 response.
  - corecoder 10y ago
    What parent is saying is: ask to put STRING1 at path STRING2; this way, the server has no way of unintentionally show STRING1, as it is different from STRING2.
  - rtkwe 10y ago
    I should have been more clear but corecoder has it right the token in this case would be a different string/file than the location so you wouldn't run into the issue of some 404 pages including the token because the data godaddy would be looking for is completely unrelated to the url they're checking.
rtkwe 10y ago
That does show a fairly easy way that this could have been prevented in GoDaddy's case though. Simply provide both a chunk of data as a token and a location that it should be placed.

by bisby 10y ago

deleted 10y ago

[deleted]

EGreg 10y ago

Google Apps just asked you to upload random text files to certain locations or add DNS TEXT records to verify you own the domain. So does Amazon with SES. You just make an account with them and they give you the stuff. Why isn't that good enough? No need to use a cert to verify it.

closeparen 10y ago
Well, this is "upload random text files to certain locations." Let's Encrypt is meant to be renewed by cronjob, and most web servers probably don't have programatic control over their DNS records.
bisby 10y ago
That would work. The point of ACME is to not need to generate certs. They just verify them. That removes a bit of computational burden from them. the acme challenge is probably "random text files" too, just generated using the certificate at hand to verify ownership of domain and certificate. Certbot basically is just a client to do all those things you described for you. The difference between "prove you own this domain and we will provide you a signed certificate for it" and "prove you own this domain and this certificate at the same time, and we will sign it for you" It's really not that different, except they have opted to make it such a way that it is easily automated. And it's open source, so if they wanted to google, amazon, or even godaddy could set up an ACME server that validates SSL/TLS certs... but would they be able to charge for it if you had to use the lets-encrypt process anyway?
- tialaramex 10y ago
  What you wrote about not needing "to generate certificates" is quite wrong, though I suppose I get what made you think this. ACME uses public key cryptography in (at least) three separate places, the keys pairs are different in each place. Like completely different - one could be 2048-bit RSA, one could be a shiny Elliptic Curve key, and one 4096-bit RSA. 1. Access to HTTPS ACME service over SSL/TLS. Let's Encrypt has a private key, users of their ACME service get a public key, this allows them to be confident they are dealing with the genuine Let's Encrypt ACME service 2. ACME accounts and associated challenges. Every would-be subscriber using an ACME service must create an account, this account has a private key (which they know, usually stored in a file on their computer) and a public key, which they send to the ACME service. The ACME private key is used to sign data in ACME challenges. This proves that whoever is passing the challenges (e.g. by putting files on a web server) is also making the ACME requests. This provides the confidence to issue certificates to the account holder. 3. The SSL certificates have a public key baked inside them, which corresponds to a private key owned by the subscriber. The subscriber proves they control the private key and want a certificate by signing a Certificate Signing Request, CSR with their private key. The Certbot software often used with Let's Encrypt automates most of this, making the key pair for (2) automatically and just requesting you OK a PDF describing the rules for Let's Encrypt. By default it will make the key pair for (3) as well BUT if you're getting a certificate for some device that issues its own CSRs, you can hand over a CSR and it will use that one. If it didn't allow this, you couldn't get the right certificate for a device that only issues CSRs, because those devices provide no way to upload a different private key. -- Finally, we expect that third parties will want to offer ACME services where a mandatory challenge is like "Fax us all the paperwork and pay $50 verification fee" and then you get an EV certificate instead of the DV certificates that Let's Encrypt issues. Also, never underestimate the willingness of big businesses to pay money for things.
  - bisby 10y ago
    I see how what I said may have been confusing, but I meant that the ACME server does not generate a certificate for each user. They have their own cert for validating their service (not generated per user). And the user/client generates the certificate. The server isn't (necessarily?) generating the keys, the client is.

rtkwe 10y ago

That does show a fairly easy way that this could have been prevented in GoDaddy's case though. Simply provide both a chunk of data as a token and a location that it should be placed.

peteretep 10y ago
My understanding is specifically that wouldn't have helped, because all locations that didn't already have content would have shown the token -- the token being present in the 404 response.
- corecoder 10y ago
  What parent is saying is: ask to put STRING1 at path STRING2; this way, the server has no way of unintentionally show STRING1, as it is different from STRING2.
- rtkwe 10y ago
  I should have been more clear but corecoder has it right the token in this case would be a different string/file than the location so you wouldn't run into the issue of some 404 pages including the token because the data godaddy would be looking for is completely unrelated to the url they're checking.

rtkwe 10y ago

That does show a fairly easy way that this could have been prevented in GoDaddy's case though. Simply provide both a chunk of data as a token and a location that it should be placed.