Records getting mixed up during verification

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: custom-cds.co.uk

I think I am either blind or stupid, something seems to be wrong. I am making a script that creates certs for all of my domains (as of now it doesn't work yet), so I'm making one cert with SANs custom-cds.co.uk and *.custom-cds.co.uk.

I am using DNS verification.

Something seems to be extremely wrong with these challenges:

https://acme-v02.api.letsencrypt.org/acme/chall/2190071165/465895122045/s1C2hQ
https://acme-v02.api.letsencrypt.org/acme/chall/2190071165/465895122055/DUp5IA

One challenge gives token 2fAXtjPKSgfjZpbPxHKlgNb0LTmlpwWjx8UxKY6ic and the other gives 903zdmGv8J1WhnEfEpwjofunQg615WMgnSsDyZlZOIM. Both are complaining that the other one (and 1 more) was found. When I use certbot and set manually, everything is fine. Does anyone know what is going on? I am using GitHub - mholt/acmez: Premier ACME client library for Go for ACME and GitHub - cloudflare/cloudflare-go: The official Go library for the Cloudflare API to set DNS with CF.

Note that I am waiting around 10 minutes after verifying deployment on 8.8.8.8

@martinnaj, welcome to the community! :smile:

Just get the two TXT records installed together in parallel in the DNS at the same time.

1 Like

That's what I was doing the entire time...

Thanks for the welcome btw!!

I attempted to generate one cert, regular, no wildcard, this happened:

{
"type": "dns-01",
"url": "https://acme-v02.api.letsencrypt.org/acme/chall/2190071165/465903589105/oe7OVg",
"status": "invalid",
"validated": "2025-01-25T07:37:26Z",
"error": {
"type": "urn:ietf:params:acme:error:unauthorized",
"detail": "Incorrect TXT record "rXHyA_naOPUO1FPHBsWlTJDh8bNq9LhXBnV-p3tXV0g" found at _acme-challenge.custom-cds.co.uk",
"status": 403
},
"token": "rXHyA_naOPUO1FPHBsWlTJDh8bNq9LhXBnV-p3tXV0g"
}

I suggest you to start over again but scratch all related existing DNS records before doing that:

tumbleweed:~ # dig +short TXT _acme-challenge.custom-cds.co.uk @deb.ns.cloudflare.com.
"SC0C3ufMMgnYTTJaHu6q4g2o6_hStVjSWgqPYa5G9fo"
"rXHyA_naOPUO1FPHBsWlTJDh8bNq9LhXBnV-p3tXV0g"
"uLYboqO65_Ll5nTI0z50jzusj7irEt0AQvRFt3k0dg4"
tumbleweed:~ # 

I do not know, how long the client you are using waits before requesting the ACME server to verify the DNS challenge(s)?
The DNS records must be available on all authoritative DNS servers, before attempting to request the identifier validation.

2 Likes

@lestaff: any idea why Boulder would complain about an incorrect token which, according to the same ACME output, is actually correct? :question:

1 Like

The token value is not meant to be directly used as the DNS record.

See: Urn:ietf:params:acme:error:unauthorized - #5 by stewe

2 Likes

Ah, I thought that was for the http-01 challenge, with the dot in the middle et c. Didn't realise (or remember :roll_eyes:) the TXT value was the SHA256 hash of the keyAuthorization. Thanks!

So I guess this is a bug in the ACME clients implementation of the dns-01 challenge? Although that's weird, because ACMEz from @mholt is a widely used client (probably mostly indirectly by Caddy, but still)?

@martinnaj Can you show us the actual and exact code you're using?

2 Likes

@martinnaj if you use

func (c Challenge) DNS01KeyAuthorization() string

Source: https://pkg.go.dev/github.com/mholt/acmez/v3@v3.0.1/acme#Challenge.DNS01KeyAuthorization

instead of the Token value directly, it should work.

4 Likes