Wildcard DNS-01 Certbot: DNS problem SERVFAIL CAA

Help
1

Dear community,

I try to issue a wildcard certificate via DNS-01 challenge and the RFC2136 plugin of Certbot.
Running the below command with the Domain at-visions.net worked successfully. (but the .net does not have any CAA records to be fair :slight_smile: )

But running it on at-visions.com issues a SERVFAIL of my nameservers while checking the CAA records.

When manually checking the CAA records everything seems to be fine:
âžś ~ dig @ns2.at-visions.net at-visions.com caa

; <<>> DiG 9.10.6 <<>> @ns2.at-visions.net at-visions.com caa

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47302

;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 5

;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;at-visions.com. IN CAA

;; ANSWER SECTION:

at-visions.com. 3600 IN CAA 128 issue “ssl.com”

at-visions.com. 3600 IN CAA 128 issue “letsencrypt.org”

at-visions.com. 3600 IN CAA 128 iodef “mailto:webadmin@at-visions.com”

;; AUTHORITY SECTION:

at-visions.com. 38400 IN NS ns2.at-visions.net.

at-visions.com. 38400 IN NS ns1.at-visions.net.

;; ADDITIONAL SECTION:

ns1.at-visions.net. 38400 IN A 194.232.117.129

ns2.at-visions.net. 38400 IN A 80.123.233.65

ns1.at-visions.net. 38400 IN AAAA 2001:470:5127:1::53

ns2.at-visions.net. 38400 IN AAAA 2001:850:40f6:1::53

;; Query time: 36 msec

;; SERVER: 80.123.233.65#53(80.123.233.65)

;; WHEN: Thu May 14 13:33:40 CEST 2020

;; MSG SIZE rcvd: 290

I tried removing the ssl.com CAA, tried adding issuewild CAA… All possible combinations.

I tried to google for the exact name server lookup LetsEncrypt is doing for this verification, but I could not find it (so I can check myself what the results are).

Is there an issue with my CAA entries?

Thanks,
phix

PS: also no error logs on the nameserver (@SERVFAIL)

My domain is: at-visions.com

I ran this command: certbot certonly --dns-rfc2136 --dns-rfc2136-credentials ~/certbot-rfc2136.secrets -d *.at-visions.com

It produced this output:
[root@acme01 ~]# certbot certonly --dns-rfc2136 --dns-rfc2136-credentials ~/certbot-rfc2136.secrets -d *.at-visions.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator dns-rfc2136, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for at-visions.com
Waiting 60 seconds for DNS changes to propagate
Waiting for verification…
Challenge failed for domain at-visions.com
dns-01 challenge for at-visions.com
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: at-visions.com
    Type: dns
    Detail: DNS problem: SERVFAIL looking up CAA for at-visions.com -
    the domain’s nameservers may be malfunctioning

My web server is (include version): None, using DNS-01 challenge

The operating system my web server runs on is (include version): CentOS 8.1

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):
[root@acme01 ~]# certbot --version

certbot 1.3.0

1 Like
2

Might be an IPv6 thing? I can't get your NS2's IPv6 to answer me with this query:

$ dig +dnssec -6 @ns2.at-visions.net at-visions.com caa

; <<>> DiG 9.16.1-Ubuntu <<>> +dnssec -6 @ns2.at-visions.net at-visions.com caa
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Also, this test (Let's Debug), which uses the same DNS software internally as the resolver Let's Encrypt uses, it taking a really long time. That basically only happens when it can't get an answer from a nameserver.

Smells like a network problem to me.

Edit: oh hey, the test finally finished:

DNS response for at-visions.com had fatal DNSSEC issues: validation failure <at-visions.com. CAA IN>: signature crypto failed from 80.123.233.65

Looks like not network after all.

2 Likes
3

Hi @Phix

your name servers are buggy - https://check-your-website.server-daten.de/?q=at-visions.com

2020-05-14.at-visions.com

No TCP support of your ipv6 name server.

And extremely rare (never seen such a combination).

2020-05-14.at-visions.com.II

It's possible to validate your zone and to validate your A- and TXT record.

But validating your CAA fails.

2 Likes
4

Let’s Encrypt may or may not care, but the SOA record is bogus, too.

https://dnsviz.net/d/at-visions.com/Xr0wZA/dnssec/

2 Likes
5

Why do your CAA records all have 128 value ?

You might want to set them all to zero and try again.

1 Like
6

128 is valid, though. And it’s still a serious bug if the signer is doing something wrong.

1 Like
7

And the ramifications of that are?

1 Like
8

Dear all,

thanks for your quick replies :wink:
@ IPv6: yes, I know we currently have a IPv6 routing issue in the DC - I forgot to mention it - and hoped that LE will fallback to IPv4 in such a case.
@_az thanks for providing the lets debug link, I was not aware of that (and was too stupid to google it apparently :wink: )
@JuergenAuer thanks as well, will look into the DNSSEC error. Strange to me too…
@ mnordhoff thanks for the SOA hint. It seems our DNSSEC is totally messed up :nauseated_face:
@ rg305 because the German wikipedia states that 128 refuses CAs to issue certificates if the CAA records cannot be evaluated.
Is this incorrect? What would be a correct value?

Thank you all again for your quick help (and the really useful debug links :wink: )
I will sort all issues out and report back (successful hopefully)

1 Like
9

I only see zeros and ones … although I guess "1" may have been misinterpreted as 128 ('10000000'):

image

Despite the inclusion, the "usefulness" of it doesn't make much sense to me.
Additionally, every site I queried uses "0".
Yours is the only one I found using anything else.

So again:

10

Then you should remove the name server ipv6 address. Fix it, then add it again.

About the 32773 value in your CAA: 0, 1, 5, 9 are some values I see.

server-daten.de uses INWX name servers. There is a 5.

1 Like
11

In the web PKI, it's effectively a no-op for the iodef, issue and issuewild properties. CAs are required by the Baseline Requirements to understand them, so you could say that they're effectively always critical.

(CAs are not required to use iodef, though.)

I used to use 128, but I switched to 0 to be more boring.

128 is correct. The flags field is one byte and the critical flag is the biggest bit.

1 Like
12

Welcome to the boring side of the house :slight_smile:

1 Like
13

image
That means that LE must “support” all 3 values:

image
image730Ă—55 1.7 KB

One of which is an email address…
How is that supported (by LE)?
Or is it just ignored…
But wait! It can’t ignore it, the RFC mandated otherwise…

Maybe the iodef should be set to zero.

1 Like
14

BR 1.7.0 § 3.2.2.8:

When processing CAA records, CAs MUST process the issue, issuewild, and iodef property tags as specified in RFC 6844, although they are not required to act on the contents of the iodef property tag.

In any case, the problem here seems to be the RRSIG record, not the semantics of the CAA records themselves. Boulder doesn't even have the opportunity to see them.

1 Like
15

Dear all,

shame on me!! I manually fiddled with the CAA records and forget to resign the zone…
Despite the IPv6 errors it seems now OK and I could successfully obtain the certificate :wink:

Thank you all very much! Really great and quick support!

Greetings from Austria,
phix

PS: changed the CAA records to 0 as well :wink:

/edit: Sorry, I would love to mark all your answers as Solution, but only one is possible (I guess you know :wink: ) I marked the one which I assume helps others with the same problem most.
Please no bad feelings @_az - I appreciate your quick response very much

3 Likes
16

Thanks, good to know. So now I know my signature validation works.

Older signatures -> not changed -> validated.

CAA changed, signature not -> signature is invalid.

2 Likes
17

Also the SOA error was due to the serial update and forgotten signing :wink:

Is check-your-website your project? Really cool tool - well done!

2 Likes
18

Yes, it's part of my main job Server-Daten.

Started because of the questions in this forum, needed some time.

Now it saves my time. A lot of configuration errors are visible without checking all these things manual.

3 Likes
19

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