Another Letsencrypt method

Discuss your pilot or production implementation with other Zimbra admins or our engineers.
User avatar
JDunphy
Outstanding Member
Outstanding Member
Posts: 341
Joined: Fri Sep 12, 2014 11:18 pm
Location: Victoria, BC
ZCS/ZD Version: Release 8.7.11_GA_1854.RHEL6_64.P7
Contact:

Re: Another Letsencrypt method

Postby JDunphy » Sun Nov 04, 2018 1:55 pm

I was able to test this a little more and while the script works perfectly for installation it fails to reload the ldap certificate and gives a false sense that everything worked perfectly. As a result - some point in the future that running ldap process will have an expired certificate. That causes a lot of side effects with stop/restarts/status etc. If you restart zimbra or reboot your hosts before the expiration then one might not notice this because the updated cert would have been reloaded. I have updated the wiki to reflect this code change. Too bad because restarting/reloading did shave a little time off the outage to update the certificate.

Note: Given how badly an expired ldap certificate behaves in this failure mode, I am going with the full restart vs finessing the addition of an ldap restart/reload to those other 3 restart/reloads myself.


User avatar
JDunphy
Outstanding Member
Outstanding Member
Posts: 341
Joined: Fri Sep 12, 2014 11:18 pm
Location: Victoria, BC
ZCS/ZD Version: Release 8.7.11_GA_1854.RHEL6_64.P7
Contact:

Re: Another Letsencrypt method

Postby JDunphy » Thu Jan 31, 2019 3:50 pm

FYI - reminder if anyone is doing TLS-SNI-01 validation instead of the others methods such as DNS, HTTP, etc that it is deprecated. Here is the official wording:

Let’s Encrypt soon will disable support for the TLS-SNI-01 domain validation method in the ACME protocol. In January of last year, a vulnerability in TLS-SNI-01 was discovered by Frans Rosén from Detectify. The deprecation will likely cause problems for users of some stable Linux distributions.

TLS-SNI-01 requires a user to temporarily serve a certificate with a special, invalid domain name via the TLS SNI extension. However, under many cloud provider’s settings, it’s possible for users to exploit this scenario and get positive validation for domains hosted by other users at the same cloud provider. This affected Heroku and Amazon CloudFront, for example.

Let’s Encrypt decided that this inherent vulnerability of the TLS-SNI-01 method is too much of a risk and therefore to deprecate it fully. But until now, there was still an exception in place for some providers and for certificate renewals.

The final deadline for TLS-SNI-01 is February 13, 2019, after which all current setups using this method will stop working. Let’s Encrypt certificates have a relatively short lifetime of ninety days, and it heavily relies on automated renewal. Let’s Encrypt sent out warning emails in recent weeks to those who still use TLS-SNI-01, but not all users will get them because providing an email address isn’t mandatory to use Let’s Encrypt.

If you do anything odd with your firewall rules like blocking port 80, your automatic renewal could fail if you are expecting TLS/443 access with certbot.

Note: If you are using acme.sh with DNS validation it will continue to work. Another great use of this validation method - it works for servers even on RFC1918 address space such as home zimbra instances and plex media servers. So give it a try if you are tired of getting those untrusted cert errors. :-)

Return to “Administrators”

Who is online

Users browsing this forum: No registered users and 22 guests