CAA record prevents issuance

un99known99 · November 1, 2024, 4:41pm

shouldnt it be issuewild instead of issue? I need the cert for miharu.dedyn.io and *.miharu.dedyn.io?

un99known99 · November 1, 2024, 4:42pm

yes absolutely fine for me, many thanks for your efforts here....

MikeMcQ · November 1, 2024, 4:43pm

No, actually the other way around. The --dry-run would have failed if "issue" was wrong.

An "issue" allows discrete names and wildcard names. An "issuewild" is only for wildcard.

Osiris · November 1, 2024, 4:48pm

But, according to the RFC, wouldn't prevent issuing a non-wildcard hostname.

un99known99 · November 1, 2024, 4:48pm

will wait then on instructions from your side, maybe I can support then in testing your solution. Crazy, it seemed working as a cert has been issued this morning

Osiris · November 1, 2024, 4:50pm

As far as I can tell, your CAA RRs are fine as they are now. I believe that's also what Mike meant.

un99known99 · November 1, 2024, 4:51pm

thanks, maybe I re-check by reducing the renewal period, just for my sake

MikeMcQ · November 1, 2024, 5:23pm

I think you probably got the production cert today from a test earlier in this thread.

It is good for 90 more days so there is time to get the final answer

Bruce5051 · November 1, 2024, 5:25pm

I believe @un99known99 you successfully been issued a certificate.
Here is a list of issued certificates crt.sh | miharu.dedyn.io, the latest being 2024-11-01,
and that certificate is crt.sh | 15173277262

MikeMcQ · November 1, 2024, 5:27pm

Yeah I saw you say that. I didn't read them myself. I was trying to simplify for them since they had the general understanding wrong.

I think you may be right that there may be some LE errata here with issuewild. We can check that offline easier. I'll do it myself unless someone beats me to it. I probably won't have time immediately to do that. But, it won't be hard to check variations once I do.

Osiris · November 1, 2024, 5:28pm

I ignored the whole accounturi thingy as I assumed that would be correct. So maybe LE does everything correctly, I dunno, should check indeed.

Also, RFCs are one thing, the baseline requirements are holy, so gotta check that one too

Bruce5051 · November 1, 2024, 5:42pm

From here RFC 8659 - DNS Certification Authority Authorization (CAA) Resource Record

An Issuer MAY choose to specify parameters that further constrain the issue of certificates by that Issuer -- for example, specifying that certificates are to be subject to specific validation policies, billed to certain accounts, or issued under specific trust anchors.For example, if ca1.example.net has requested that its customer account.example.com specify their account number "230123" in each of the customer's CAA records using the (CA-defined) "account" parameter, it would look like this:

account.example.com CAA 0 issue "ca1.example.net; account=230123"

The semantics of parameters to the issue Property Tag are determined by the Issuer alone.

Bruce5051 · November 1, 2024, 7:15pm

I am posting this to help others in the future.

More restrictive CAA record fields demonstration
for both Let's Encrypt production and staging environments.

This is for the DNS-01 challenge of the Challenge Types - Let's Encrypt

I am demonstration with a test domain of mine and Certbot Instructions | Certbot
I had a propagation issue with the default of 80 second so I change to 300 seconds with this option added to the certbot command line --dns-desec-propagation-seconds=300

$ nslookup -q=caa fivvy.us.eu.org ns1.desec.io.
;; Truncated, retrying in TCP mode.
Server:         ns1.desec.io.
Address:        45.54.76.1#53

fivvy.us.eu.org rdata_257 = 128 issue "letsencrypt.org;validationmethods=dns-01;accounturi=https://acme-staging-v02.api.letsencrypt.org/acme/acct/130474314"
fivvy.us.eu.org rdata_257 = 128 issue "letsencrypt.org;validationmethods=dns-01;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1483983656"
fivvy.us.eu.org rdata_257 = 128 issuewild "letsencrypt.org;validationmethods=dns-01;accounturi=https://acme-staging-v02.api.letsencrypt.org/acme/acct/130474314"
fivvy.us.eu.org rdata_257 = 128 issuewild "letsencrypt.org;validationmethods=dns-01;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1483983656"

$ nslookup -q=caa fivvy.us.eu.org ns2.desec.org.
;; Truncated, retrying in TCP mode.
Server:         ns2.desec.org.
Address:        157.53.224.1#53

fivvy.us.eu.org rdata_257 = 128 issue "letsencrypt.org;validationmethods=dns-01;accounturi=https://acme-staging-v02.api.letsencrypt.org/acme/acct/130474314"
fivvy.us.eu.org rdata_257 = 128 issue "letsencrypt.org;validationmethods=dns-01;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1483983656"
fivvy.us.eu.org rdata_257 = 128 issuewild "letsencrypt.org;validationmethods=dns-01;accounturi=https://acme-staging-v02.api.letsencrypt.org/acme/acct/130474314"
fivvy.us.eu.org rdata_257 = 128 issuewild "letsencrypt.org;validationmethods=dns-01;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1483983656"

$ sudo certbot show_account
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Account details for server https://acme-v02.api.letsencrypt.org/directory:
  Account URL: https://acme-v02.api.letsencrypt.org/acme/acct/1483983656
  Account Thumbprint: QX3VW-VjJ6ZlVTPv9Mm6QR6zMQW8U1pGGXPI0CP4psI
  Email contact: bam@figment.biz

$ sudo certbot show_account --staging
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Account details for server https://acme-staging-v02.api.letsencrypt.org/directory:
  Account URL: https://acme-staging-v02.api.letsencrypt.org/acme/acct/130474314
  Account Thumbprint: kHnkBT36Jx_qD9cOeAg1Bs-7pMT4UC8DNzoY6moVaCk
  Email contact: none

$ sudo certbot renew --dry-run --renew-by-default -v --dns-desec-propagation-seconds=300
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/fivvy.us.eu.org.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Plugins selected: Authenticator dns-desec, Installer None
Simulating renewal of an existing certificate for fivvy.us.eu.org and *.fivvy.us.eu.org
Performing the following challenges:
dns-01 challenge for fivvy.us.eu.org
dns-01 challenge for fivvy.us.eu.org
Waiting 300 seconds for DNS changes to propagate
Waiting for verification...
Cleaning up challenges

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/fivvy.us.eu.org/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

$ sudo certbot renew --renew-by-default -v --dns-desec-propagation-seconds=300
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/fivvy.us.eu.org.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Plugins selected: Authenticator dns-desec, Installer None
Renewing an existing certificate for fivvy.us.eu.org and *.fivvy.us.eu.org

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all renewals succeeded:
  /etc/letsencrypt/live/fivvy.us.eu.org/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

$ sudo certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: fivvy.us.eu.org
    Serial Number: 4cc83e3d16d09496a1e1fb99732673fe632
    Key Type: ECDSA
    Domains: fivvy.us.eu.org *.fivvy.us.eu.org
    Expiry Date: 2025-01-30 17:42:41+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/fivvy.us.eu.org/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/fivvy.us.eu.org/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

$ sudo certbot --version
certbot 2.11.0

un99known99 · November 2, 2024, 7:02am

Infact I did a re-testing, thanks @Bruce5051 I used your proposal as my new setup and forced certbot to update. Setup looks now:

miharu.dedyn.io rdata_257 = 128 issue "letsencrypt.org;validationmethods=dns-01;accounturi=https://acme-staging-v02.api.letsencrypt.org/acme/acct/20150032"
miharu.dedyn.io rdata_257 = 128 issue "letsencrypt.org;validationmethods=dns-01;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/125274239"
miharu.dedyn.io rdata_257 = 128 issuewild "letsencrypt.org;validationmethods=dns-01;accounturi=https://acme-staging-v02.api.letsencrypt.org/acme/acct/20150032"
miharu.dedyn.io rdata_257 = 128 issuewild "letsencrypt.org;validationmethods=dns-01;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/125274239"

all went fine with the new renewal, for now I left also the 80s propagation time

So seems to be a combination / mixture of 2:

one seems to be the wrong staging setup as @MikeMcQ mentioned
second seems to be some changes on LE side as far as I understood @MikeMcQ

so will looking forward what the outcome might be here - many thanks for all in helping out here

MikeMcQ · November 3, 2024, 3:53am

Well, it is good news for Let's Encrypt since my tests have CAA behaving as expected. My guess as to what happened in your case is at the end.

I tried exactly your test case and it succeeded. Bruce's example showed that CAA accounturi could work. My test tried to reproduce your failure in case LE had a quirk.

DNS test1:
sub.example.com CAA 128 issuewild "Xletsencrypt.org;accounturi=(uri)"
Used Certbot to request cert for: *.sub.example.com sub.example.com
Failed to issue, as expected, due to wrong CA value
Error message was CAA record for sub.example.com prevents issuance
(test was to prove CAA was properly seen in DNS)

DNS test2:
sub.example.com CAA 128 issuewild "letsencrypt.org;accounturi=(uri)"
Used Certbot to request cert for: *.sub.example.com sub.example.com
Success. Issued cert that includes both names

Note issuewild only restricts wildcard domain names, not wildcard certs. Having only issuewild still allows certs with all non-wildcard domain names in it. I'm sure there are times this makes sense but I wanted to highlight this.

In your case having just those two issue records does everything you need. You do not even need the issuewild since they have the identical restrictions. You only need issuewild if you want unique criteria for wildcard domain names in the cert.

My guess as to what happened to bring you here ... I think something went wrong with a renewal but not related to CAA. Perhaps LE had a brief outage, a temp comms problem, or such. Then, you tried using --dry-run to evaluate and started getting the CAA restriction errors. These were correct though since you only had your production account in the CAA accounturi.

I reviewed the entire thread and did not see any failure that also showed using your production account. Each test shown was either incomplete or showed --dry-run.

You could review all your past logs in /var/log/letsencrypt and see if you could find the original CAA restriction failure using production. Alas, we won't be able to verify what the CAA record looked like at that moment so would be hard to confirm anyway.

Hope this helps.

Bruce5051 · November 3, 2024, 4:53pm

Thanks Mike for your in-depth investigation and effort, much appreciated!

un99known99 · November 3, 2024, 5:42pm

Hi Mike,

thanks for the profound analysis. I took a look at the old logs - and - true, it shows that it tried to check the staging - for my productive renewal:

{
497 "identifier": {
498 "type": "dns",
499 "value": "miharu.dedyn.io"
500 },
501 "status": "invalid",
502 "expires": "2024-11-08T07:08:54Z",
503 "challenges": [
504 {
505 "type": "dns-01",
506 "url": "https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/ID/ID",
507 "status": "invalid",
508 "validated": "2024-11-01T07:10:17Z",
509 "error": {
510 "type": "urn:ietf:params:acme:error:unauthorized",
511 "detail": "Incorrect TXT record "" found at _acme-challenge.miharu.dedyn.io",
512 "status": 403
513 },
514 "token": "tokenID"
515 }
516 ],
517 "wildcard": true

Questions:

Why did the renew succeed despite the auth error shown above ???
According to your findings I set the CAA records for my "*.domain" and "domain" records now to

I guess I should be fine now?

Thanks

MikeMcQ · November 3, 2024, 5:49pm

Not sure which "renew" you are talking about. One of your tests earlier in this thread worked. Not sure if that was production or not: CAA record prevents issuance - #17 by un99known99

Yes, I think so. Cheers

un99known99 · November 3, 2024, 5:50pm

Many thanks Mike!

system · December 3, 2024, 5:50pm

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

Topic		Replies	Views
Absent CAA Record preventing issuance Help	4	2501	February 3, 2019
CAA record prevents issuance Help	3	5650	January 17, 2019
Renewal failures - "CAA prevents issuance" with unchanged CAA Help	7	1104	June 30, 2023
CAA record issue while renewing Help	7	926	May 20, 2020
CAA record preventing issuance since Friday 26th but nothing has obviously changed Help	5	534	June 29, 2023

CAA record prevents issuance

Related topics