Renew problems after updating certbot

Help
1

I’m running many sites on our servers. I recently got an email about the end-of-life of TLS-SNI-01 validation. Therefore I’m updating certbot clients from all of our servers. After updating, I made a new certificate with ./certbot-auto --apache and it seemed to issue and work nicely.

But when I run ./cerbot-auto renew --dry-run I get different kind of errors:

“DNS problem: SERVFAIL looking up CAA…”
“DNS problem: SERVFAIL looking up A…”
“No valid IP addresses found…”

And this is not just for one domain. Happens with different servers, different domains, different IP-addresses. I use saul.fi domain here as an example. Sometimes the dry-run even goes through. Seems that the checks work sometimes, and sometimes don’t. Even with Let’s Debug I get different kind of errors on each run:

https://letsdebug.net/saul.fi/20959
https://letsdebug.net/saul.fi/20957
https://letsdebug.net/saul.fi/20958

My domain is: saul.fi

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

The operating system my web server runs on is (include version): Feroda 26

My hosting provider, if applicable, is: Own server

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

The version of my client is: certbot 0.30.2

2

I ran https://unboundtest.com/ 3 times, it failed on the last one.

https://unboundtest.com/m/A/saul.fi/HBINTOH7

It's looks like this issue:

3

Unfortunately this doesn’t tell me much. Is there anything I can do, or is this a problem with my DNS provider? If it is, should I contact them and ask for what?

4

Looks like a variant of the additional record ordering.

First:

parse of NS(2) IN(1) saul.fi.
parse of NS(2) IN(1) saul.fi.
parse of NSEC3(50) IN(1) rokbtsmlfioipkff1psd35p98eofm0v6.fi.
parse of RRSIG(46) [NSEC3(50)] IN(1) rokbtsmlfioipkff1psd35p98eofm0v6.fi.
parse of NSEC3(50) IN(1) g3d9n9gg4vuto3numgsk0li82v37pj9a.fi.
parse of RRSIG(46) [NSEC3(50)] IN(1) g3d9n9gg4vuto3numgsk0li82v37pj9a.fi.
parse of A(1) IN(1) ns.nebula.fi.
parse of AAAA(28) IN(1) ns.nebula.fi.
parse of A(1) IN(1) ns2.nebula.fi.
parse of AAAA(28) IN(1) ns2.nebula.fi.
parse of OPT(41) ??(4096) .

Second:

parse of NS(2) IN(1) saul.fi.
parse of NS(2) IN(1) saul.fi.
parse of NSEC3(50) IN(1) rokbtsmlfioipkff1psd35p98eofm0v6.fi.
parse of RRSIG(46) [NSEC3(50)] IN(1) rokbtsmlfioipkff1psd35p98eofm0v6.fi.
parse of NSEC3(50) IN(1) g3d9n9gg4vuto3numgsk0li82v37pj9a.fi.
parse of RRSIG(46) [NSEC3(50)] IN(1) g3d9n9gg4vuto3numgsk0li82v37pj9a.fi.
parse of AAAA(28) IN(1) ns.nebula.fi.
parse of AAAA(28) IN(1) ns2.nebula.fi.
parse of A(1) IN(1) ns.nebula.fi.
parse of A(1) IN(1) ns2.nebula.fi.
parse of OPT(41) ??(4096) .

ns/ns/ns2/ns2 vs ns/ns2/ns/ns2.

I believe not, except try again repeatedly and pray the bad nameserver isn't involved.

I think that this requires either fi to fix e.fi nameserver, or for Let's Encrypt to patch their Unbound instance (but there is no numbered release with the fix published yet).

1 Like
5

I just sent an e-mail to CDNS referencing the other forum thread and pointing out that this appears to affect e.fi as well.

6

Ok, thanks guys. Good to know this is a known problem, so I can expect it to be fixed at some point.

7

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