Requesting a certificate for a subdomain fails since it doesn't have CAA record


#1

If I request a certificate for a subdomain, and subdomain doesn’t have a CAA record, but the second-level domain does, I get an error stating that the domain doesn’t have a CAA record. I don’t think should be the case, since CAA records apply to subdomains. Is this an error in boulder implementation, or is this not a case and CAA records should be specified for every subdomain?


#3

What, exactly, does the error say? Because not having a CAA record is not an error condition. However, if your DNS host responds with an error when queried, that is an error condition.


#4

Hi @anon51109878

we need your domain name to check that.


#5

As a domain’s CAA inherited to subdomain unless overided, if main domain’s CAA record doesn’t include LE as allowed then the the cert request for subdomain will be denied.


#6

Please show the full error message to better understand the problem.


#7

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:

I ran this command:

It produced this output:

My web server is (include version):

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

My hosting provider, if applicable, is:

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

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

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


#10

The error isn’t saying that you don’t have a CAA record, it’s saying that there’s a DNS resolution problem.

https://unboundtest.com/m/CAA/znc.tachibana.industries/DEKLJQ7Q

It’s some sort of DNSSEC problem, but I’m not sure what.

You do have an NSEC record saying no subdomains at all exist, which is a catastrophic problem, but it doesn’t look invalid to me.

tachibana.industries.   300     IN      SOA     ns1.vultr.com. dnsadm.choopa.com. 1550298527 10800 3600 604800 3600
tachibana.industries.   300     IN      RRSIG   SOA 13 2 300 20190228000000 20190207000000 34481 tachibana.industries. keJRl/4azqADVS+AAKGwYE8VfbB02G3fVBJBsCeRvWVGRUuTBW1RD/b5 rOIxvb6T17qIXy99zNNYjPEfrJx4HQ==
tachibana.industries.   3600    IN      NSEC    tachibana.industries. NS SOA RRSIG NSEC DNSKEY CAA
tachibana.industries.   3600    IN      RRSIG   NSEC 13 2 3600 20190228000000 20190207000000 34481 tachibana.industries. k4WUdQlZ8V965kyXXHNxMVBcXex+jL7+osxFudYTitNYbRy75YmUCqZZ kpmgq9POpNxBnwT61QxprmZCd+xBng==

You – or the nameserver administrators – need to run “sudo pdnsutil rectify-zone tachibana.industries” on the authoritative nameserver(s) and ensure that the zones are properly rectified after record changes in the future.

There’s a good chance that will fix whatever problem is making negative responses invalid.

Edit: Maybe resolvers are simply unhappy because it’s a NOERROR status code and an NXDOMAIN answer?


#12

Not a good sign, since they’re using Vultr’s managed DNS.

I wonder if @anon51109878 might have better luck by disabling and re-keying their DNSSEC.


#13

If you don’t have low-level access to the DNS servers – via the command line or API or a control panel – you need to contact Vultr and get them to fix it.

In the meantime, you can disable DNSSEC and/or switch DNS providers, I guess.

Edit: You’re not running a hidden primary nameserver, are you? I don’t think Vultr’s managed DNS supports that.


#15

In short, allows server admin the full control the primary name server [which is not seen from Internet, nor known to the Internet].
What the internet sees are just authoritative secondaries of that [hidden] primary.


#17

Then the Internet seen nameservers are the only nameservers for that zone.
[and the only place to make any required changes]


#18

It seems to be different/fixed for me.

Moved onto different issues about the firewalling of your server.

What did you do?


#21

Your webserver, yeah - https://letsdebug.net/znc.tachibana.industries/23633

But depends whether you intend to use DNS-01 or HTTP-01 challenge, of course.


#23

DNSviz sometimes sees UDP problems with the IPv6 IPs of Vultr nameservers:
http://dnsviz.net/d/znc.tachibana.industries/dnssec/

…and sometimes it all looks OK…

[not enough eggs nor baskets]


#26

Some people say, and many have heard, “never put all your eggs in one basket”.
If you understand that saying, then you should understand what I meant.
For those who don’t, I will try to explain both.
This expression generally refers to a “single-point-of-failure” with a very large impact scope.
[should something bad “happen” to that one basket, your may lose all your eggs]

The “not enough eggs nor baskets” was meant to infer that there is a very big “single-point-of-failure” in this design and attempted to analogize it with “having only one egg and only one basket”.
[The one DNS IP (being the single egg) and only one DNS provider (being the single basket)]

Given that:
When you only have one egg, it must go in only one basket (less you should break it!).
And that:
When you only have one basket, then all your eggs must go to that single basket.

Both of those cases are bad:

  1. Only one egg & only one basket
  2. More than one egg; But all in the same basket

But the first is clearly even worse than the second.
Where the second is already a well-known example of a very bad case scenario; as told and retold by many (“never put all your eggs in one basket”).
[where the second case could survive and overcome losing one egg, the first case would fail on any loss]

I saw this case just as that first one (with: just one egg and one basket).
And thus explains the footer message line: [not enough eggs nor baskets]

[more than two hundred words used to explain five words]
[and much like the comedian who has to “explain the joke”… this will (no doubt) fail to “get a laugh”]
[don’t ask me to explain any of that too - LOL]


Another CAA record failure issue
closed #28

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