No possible way to renew once TLS-SNI validation goes away

I have full control over my server, but not over the firewall or DNS.
Port 443 is open in both directions. Inbound port 80 is closed.

TLS-SNI validation worked to get me started, but once it goes away I can’t see any way I’ll ever be able to renew.

What are people in my position expected to do? Right now it looks like I’ll have no choice but to revert to a self-signed certificate.

If you can’t use any of the ACME challenges, then you could use one of the other automated CAs that are around. The one I linked will try on both 80/tcp and 443/tcp.

1 Like

The previous discussions in the ACME working group apparently concluded that we can’t safely do a file-content-based challenge on port 443 in terms of the practices of hosting providers. In a way, this is an earlier version of the concern that we’re now facing with TLS-SNI-01. I’m not sure that Let’s Encrypt will be able to resume using any validation method that begins with a connection on port 443.

Thanks to @_az for the suggestion; I hadn’t seen that CA before.

I think a key challenge that all domain validation will eventually face is the challenge in the OP’s comment:

It’s hard to imagine the server at :443 is legitimate if the party running it can not achieve, via working with coworkers / vendors / etc to get delegation of a DNS CNAME record for acme challenges. Or to get the firewall admin to open port 80 for ACME challenges.

How often are those things impossible?

Thank you! I didn’t know about the service you suggested. I’ve obtained a certificate from there, and my problem is now solved.

Although I’m disappointed; I really like the idea of LetsEncrypt.

I have no idea how common my situation is.

What I’m doing is running a personal web server for my own uses, to replace a public server which management decided was no longer required – even though I and a few of my colleagues depended on it.

Could I persuade the network team to open port 80 just to
Probably, but given the management climate at my institution, I’d prefer to leave that can of worms unopened.

Unfortunately, this is in tension with some efforts by the CA industry to give management—in the form of network administrators representing domain owners—more control over the ability to issue certificates. "We don't want to have to ask the domain owner before getting a certificate" isn't a case that the industry is very friendly to, even though in your case your intentions are entirely non-malicious.

I agree. While I understand the user’s dilemma and sympathize, there is a good case to be made that, in fact, such a certificate should not issue. If there’s hesitation to seek the active permission of the domain holder, this suggests against issuance.

1 Like

For this use-case, you could probably just buy a domain ($10 a year or less) specifically for this, or probably use custom signed certificates. I doubt your IT department locked down the 443 traffic to connections for accepted domains (which is sort of possible, but a huge pain to implement). I am certain your manager would approve this expense.

An idea which I offer that might help in your particular situation, rather than because I think it’s a good idea per se.

If normal Internet DNS works from your workplace, you could arrange to create a name for the service in a domain the employer doesn’t own, either a “free” domain like no-ip (not an endorsement) or your own. You would control DNS for this name (and thus pass dns-01) and you would control the service in fact so you could install the certificate. You and colleagues would use this new name for the service and the cert would check out as OK. Using dns-01 this way Let’s Encrypt won’t even care if the service becomes entirely inaccessible from the Internet.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.