4 ms·

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

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.
  - tonyarkles 9y ago
    Your sibling comment suggests that the LetsEncrypt verifier would potentially follow a redirect HTTPS, which I'm going to have to experiment with today because it'd keep things simpler here. Best I know, currently HTTP validation is required to happen on port 80. And that works awesome for bootstrapping; on a new install, you don't need to provision a fake self-signed cert to be able to request a real one. If it can happen over HTTP or HTTPS, that would be amazing.
    - BillinghamJ 9y ago
      It seems... very strange that it doesn't allow the use of port 443/HTTPS with a self-signed cert. It's exactly the same thing.

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.
- tonyarkles 9y ago
  Your sibling comment suggests that the LetsEncrypt verifier would potentially follow a redirect HTTPS, which I'm going to have to experiment with today because it'd keep things simpler here. Best I know, currently HTTP validation is required to happen on port 80. And that works awesome for bootstrapping; on a new install, you don't need to provision a fake self-signed cert to be able to request a real one. If it can happen over HTTP or HTTPS, that would be amazing.
  - BillinghamJ 9y ago
    It seems... very strange that it doesn't allow the use of port 443/HTTPS with a self-signed cert. It's exactly the same thing.