I’ve switched all my websites and servers to use certificates from the Let’s Encrypt. They’re a very new certificate authority (the entity responsible for verifying and issuing cryptographic certificates) and they still consider themselves to be in beta. Here are my experiences after using their certificates for two months.
The cost of a basic TLS certificate was no more than 6 USD from the cheapest certificate authorities before Let’s Encrypt entered the market. But the time, effort, and technical skills required to set it up still prohibited their deployment across the web. I’ve had four certificates issued in Let’s Encrypt’s closed beta program, and have grown that number to ten since they opened up to public beta. Let’s Encrypt’s process is much more convenient and faster to deploy certificates than having them issued and installed manually by traditional certificate authorities.
I only had two websites with certificates before migrating to Let’s Encrypt. Renewing these certificates was always a hassle as their two year-expiration windows were just enough time to forget everything about the issuance process. The automatic-issuance and auto-renewing scheme deployed by Let’s Encrypt have cut the time needed to deploy TLS down from around two hours to mere minutes.
The signing certificates Let’s Encrypt are using are cross-signed by IdenTrust in addition to Let’s Encrypt’s own new root certificate. This should ensure support in most clients even without them having to update their certificate root stores to include Let’s Encrypt. The web browsers on PlayStation 4 and Nintendo Wii U are notable clients that lack support for IdenTrust’s root certificates and by extension Let’s Encrypt.
There are also a ton of online services that can no longer talk to my websites including AppleNewsBot. This is a mixed blessing as bot traffic has dropped considerably, but I’ve also lost access to my favorite keyword analysis tools. It has also affected feed subscription numbers as many feed readers and feed syndication services are built on versions of Java that don’t support the IdenTrust root certificate.
I’ve had moderate success reaching out to these services about supporting Let’s Encrypt and most haven’t bothered responding at all. Most notably the Internet Archive has added support.
I had to write some patches for the Let’s Encrypt client to fix installation problems on my servers running Fedora Linux. Other than those initial installation problems, the client hasn’t given me any issues and it’s performed its job as advertised. Let’s Encrypt have since been added to Fedora Linux’s stable package repository. I’m somewhat worried that a package proclaimed by its upstream to be a beta was added to a distribution’s stable package repositories. Some caution here would probably have been advisable.
I’ve noticed a degradation in Apache httpd web server resulting from slow and sometimes unresponsive OCSP servers. During Apache startup, it’s been configured to “staple” OCSP responses to the end of each certificates. The benefit of that’s that each user doesn’t have to repeat this process and it can speed up their connection performance.
However, I’m seeing a 20–40 seconds delay in http start-up times for a server with ten VirtualHosts each running with their own certificate that needs a response from Let’s Encrypt’s OCSP server confirming the certificates’ validity. When rebooting a server, this can take your website’s downtime from 2–8 seconds and up to near a full minute. OCSP stapling is repeated every so often, and I’ve logs full of “[ssl:error] AH01972: could not resolve address of OCSP responder ocsp.int-x1.letsencrypt.org” and “AH01941: stapling_renew_response: responder error” error messages.
Update (): The specific issue above was caused by Let’s Encrypt. However, upon reviewing my logs (I do keep logs for that long) I’ve also found that some of the failures were caused by enforcing Security-Enhanced Linux (SELinux) policies. See Allowing OCSP stapling in Apache Web Server with SELinux policies for details on that.
I’d not recommend that any website depending on wide compatibility support adopt Let’s Encrypt for another full year or even longer. Websites that deploy it should remain accessible over HTTP to ensure everyone can still reach it. I’ve chosen to sacrifice client compatibility for free security and a less stressful day-to-day system’s administration. That might not be the right option for everyone.
Update (): The above recommendation is outdated, and Let’s Encrypt is now suitable for use for just about every website except those with exceptionally high compatibility requirements for fringe and outdated devices.