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. crt.sh | 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:
*.summers.k12.wv.us
I ran this command: renew existing cert using DNS and a manual auth hook bash script
It produced this output:
Detail: During secondary validation: While processing CAA for *.summers.k12.wv.us: CAA record for k12.wv.us prevents issuance
My web server is (include version):
N/A
The operating system my web server runs on is (include version):
N/A
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):
N/A
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
1.11.0
I have a RedHat v7 server that we use as a central LE control point, interfacing with our DNS server as well as our F5 load balancer, and various other RedHat servers .. it has bash scripts to insert dns records for things like wildcard validation and has been working pretty good for about 100 certs for several years. Soon we will upgrade that server to RedHat 9 and then can migrate to a newer release of certbot, if certbot is my issue.
the other day I was experimenting with a new/optional CAA tag
contactemail
and created this CAA record in DNS:
k12.wv.us 3600 IN CAA 0 contactemail "mailto:verne-caa-k12@wvnet.edu"
which HOST and DIG display just fine
I submit to you that since my CAA record does not have the tag "issue" that LE should ignore it, instead it appears LE feels, from the error in letsencrypt.log
Domain: summers.k12.wv.us
Type: caa
Detail: During secondary validation: While processing CAA for *.summers.k12.wv.us: CAA record for k12.wv.us prevents issuance
that my CAA record does not permit LE to issue certs
as this is a test of the new optional CAA tag contactemail what I will end up doing in a week or so, is deleting that CAA record so I can renew the LE cert
but at the moment I wanted to leave that record in DNS in case anyone wanted to examine it.
Yes, this is explicitly stated by RFC 8659, "If the Relevant RRset for an FQDN or Wildcard Domain Name contains no Property Tags that restrict issuance (for instance, if it contains only iodef Property Tags or only Property Tags unrecognized by the CA), CAA does not restrict issuance."
From a quick skimming through the source, I think they handle this right for non-wildcard names, but for wildcards I don't think there's a similar check and it is trying to find their name in the provided records even though it isn't there.
@aarongable@mcpherrinm (Sorry, to call you guys out specifically, but it looks like we don't have permissions to mention @lestaff anymore for escalations): This looks to be a bug in Boulder's CAA logic to me. (Albeit one that stops issuance that should be allowed, rather than the other way around which would be much more concerning.)
This behavior is expected. (Maybe it isn't. See the preceding comment by @petercooperjr.) When you had no CAA records, you were fine not having one that allowed Let's Encrypt to issue certificates. Once you aded a CAA record that doesn't explicitly allow issuance by any CAs, you created a policy that doesn't permit Let's Encrypt certificate issuance.
Also relevant, but of minor significance, I hope that you mean RHEL where you wrote RedHat. RedHat 7 and RedHat 9 were released in 2000 and 2003, respectively. RHEL != RedHat
At first glance, it looks like you've found a real bug, and I think @petercooperjr's analysis is correct. But that's just me looking from my phone; give me a bit and I'll actually dig in and run some tests. Thanks for bringing this to our attention and I'll let you know what I find!
I did some investigation of my own, and put the results in this bug. I've developed a regression test and a fix for this behavior in this PR. It'll take a bit to get that reviewed, merged, and deployed, but you should be able to see this fully fixed in a week or two.
Thanks again for bringing this to our attention! As a note to both verne-work and petercooperjr, whenever you have something that you truly believe is a real bug, you're always welcome to file it as an issue in the boulder repo, which is generally our preferred method for receiving reports like this. It fits better with our triage and awareness patterns.
