Letsencrypt is revoking certificates on March 4

L et’s Encrypt is a non-profit certificate authority that provides X.509 certificates for Transport Layer Security (TLS) encryption free of cost. The TLS certificate is valid for 90 days only. However, Due to the bug, they need to revoke many (read as “certain”) Let’s Encrypt TLS/SSL certificates. Let us see how to find out if you are affected by this bug and how you can fix it to avoid any problems with your TLS/SSL certificates.

The revocations start on 04 March 2020, and you need to renew your certificate before that; otherwise, your visitors will get an error about Invalid and expired/revoked certificate error.

When a TLS certificate request contained N domain names that needed CAA rechecking, Boulder would pick one domain name and check it N times. What this means in practice is that if a subscriber validated a domain name at time X, and the CAA records for that domain at time X allowed Let’s Encrypt issuance, that subscriber would be able to issue a certificate containing that domain name until X+30 days, even if someone later installed CAA records on that domain name that prohibit issuance by Let’s Encrypt.

2020.02.29 CAA rechecking bug

From the forum thread:

On 2020-02-29 UTC, Let’s Encrypt found a bug in our CAA code. Our CA software, Boulder, checks for CAA records at the same time it validates a subscriber’s control of a domain name. Most subscribers issue a certificate immediately after domain control validation, but we consider a validation good for 30 days. That means in some cases we need to check CAA records a second time, just before issuance. Specifically, we have to check CAA within 8 hours prior to issuance (per BRs §3.2.2.8), so any domain name that was validated more than 8 hours ago requires rechecking.

How many certificates are affected?

According to project site 3,048,289, currently-valid certificates are affected, out of 116 million overall active Let’s Encrypt certificates. Of the affected certificates, about 1 million are duplicates of other affected certificates, in the sense of covering the same set of domain names.

How to check if I am using an affected Letsencrypt certificate

Linux, macOS and Unix users can use the curl command as follows:

$ curl -XPOST -d 'fqdn=your-domain-name-here' https://unboundtest.com/caaproblem/checkhost

For example, I am going to check www.nixcraft.com certificate using the following syntax:

$ curl -XPOST -d 'fqdn=www.nixcraft.com' https://unboundtest.com/caaproblem/checkhost
 $ curl -XPOST -d 'fqdn=nixcraft.com' https://unboundtest.com/caaproblem/checkhost

Sample outputs:

The certificate currently available on www.nixcraft.com is OK. It is not one of the certificates affected by the Let's Encrypt CAA rechecking problem. Its serial number is 04800cab6c1b2c7ec770845bf02b04e696a2

Here is how it looks when the certificates affected by the bug:

The certificate currently available on www.cyberciti.biz needs renewal because it is affected by the Let's Encrypt CAA rechecking problem. Its serial number is 04xxxxxxxxxxxxxxxxxxxxxxxxxxxxcd1. See your ACME client documentation for instructions on how to renew a certificate.

There is an online tool for Windows and mobile users to check whether a host’s certificate needs replacement:

https://unboundtest.com/caaproblem.html

2020.02.29 CAA Rechecking Bug

How do I force renew the certificate to avoid this bug?

Pass the --force-renewal option to the certbot command to request a new certificate with the same domains as an existing certificate:

$ certbot renew --force-renewal

Please note that if you see rate limit error, you need to create a certificate with the domain(s) you want and additional domain. For example, if I am getting a rate limit error for www.cyberciti.biz, I should try another sub-domain like test.cyberciti.biz. The syntax is as follows:

$ certbot -d cyberciti.biz,www.cyberciti.biz,test.cyberciti.biz --expand

In my case I already had a certificate which includes cyberciti.biz, www.cyberciti.biz and it want one more certificate to get around rate limit error. So I added the test.cyberciti.biz. Make sure you include every domain name you want.

A note about acme.sh client

In many of my tutorials, I talked aboutacme.sh client, so the syntax is as follows:

$ acme.sh -f -r -d www.cyberciti.biz -d cyberciti.biz

Where,

-f : Used to force to install or force to renew a cert immediately
-r : Renew a cert.
-d DOMAIN_NAME : – Your domain names.

Verify that your certificate is no longer affected by the bug:

curl -XPOST -d 'fqdn=www.cyberciti.biz' https://unboundtest.com/caaproblem/checkhost

Sample outputs:

The certificate currently available on www.cyberciti.biz is OK. It is not one of the certificates affected by the Let's Encrypt CAA rechecking problem. Its serial number is 0704cf1cca2ef1c7abf433466b6231e00000

Conclusion

Letsencrypt is revoking certificates on March 4, and it the inconvenient for many of its users. However, they are patching a critical bug, and I tested the renewal procedure for TLS certificates, which went smoothly. I encourage you to see the following URLs:

Incident bug report here
Revoking certain certificates on March 4 forum post here

Letsencrypt is revoking certificates on March 4