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.
HI,
That’s what I thought at the start too.
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
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.
@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.
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.
Using an older version of pyopenssl as suggested heremight 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 ) .