DNS/CAA Error During Automatic Renewal


#1

Hi all!

I’m running automatic renewal for SSL using LetsEncrypt on a server that has about 26 sites on it. Things have been running very smoothly, but I’m just now seeing a new error that hasn’t come up before on a domain that has been fine for the past few months:

Here is a snippet from the error log:

Domain: www.artisanbakeryexpo.com
Type: None
Detail: DNS problem: networking error looking up CAA for com
2018-10-26 01:01:33,317:INFO:certbot.auth_handler:Cleaning up challenges
2018-10-26 01:01:34,324:INFO:certbot.hooks:Running post-hook command: systemctl start apache2
2018-10-26 01:01:35,554:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
File “/usr/bin/certbot”, line 11, in
load_entry_point(‘certbot==0.21.1’, ‘console_scripts’, ‘certbot’)()
File “/usr/lib/python3/dist-packages/certbot/main.py”, line 1240, in main
return config.func(config, plugins)
File “/usr/lib/python3/dist-packages/certbot/main.py”, line 994, in run
certname, lineage)
File “/usr/lib/python3/dist-packages/certbot/main.py”, line 113, in _get_and_save_cert
renewal.renew_cert(config, domains, le_client, lineage)
File “/usr/lib/python3/dist-packages/certbot/renewal.py”, line 297, in renew_cert
new_certr, new_chain, new_key, _ = le_client.obtain_certificate(domains)
File “/usr/lib/python3/dist-packages/certbot/client.py”, line 318, in obtain_certificate
self.config.allow_subset_of_names)
File “/usr/lib/python3/dist-packages/certbot/auth_handler.py”, line 81, in get_authorizations
self._respond(resp, best_effort)
File “/usr/lib/python3/dist-packages/certbot/auth_handler.py”, line 138, in _respond
self._poll_challenges(chall_update, best_effort)
File “/usr/lib/python3/dist-packages/certbot/auth_handler.py”, line 202, in _poll_challenges
raise errors.FailedChallenges(all_failed_achalls)
certbot.errors.FailedChallenges: Failed authorization procedure. www.artisanbakeryexpo.com (tls-sni-01): urn:acme:error:dns :: DNS problem: networking error looking up CAA for com

I’ve verified that the DNS settings for this domain are set up the same as others on the site on the server.

Thanks in advance!


#2

Hi @blancast

looks like a temporary problem with the com - DNS-settings.

https://sslmate.com/caa/

doesn’t find a problem.

So try it again.


#3

Hi @JuergenAuer

Thanks for the quick response!

I figured it was a temporary problem. The odd thing is that this has happened the last 3 nights in a row, and it actually stalls apache2 and makes the server go down.


#4

Perhaps you should update your Certbot. And

this is deprecated. Read

and switch to http-01 - validation.


#5

Your job stops apache every time it checks for cert updates?
If so, that step should be eliminated and only restart apache when a cert is actually updated.


#6

Hi @JuergenAuer - that’s odd, we have auto-updates on and it seems that 0.21.1 is the latest Ubuntu is pulling that version from the repo.

As for tls-sni-01, I believe we changed to http-01 validation, so I’m not sure why it’s still trying to use tls-sni-01. Could this be because the original certs were requested using tls-sni-01 so it’s continuing to use that validation?


#7

Hi @rg305

That’s surprising! I was certain we had it set up to only stop/start apache2 when the cert update was successful.


#8

Ok. The standalone-certbot has the version 0.27.

Yes, that may be the reason. But that may crash 2019, so add the --preferred-challenges http.

If you have a lot of domains working port 443, certbot must stop your Apache to create the standalone listening port 443.

So your website is down.


#9

Adding this config will force http validation even if the original cert was created using tls?

I have 26 sites - is this the reason certbot is start/stopping apache even if the cert wasn’t successfully updated?


#10

Yes. yo can switch the challenge type.

I don’t know exactly, how Certbot handles such a mass-update with a lot of tls-01-validations. But Certbot must stop Apache to use the port 443 to initialize the listener.

There:

Hooks will only be run if a certificate is due for renewal, so you can run the above command frequently without unnecessarily stopping your webserver.

But if 26 certificates are renewed, there are 26 stops and starts.