Auto renew is failing

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command sudo certbot renew --dry-run
It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/

Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator webroot, Installer apache
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for
Waiting for verification…
Cleaning up challenges
Attempting to renew cert ( from /etc/letsencrypt/renewal/ produced an unexpected error: Failed authorization procedure. (http-01): urn:ietf:params:acme:error:dns :: DNS problem: SERVFAIL looking up CAA for - the domain’s nameservers may be malfunctioning. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/ (failure)

** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/ (failure)
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates above have not been saved.)

1 renew failure(s), 0 parse failure(s)

My web server is (include version): Apache/2.4.25

The operating system my web server runs on is (include version): Raspbian 9 stretch

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 0.28.0

1 Like

Hi @Jonno

checking your domain that looks inconsistent. Your main domain - : There is DNSSEC and a working CAA:

RRSIG Type 257, expiration 2020-02-27 00:00:00 validates the CAA - Result: 5|

Same with unboundtest -

But your subdomain is curious -

Checking CAA:

RRSIG Type 47, expiration 2020-02-27 00:00:00 validates the NSEC RR that proves the not-existence of the CAA RR. Bitmap: A, NS, SOA, MX, TXT, AAAA, RRSIG, NSEC, DNSKEY, CAA

There is a NSEC send -> No CAA. But the Bitmap has the CAA flag.

Same with unboundtest -

A lot of bogus

validate(nodata): sec_status_bogus

and LAME

query response was DNSSEC LAME


Perhaps your DNSSEC is inconsistent. Try to add the same CAA entry with your subdomain, so your DNSSEC is refreshed.

1 Like

Thanks for the reply @JuergenAuer.
I meant to mention that it has all been working for over a year and I have not changed anything on my server.
Can you please give me some detail on how to add the CAA entry with the subdomain as you suggest.

1 Like


It seems like you are using’s free DNS service.
There might be some issues with the DNS servers have… You need to contact them to sort it out…

Thank you

1 Like

That’s a DNSSEC problem. You may have added DNSSEC. Or your dns provider has a problem.

As written: Your main domain works (the CAA), your subdomain not. That’s untypical. Normally, both or none would work.

Same how you have created your main domain entry.

1 Like

The main domain is a free subdomain provider, which i believe is not in the OP’s procession.


Ah, thanks!


Then share the menu of your DNS setup (PS: A screenshot).

Perhaps there is an option to create a CAA entry.

If not, it may not work -> the provider must fix the DNSSEC.

1 Like

I think it looks like your provider needs to run pdnsutil rectify-zone (or pdnsutil rectify-all-zones) – and ensure that their zones are automatically rectified when modified in the future to prevent similar issues from happening.

(For example, it can be configured to automatically rectify when changes are made via the API.)

1 Like

I talked to someone, who talked to someone (who I could’ve talked to in the first place), who talked to YDNS. The zone has been rectified, and resolves correctly now.


The reason for that is that the authoritative DNS servers were erroneously returning the NSEC record for as if no subdomains existed at all.

The DS check above shows that:

DS-Query in the parent zone has a valid NSEC RR as result with the domain name between the NSEC-Owner “” and the NextOwner “”. So the parent zone confirmes the non-existence of a DS RR. Bitmap: A, NS, SOA, MX, TXT, AAAA, RRSIG, NSEC, DNSKEY, CAA

1 Like

Thank you everyone for your responses and help.
I see that my cert has now been renewed.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.