ACME client issues w/Cloudflare

[Patrick M. Hausen]

If its a customer who is complaining, why not just buy a certificate? Getting a wildcard certificate for the domain/s fixes the problem instantly and it doesn't cost much for a business.

Maintenance every year?

[Monviech (Cedrik)]

Maintenance should be a plus if you have customers since you can charge for that. :D

[liceo]

If its a customer who is complaining, why not just buy a certificate? Getting a wildcard certificate for the domain/s fixes the problem instantly and it doesn't cost much for a business.

Agree, but i would like to fix THIS problem. It was working for years now, something seems to be changed.

[Monviech (Cedrik)]

Well did you check if a new TXT record for the ACME challenge is created in the DNS?

If not something might be up with the API key. I think ive read a while ago that cloudflare refuses global API keys that can access all resources, and demand a stricter one now, but unsure.

(Hint: if you think its the api key or some other weird issue, the os-caddy plugin also has cloudflare built in. Just create a domain in it and put the api key into the dns provider, and check the dns-01 challenge. Then check the logfile if it works there. If it does, then you might have some quirks with the acme sh script of the acme plugin in some way.)

[liceo]

I tried with ZoneID Key already, same result. I can't see any TXT records but ACME plugin normally removes it after validation. Maybe im too slow to catch it. I also tried to add the key manually, but on every round ACME generates a new key.

[julsssark]

It sounds like you are using a global API key. See here:

https://developers.cloudflare.com/fundamentals/api/get-started/

Try creating an API token with the correct permissions and use that for the challenge.

[Modaeus]

Not sure if it helps, but noticed a behavior change at some point. If you have a double entry in your cert with the common name present as a SAN name, it will fail at the txt stage the second time it tries to validate.

Had the same issue on a wildcard cert. Solved it by removing the SAN entry.
The SAN value will still be present on the final cert.

[liceo]

Had the same issue on a wildcard cert. Solved it by removing the SAN entry.
The SAN value will still be present on the final cert.

You're right, it has something to do with the SAN. For testing i have removed all SAN and the validadion is working again. But removing the SAN, they are also removed from the certificate of course.

But it's kinda wierd: After removing the SAN equal to the domain it worked again. Now i can add the other SAN (e.g. *.domain.com) again and it still seems to work..

So many thanks for the hint @Modaeus!

[evanfrey]

Sooooo, is this going to be fixed or just ignored?  Just want to sort out my options.  To be clear, this works PERFECTLY in pfsense.