Great idea. Flawed implementation


#1

I’ve played with Let’s Encrypt for a few days now, and I have two concerns with this implementation. First, if you’re using a non-Apache web server (e.g., Nginx), the recommended renewal-check job brings the web server down before checking (via a REST query) for cert expiration. The recommendation is to run this job every hour. That means once an hour, for a minute or so, the secured web server is down. For really small companies who are thrilled with the idea of a cheap (or free) SSL cert, this restriction might, in fact, make the whole approach a non-starter. Of course, running the job less frequently (e.g., at night) might be fine, though that increases the chances of generating browser errors on the day your cert happens to expire. And, since they expire every 90 days, this is potentially… problematic.

My second concern is actually more worrisome to me. When I use a Let’s Encrypt cert on a web site, and I check the cert in Chrome, I see the following: Your connection to www.example.org is encrypted using an obsolete cipher suite. The connection uses TLS 1.0. While it’s entirely possible that there’s nothing at all wrong with these certs, that warning might put people off. Granted, not too many people bother to check the certs, but some do…


#2

Hi @bmc,

Thanks for your comments.

With regard to your first concern, I’m going to make a post today (probably in one to two hours) describing a new renewal system which should work better in several respects than our previous suggestions. We’ve been hard at work recently on improving the renewal process. However, you’re right that integration with other web servers needs to be improved.

The example that you’re referring to is only one example of one particular configuration, and it can already be improved in many ways using our existing technology. For example, if you get certificates using the webroot plugin instead of the standalone plugin, you never need to take your webservers down at all for issuance purposes (though you do need to reload them to deploy a new cert when renewal occurs). The script you saw assumes that nginx users need standalone, which is not always the case; many nginx users are using webroot successfully. That script also doesn’t check whether the cert is near expiry before trying to renew, which is simply a bug!

With regard to your second concern, TLS certificates do not specify or prescribe in any way what version of TLS they can be used with. We have thousands of users using our certificates with TLS 1.1 and 1.2, and we strongly encourage users to configure their web servers to use newer versions of TLS. The TLS 1.0 connection that you’re seeing is a result of the web server configuration, not of anything in the certificate.

Anyway, I agree that our example renewal scripts are not ideal and can have undesired properties; hopefully we can get better renewal suggestions posted soon. If you look around renewal threads on this forum, you can also find other people’s sample renewal scripts, some of which may be preferable to our samples in various ways.


#3

My bad on the TLS 1.0 issue, and thank you for pointing that out.

Regarding the changes to the renewal process, awesome. The better this works, the more likely the uptake. Regarding webroot and Nginx, having instructions available for how to do that is something to consider. If I manage to get that working, I’ll try to share the information (assuming I ever have time to look into it).