3 ms·

Ultimately, if you're attempting to prove hostname control, it would seem fundamentally incorrect to make a request with a Host header or SNI hostname set to an

Ultimately, if you're attempting to prove hostname control, it would seem fundamentally incorrect to make a request with a Host header or SNI hostname set to anything other than the hostname requested for issuance. I don't really understand why this didn't come up while considering the protocol initially. Why aren't we using ALPN for this? (ALPN is used to negotiate HTTP/2 without prior knowledge of the server's capability - https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation https://en.wikipedia.org/wiki/Application-Layer_Protocol_Neg...)

rgbrenner 9y ago
Yes... as long as SNI is used and valid on the internet... it is incorrect to assume IP = domain control.. which is the assumption that the TLS-SNI-01/02 challenges are based on. These challenges are fatally flawed in their current form, and should be discontinued. (Your solution in the first sentence changes it to domain control = domain control. Obviously correct.)
tonyarkles 9y ago
> it would seem fundamentally incorrect to make a request with a Host header or SNI hostname set to anything other than the hostname requested for issuance. Pondering why they'd do it the way it is right now, my best guess would be that it allows you to get a LetsEncrypt certificate while still having a valid certificate from another CA. For example, example.com currently has a Symantec certificate that is soon going to be invalidated, and I want to swap over to an LE cert with 0 downtime.
- BillinghamJ 9y ago
  You could still do that! Just accept LE’s requests with the existing Symantec cert and respond as needed. Or use the DNS challenge. Or use something like ALPN instead.
  - tonyarkles 9y ago
    How would LE do SNI validation using the Symantec cert though? I can't add anything to it without invalidating it. My understanding is that that's why they do the .acme.invalid SNI responses; so that the server can respond with a self-signed cert that's not going to interfere with anything else. DNS and ALPN are both great solution, but here's why neither of them work all that well in my specific circumstances, but TLS-SNI works awesome. - I can provision VMs at will, but I don't personally have access to DNS. To get a DNS record added, I need to submit a change request. I haven't done the DNS challenge, and I'm not sure if a new TXT record gets generated when you renew a cert or if it's static after initial creation, but either way, DNS very much adds a painful manual step to cert provisioning here. - ALPN would be great, if it were baked into the default Centos Apache :). That, I suspect, would be a long time coming... Right now I generally just use HTTP validation, because I've worked out a pattern that generally works pretty good. I set up an Apache rule that auto-redirects all traffic from http to https anyway; I just add a condition to it so that /.well-known/ gets served off the filesystem before redirecting everything else.
    - tialaramex 9y ago
      You need to re-do a proof of control periodically, in normal use it will be for each renewal. So yes, you'd need to do the juggling to sort out a new TXT record every time. For what it's worth I believe Let's Encrypt would happily follow your redirect to the HTTPS site, so long as within a reasonable number of steps you give it the answer it was looking for, the redirect isn't a problem. It also doesn't check certificate validity (after all, it's doing validation, that would be a chicken-and-egg problem) for the redirected HTTPS connection. But just serving the answer directly works fine and is probably more future proof.
    - BillinghamJ 9y ago
      I don't see why you couldn't do the HTTP validation, but over the existing HTTPS cert you have, without having to accept non-TLS connections. To be honest, I just don't think the SNI challenge has any place here. Although I totally recognise it is an easier option where you're more restricted, the fundamental security concerns are more important.

rgbrenner 9y ago

Yes... as long as SNI is used and valid on the internet... it is incorrect to assume IP = domain control.. which is the assumption that the TLS-SNI-01/02 challenges are based on. These challenges are fatally flawed in their current form, and should be discontinued. (Your solution in the first sentence changes it to domain control = domain control. Obviously correct.)

tonyarkles 9y ago

> it would seem fundamentally incorrect to make a request with a Host header or SNI hostname set to anything other than the hostname requested for issuance. Pondering why they'd do it the way it is right now, my best guess would be that it allows you to get a LetsEncrypt certificate while still having a valid certificate from another CA. For example, example.com currently has a Symantec certificate that is soon going to be invalidated, and I want to swap over to an LE cert with 0 downtime.

BillinghamJ 9y ago
You could still do that! Just accept LE’s requests with the existing Symantec cert and respond as needed. Or use the DNS challenge. Or use something like ALPN instead.
- tonyarkles 9y ago
  How would LE do SNI validation using the Symantec cert though? I can't add anything to it without invalidating it. My understanding is that that's why they do the .acme.invalid SNI responses; so that the server can respond with a self-signed cert that's not going to interfere with anything else. DNS and ALPN are both great solution, but here's why neither of them work all that well in my specific circumstances, but TLS-SNI works awesome. - I can provision VMs at will, but I don't personally have access to DNS. To get a DNS record added, I need to submit a change request. I haven't done the DNS challenge, and I'm not sure if a new TXT record gets generated when you renew a cert or if it's static after initial creation, but either way, DNS very much adds a painful manual step to cert provisioning here. - ALPN would be great, if it were baked into the default Centos Apache :). That, I suspect, would be a long time coming... Right now I generally just use HTTP validation, because I've worked out a pattern that generally works pretty good. I set up an Apache rule that auto-redirects all traffic from http to https anyway; I just add a condition to it so that /.well-known/ gets served off the filesystem before redirecting everything else.
  - tialaramex 9y ago
    You need to re-do a proof of control periodically, in normal use it will be for each renewal. So yes, you'd need to do the juggling to sort out a new TXT record every time. For what it's worth I believe Let's Encrypt would happily follow your redirect to the HTTPS site, so long as within a reasonable number of steps you give it the answer it was looking for, the redirect isn't a problem. It also doesn't check certificate validity (after all, it's doing validation, that would be a chicken-and-egg problem) for the redirected HTTPS connection. But just serving the answer directly works fine and is probably more future proof.
  - BillinghamJ 9y ago
    I don't see why you couldn't do the HTTP validation, but over the existing HTTPS cert you have, without having to accept non-TLS connections. To be honest, I just don't think the SNI challenge has any place here. Although I totally recognise it is an easier option where you're more restricted, the fundamental security concerns are more important.