Could LE expand to cover servers with no SNI support? (= dedicated IP per SSL cert)

Older servers with an openssl version earlier than 0.9.8f will have no 'SSL_set_tlsext_host_name' support, BUT those web servers will also not support SSLs hosted on a shared IP anyway. They all still require dedicatd IPs for hosting SSL certificates on them.

My question here is, how much re-engeering or effort would it take for the current “letsencrypt-auto” to detect those older servers such as the whole RHEL 5.x (and CenOS 5.x and all it’s other RHEL derivatives) which still run on openssl 0.9.8e with all applicable security CVEs backported to it, the ‘redhat’ enterpsie way.

There are still thousands of web servers that are hosted on those older OSs, and their 10 years enterpise support has a few years left on them and they won’t simply disappear anytime soon.

This stream of letsencrypt-auto would really help those web servers to also get SSL certifciates for their single dedicated IP hosted domains.

While not having tested the auto-configuration without SNI, I don’t see any reason why you shouldn’t be able to issue certs for those domains. You might need to use certonly mode with webroot or http-01 auth and configure the vhosts yourself, but apart from that it should work out of the box.

I’m not 100% certain how this will work with SANs, because there have been problems with the webroot method in that regard (same webroot for all domains, can be solved easily) and it is possible (while unlikely) that the client will complain about the domains being hosted on different machines.

Your best option is probably to use the reverse proxy method explained here LE client needs to bind to port 80, which I'm already using
Simply issue one cert for all domains regardless of their IP.

If you issue one cert for each domain separately that should work as well, but results in more work.

That’s what I thought at the start too. :wink:
But unless I am missing something, or maybe there is a trick, I only ever get a big FAT null with the error message:

“AttributeError: ‘module’ object has no attribute ‘SSL_set_tlsext_host_name’”

And what I am hoping for, is that on machines where I do not care for SNI and hosting multiple SSLs on a single IP, speak where I am happy to give one dedicated IP per each SSL domain, I was really hopeing letsencrypt would not give up with above error message, but instead let me proceed with a lesser requirement that does not ask for ‘SSL_set_tlsext_host_name’ support (and hence SNI).

Please note that 0.9.8 will loose the official support soon.

Support for version 0.9.8 will cease on 2015-12-31. No further releases of 0.9.8 will be made after that date. Security fixes only will be applied to 0.9.8 until then. – OpenSSL

1 Like

Take a look at the list of alternative ACME clients, I doubt they all have a hard dependency on SNI. My money would be on letsencrypt-nosudo. IMO, having to support OpenSSL versions that old would be too big of a trade-off for the official client, considering there are alternatives that do not rely on SNI. But that’s just me. :grin:

@kelunik: Distributions often have longer support cycles and backport critical security fixes of software they ship. Not sure if this is the case with CentOS/RHEL and OpenSSL here, but it’s possible.

1 Like

Sure, I know that. But this support will never be as good as the support by the official maintainers.

Does that happen with webroot auth as well? I cannot imagine that being the case, since you don’t even need to run the LE client on the same machine for webroot auth to work.

BTW, this was flagged as wontfix here:

Using an older version of pyopenssl as suggested here might work if you’re using a mode that doesn’t rely on SNI, like webroot/manual. But, given your environment, I’d just stick with a simple client that doesn’t use SNI at all (i.e. works without workarounds :smiley:) .

1 Like