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: appalachian-watchtower.cc
I ran this command: Create certificate (full options) > CSR created by another program > path to private key > path to csr file > single certificate > create verification records in Cloudflare DNS > API token > Windows Certificate Store > Web Hosting > No (additional) store steps > Create or update bindings in IIS > Default Web Site > No (additional) installation steps
It produced this output:
Plugin CSR generated source *.appalachian-watchtower.cc with 1 identifiers
Plugin Single created 1 order
[HTTP] Request completed with status BadRequest
Error requesting certificate Appalachian_Watchtower
My web server is (include version): Local computer
The operating system my web server runs on is (include version): Windows 11
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 don't know
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): Win-ACME 2.2.9.1701
Using the same method I'm using now before, I was able to at least get Let's Encrypt to recognize my DNS-01 challenge attempt and generate a record on Cloudflare. From there, it would generate this message:
I think this was happening because I needed to delete the _acme-challenge TXT record I created while the test was in progress to ensure there was only one, but when I tried to implement that solution today, it didn't even get as far as generating the record. Could this be a rate limit issue? If not, is there anything I can do?
No, not a rate limit issue.
You could add --verbose to your wacs command for more details of the error. The error is from the wacs preliminary validation. It is not a Let's Encrypt error. wacs checks your DNS TXT records before submitting cert request to LE. I don't see anything wrong in your DNS config and Cloudflare usually syncs fairly quick (less than a minute). So, nothing obviously wrong.
It may not help with this specific problem but you should consider changing to simple-acme to replace win-acme. The principal maintainer of win-acme forked win-acme and says this about simple-acme:
"Going forwards, this is the version that I will be supporting and working on. I don’t expect there to be further releases of win-acme, unless ZeroSSL chooses to continue developing that project separately for themselves."
The website for simple-acme is https://simple-acme.com/
4 Likes
I checked --verbose mode and found there was a badCSR error, which I think I corrected by generating a new CSR through OpenSSL commands rather than the IIS Manager. Here's the script I used:
openssl req -new -newkey rsa:2048 -nodes -keyout private.key -out request.csr
After changing this, I was able to generate a certificate in my Web Hosting folder in the Windows Certificate Store. However, based on the output, I am not sure if the DNS-01 challenge actually happened.
1 Like
I wasn't able to find the line "Authorizing using dns-01 validation (Cloudflare)" anywhere in the verbose output, and my DNS records on Cloudflare were not updated, even though I selected Cloudflare as my method for proving ownership of the domain.
(non-verbose output for the test)
Also, does Simple ACME include Cloudflare support by default, or does it require a plugin?
The verbose output was from a test using the Let's Encrypt Staging system. I also do not see the challenge issued. So, you probably had a valid authorization cached in the LE Staging system for that domain and your ACME account. Cache is 30d.
The second part of that test was for the LE production system. Does not use the same cache as LE Staging (but will cache production authorizations).
I see from the public CT log history you got two certificates today from the Staging system and two from production. So, the first from each would have needed to validate but the second would succeed without one because of this cache.
In any case, you have a new production Let's Encrypt cert so all should be well.
You should review the simple-acme website for its requirements. I am not a simple-acme expert. I know that the principal maintainer is no longer working on win-acme and instead working on simple-acme. I also know that simple-acme was forked from win-acme so is likely very much similar architecture.
But, please review it yourself to see if it is suitable. We have seen other cases where simple-acme has fixed problems that people had with win-acme. You are likely to get better support with simple-acme going forward.
2 Likes
Out of interest, why are you generating a CSR?
2 Likes
It requires a plugin, it's virtually the same as win-acme just a different name (with a few extra features and bug fixes).
1 Like
Kind of looks like cloudflare has stale TXT records left over from their own acme challenge given you had multiple returned from the looks of your logs. If they are yours, you can find and delete them from your dashboard but I bet you won't find them. Might try and pull for your domain to validate this.
% dig TXT _acme-challenge.appalachian-watchtower.cc @1.1.1.1
; <<>> DiG 9.11.3-1ubuntu1.19+esm4-Ubuntu <<>> TXT _acme-challenge.appalachian-watchtower.cc @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48253
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_acme-challenge.appalachian-watchtower.cc. IN TXT
;; ANSWER SECTION:
_acme-challenge.appalachian-watchtower.cc. 300 IN TXT "5x9XpCbEL8kCrgcfPXq7sduN01MOLBrr7QXqGjdxM-E"
_acme-challenge.appalachian-watchtower.cc. 300 IN TXT "DNS-01 Challenge #2 (06/18/2025)"
_acme-challenge.appalachian-watchtower.cc. 300 IN TXT "Hlhjtbp0DpQRnUc2Jpm9ag2AeynDku5PjxLHyNvNOlw"
;; Query time: 66 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Jun 20 14:54:19 PDT 2025
;; MSG SIZE rcvd: 227
I have a similar problem that I mentioned with more detail: Discord ... the ticket has been open for 8 days with no reply for a paying customer. Something is still broken from June 12 is my best guess. If those RR records are stale, the values never change and will always be the same and never expire. They are adding them dynamically once you attempt to pull _acme-challenge.... txt RR . You can watch the TTL count down but repeat that dig above every 6 mins and you will always start at 300 for the TTL with the same values.
I am very sure whatever problem you have is not related to this person's problem.
Once they corrected their faulty CSR they successfully passed the DNS Challenge and their wildcard cert was issued.
Yes, it looks like there are some residual TXT records. But, as long as the correct one(s) are in place there can be "wrong" ones.
If the number of TXT records becomes large it can cause an excessively large packet that can result in Let's Encrypt failing a DNS Challenge (see here). But, that isn't what was happening here. And, at one time the Cloudflare panel would not show any TXT records if there was a very large number but I don't know if that issue still exists.
If you are having a Let's Encrypt problem please post a new thread in this forum.
2 Likes
Thank you for confirming that if there are residual/stale TXT records present that LE validation for DNS-01 will cycle through and find the correct one for validation. You solved my problem too! My problem was specific to using a CNAME which was not followed with stale TXT records present so the workaround was to drop that --challenge-alias method from acme.sh and have it write an actual the TXT RR which worked perfectly as you mentioned.
@JDunphy just for confirmation, yes if you have an actual _acme-challenge TXT record in your DNS zone on your primary nameserver (regardless of caching by 3rd party dns services) Let's Encrypt will see that first, over any CNAME with the same name. If you want to use a CNAME for _acme-challenge you need to delete the TXT record with the same name.
Yes - exactly. The good news for me was that if you do force that TXT record, it will remove those stale TXT records also and you can go back to using the CNAME. Then any dig on that RR will now show only the CNAME and NOT those stale TXT records. Thank you everyone - should have come here first.
Note that DNS specs (RFC 1034) say a CNAME must not exist for the same name as a TXT (and most other record types). It sounds like your DNS provider allowed you to set that combination anyway. But, then it ignored the CNAME for queries to that name.
That explains why you saw the CNAME not being followed and why dig did not show it.
You should probably mention this to your DNS provider 
4 Likes
