Lets encrypt kerfuffle
Let's encrypt had a kerfuffle last week by accidentally not checking CAA DNS records of domains it had requests for.
CAA records are a way of recording who your domain will accept certificates to
be generated by. As an example, use dig to lookup the CAA of usc.edu.au:
# dig CAA usc.edu.au +short
0 iodef "mailto:ssladmin@usc.edu.au"
0 issue "quovadisglobal.com"
0 issuewild "quovadisglobal.com"
In this case, a CA other than quovadisglobal will refuse to generate a certificate for usc.edu.au.
The bug with Let's Encrypt was that they were not checking the CAA record every time, and therefore some of those certificates might not have been correct to generate.
My site zigford.org uses a Let's Encrypt certificate, but since using cloudflares free DNS offerring, you'll likely see their certificate when you visit my site. Nonethelsee my site could have been affected and I was interested to see if it were so.
Since Let's Encrypt certs expire very quickly (90 days I think?), it's the type of thing that begs to be automated. Let's encrypt decided to revoke all certificates issued during the presence of the bug and thankfully according to this wired article Certbot users should be pretty much unaffected as the tool will check if a revocation has happened.
So I checked through my logs and sadly, no, I was not affected. Here is what it looks like when certbot detects your certificate is going to expire shortly anyway (date stamps removed for brevity):
journalctl -u certbot-renew
Cert is due for renewal, auto-renewing...
Non-interactive renewal: random delay of 61.05961969260669 seconds
NGINX configured with OpenSSL alternatives is not officiallysupported by Certbot.
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for www.zigford.org
http-01 challenge for zigford.org
Waiting for verification...
Cleaning up challenges
Moral of the story? Use automation maybe?
Tags: certs, lets-encrypt