CAA error on domain without CAA records

Help
1

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. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

grotenhuismakelaardij.nl

I ran this command:

/usr/bin/certbot-auto certonly -n --cert-name publish8.publish.realworks.nl --rsa-key-size 4096 --webroot -w /var/www/lets_encrypt -d publish8.publish.realworks.nl -d aanbod.move.nl -d amstelhoven.com -d atrium-makelaardij.nl -d bekkervastgoed.nl -d bmbedrijfsmakelaars.nl -d boogerman.nl -d brandsbedrijfsmakelaardij.nl -d bystabel.nl -d collectiefmakelaars.nl -d dehoekschemakelaar.nl -d demakelaars.nu -d dolphijnmakelaardij.nl -d douwesmakelaardij.nl -d dutchrealestatecompany.com -d groeneraedt.nl -d grotenhuismakelaardij.nl -d hentenaarmakelaardij.nl -d heuvel.nl -d hhmakelaars.nl -d hmgmakelaars.nl -d janusgroep.nl -d karenlehman.nl -d landalmakelaardij.nl -d merwemakelaars.nl -d mijn.zelfmakelaarplus.nl -d panis.nl -d ruseler-haaglanden.nl -d stadhoudermakelaardij.nl -d support.huysshop.nl -d timmermansmakelaardij.nl -d umzeeland.nl -d vanderhelmmakelaardij.nl -d vanderhelmmakelaardij.nl -d vangeffen.nl -d www.amstelhoven.com -d www.angeladenhartog.nl -d www.angeladenhartogmakelaardij.nl -d www.atrium-makelaardij.nl -d www.bbdb-makelaars.nl -d www.bekkervastgoed.nl -d www.bmbedrijfsmakelaars.nl -d www.boogerman.nl -d www.boonstramakelaardij.nl -d www.brandsbedrijfsmakelaardij.nl -d www.bystabel.nl -d www.collectiefmakelaars.nl -d www.dehoekschemakelaar.nl -d www.demakelaars.nu -d www.ditters.nl -d www.dolphijnmakelaardij.nl -d www.douwesmakelaardij.nl -d www.drostedevries.com -d www.dutchrealestatecompany.com -d www.groeneraedt.nl -d www.grotenhuismakelaardij.nl -d www.hentenaarmakelaardij.nl -d www.heuvel.nl -d www.hhmakelaars.nl -d www.hmgmakelaars.nl -d www.janusgroep.nl -d www.karenlehman.nl -d www.landalmakelaardij.nl -d www.lucamakelaardij.nl -d www.marcmerrymakelaardij.nl -d www.merwemakelaars.nl -d www.panis.nl -d www.ruseler-haaglanden.nl -d www.ruseler-rotterdam.nl -d www.stadhoudermakelaardij.nl -d www.timmermansmakelaardij.nl -d www.tomesenmakelaardij.nl -d www.umzeeland.nl -d www.vanderhelmmakelaardij.nl -d www.vangeffen.nl -d www.venk.nl -d www.welpmakelaardij.nl -d www.wgmakelaars.nl -d www.woonschuijt.nl -d www.zeilstramakelaars.nl -d zeilstramakelaars.nl

It produced this output:

Certification Authority Authorization (CAA) records forbid the CA from issuing a certificate :: Error finalizing order :: Rechecking CAA for “grotenhuismakelaardij.nl” and 1 more identifiers failed. Refer to sub-problems for more information

My web server is (include version):

nginx-plus 17-1~stretch

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

Debian 9

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):

/usr/bin/certbot-auto --version
certbot 0.36.0

2

Additional info:

host -t CAA grotenhuismakelaardij.nl
grotenhuismakelaardij.nl has no CAA record

3

This error would happen if one or more of your authoritative nameservers started to return a SERVFAIL or another error for the CAA lookup query. Sometimes this happens with very large orders such as yours when the nameserver can’t handle the volume of requests generated by checking so many domains at once, or if it thinks it is under attack by Let’s Encrypt’s recursive resolver.

What sort of authoritative DNS setup do you use? Do you have any logs that might confirm this?

You might also consider issuing more certificates with less names per certificate. This has advantages above and beyond potentially mitigating this problem for you.

4

Hi @PaulVeldemaRw

checked your domain via Unboundtest (same configuration as the unbound-instance used by Letsencrypt), there is an error:

https://unboundtest.com/m/CAA/grotenhuismakelaardij.nl/5ZX5WGNJ

Response:
;; opcode: QUERY, status: SERVFAIL, id: 61131
Validate: message contains bad rrsets

Jul 26 13:41:42 unbound[14466:0] info: reply from <grotenhuismakelaardij.nl. > 2001:1460:1:0:1c00:6eff:fe00:1d9#53
Jul 26 13:41:42 unbound[14466:0] info: query response was ANSWER
Jul 26 13:41:42 unbound[14466:0] info: validated DNSKEY grotenhuismakelaardij.nl. DNSKEY IN
Jul 26 13:41:42 unbound[14466:0] info: Validate: message contains bad rrsets

Looks like there is a wrong RRSIG.

5

Thanks for the quick responce.

I have given our service department the information to give to the DNS provider.

With Regards
Paul

6

FYI: The problem was solved by the DNS hoster (they did not mention what they did).

The following is an interesting statement:

“You might also consider issuing more certificates with less names per certificate. This has advantages above and beyond potentially mitigating this problem for you.”

We changed the names limit to 50% of what we used to (which was to follow the limit set by letsencrypt in the documentation). This did help mitigating the problem by forcing new names to go into a new certificate and thereby avoiding the problem name.

Just for my and probably others curiosity, can you give a couple of example above and beyond advantages?

With Regards
Paul

7

Glad to hear they were able to find a solution for you. Thanks for reporting back!

Overall I think the argument is one of improved agility. Managing large shared certificates as names come and go (perhaps customers signing up for a service, or leaving it later) is cumbersome.

It's also possible based on the baseline requirements trusted CAs are bound by to have a single owner of a domain used in a shared certificate force the revocation of the entire certificate. Putting many names on one certificate increases the number of names that may be affected by a revocation like that.

Historically the primary advantage of a certificate with many subjects was to avoid needing a dedicated IP address when Server Name Indication (SNI) support wasn't yet prevalent. I don't think this advantage holds much weight in 2019 because the majority of clients support SNI and deprecations of TLS 1.0/1.1 are also helping to accelerate that trend.

Hope that helps! I think there are probably other advantages but those are the one's front of mind.