Multiple Certs with different SANs but redundant DNS verification entries

[bradpcmac]

My domain is: sterlingpsct.gov

I ran this command:

le64.exe --key %key% --csr %csr% --csr-key %csrkey% --crt %crt% --domains "%dom%,www.%dom%" --generate-missing --handle-with %dnsscript% --handle-as dns --export-pfx %pfxpass% --tag-pfx "%pfxtag%" --renew %days% --legacy --live --log-config %logconfig%

This is from a batch script and the variables work. It was simpler to copy & paste this from our main script than to decipher what each variable's value was at the time it runs...but the variables are good. The error happens during the DNS verification steps.

It produced this output:

(this was with the --debug switch)

2025/08/19 15:09:13 [INFO] [ Crypt::LE client v0.39 started. ]
2025/08/19 15:09:13 [INFO] Loading an account key from account.key
2025/08/19 15:09:13 [DEBUG] Account key loaded.
2025/08/19 15:09:13 [INFO] Generating a new CSR for domains sterlingpsct.gov,www.sterlingpsct.gov
2025/08/19 15:09:13 [INFO] New CSR will be based on a generated key
2025/08/19 15:09:14 [DEBUG] CSR generated.
2025/08/19 15:09:14 [INFO] Saving a new CSR into sterlingpsct.gov\sterlingpsct.gov.csr
2025/08/19 15:09:14 [INFO] Saving a new CSR key into sterlingpsct.gov\sterlingpsct.gov_priv.key
2025/08/19 15:09:14 [INFO] Checking certificate for expiration (website connection).
2025/08/19 15:09:14 [INFO] Checking www.sterlingpsct.gov
2025/08/19 15:09:16 [INFO] Expiration threshold set at 30 days, the certificate expires in 11 days - will be renewing.
2025/08/19 15:09:16 [DEBUG] Connecting to https://acme-v02.api.letsencrypt.org/directory
2025/08/19 15:09:16 [DEBUG] Connecting to https://acme-v02.api.letsencrypt.org/acme/new-nonce
2025/08/19 15:09:16 [DEBUG] Directory loaded successfully.
2025/08/19 15:09:16 [INFO] Registering the account key
2025/08/19 15:09:16 [DEBUG] Connecting to https://acme-v02.api.letsencrypt.org/acme/new-acct
2025/08/19 15:09:16 [DEBUG] Key is already registered, reg path: https://acme-v02.api.letsencrypt.org/acme/acct/XXXXXXXX.
2025/08/19 15:09:16 [DEBUG] Connecting to https://acme-v02.api.letsencrypt.org/acme/acct/XXXXXXXX
2025/08/19 15:09:16 [DEBUG] Account ID: XXXXXXXX
2025/08/19 15:09:16 [DEBUG] Registration success: TOS change status - 0, new registration flag - 0.
2025/08/19 15:09:16 [INFO] The key is already registered. ID: XXXXXXXX
2025/08/19 15:09:16 [DEBUG] TOS has NOT been changed, no need to accept again.
2025/08/19 15:09:16 [DEBUG] Connecting to https://acme-v02.api.letsencrypt.org/acme/new-order
2025/08/19 15:09:16 [DEBUG] Connecting to https://acme-v02.api.letsencrypt.org/acme/finalize/XXXXXXXX/419586474717
2025/08/19 15:09:16 [DEBUG] Could not finalize an order.
2025/08/19 15:09:16 [DEBUG] Requesting challenge.
2025/08/19 15:09:16 [DEBUG] Connecting to https://acme-v02.api.letsencrypt.org/acme/authz/XXXXXXXX/563253711601
2025/08/19 15:09:16 [DEBUG] Received challenges for www.sterlingpsct.gov.
2025/08/19 15:09:16 [DEBUG] Requesting challenge.
2025/08/19 15:09:16 [DEBUG] Connecting to https://acme-v02.api.letsencrypt.org/acme/authz/XXXXXXXX/571361572017
2025/08/19 15:09:17 [DEBUG] Received challenges for sterlingpsct.gov.
2025/08/19 15:09:17 [DEBUG] Requested challenges for 2 domain(s).
2025/08/19 15:09:17 [INFO] Processing the 'dns' challenge for 'sterlingpsct.gov' with DNSCS
2025/08/19 15:09:17 [INFO] Waiting 5 sec to help DNS propagation...
2025/08/19 15:09:22 [INFO] Continuing...
2025/08/19 15:09:22 [DEBUG] Domain www.sterlingpsct.gov has been already validated, skipping.
2025/08/19 15:09:22 [DEBUG] Accepted challenges for 1 domain(s).
2025/08/19 15:09:22 [DEBUG] Connecting to https://acme-v02.api.letsencrypt.org/directory
2025/08/19 15:09:22 [DEBUG] Connecting to https://acme-v02.api.letsencrypt.org/acme/new-nonce
2025/08/19 15:09:22 [DEBUG] Directory loaded successfully.
2025/08/19 15:09:22 [DEBUG] Connecting to https://acme-v02.api.letsencrypt.org/acme/chall/XXXXXXXX/571361572017/NI6lTw
2025/08/19 15:09:22 [DEBUG] Connecting to https://acme-v02.api.letsencrypt.org/acme/chall/XXXXXXXX/571361572017/NI6lTw
2025/08/19 15:09:22 [INFO] Processing the 'dns' verification for 'sterlingpsct.gov' with DNSCS
2025/08/19 15:09:22 [DEBUG] Domain sterlingpsct.gov has failed verification (status code 200).
2025/08/19 15:09:22 [DEBUG] Domain www.sterlingpsct.gov has been already verified, skipping.
2025/08/19 15:09:22 [DEBUG] All verifications failed
2025/08/19 15:09:22 [ERROR] All verifications failed

My web server is (include version): IIS 10.0.20348.1

The operating system my web server runs on is (include version): Windows Server 2022 Datacenter Azure Edition

My hosting provider, if applicable, is: Azure VMs

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): No

The version of my client is: Crypt::LE on Windows (le64.exe) version 0.39

The issue we've run into is that this customer of ours has an existing TXT DNS entry for _acme-challenge.sterlingpsct.gov, which is the entry we need to make use of for DNS verification in our system. We get customers to setup CNAME entries that point to a domain we can dynamically update while le64.exe is running for generation/renewal. This system works, so the underlying architecture is good. We do dozens of renewals each week with no problem.

Is there any way to have 2 certs with the same SAN yet use 2 different DNS verification records? I know this is a bit unorthodox and is probably better handled by separating the certs with different sub-domains. Just checking to see what all of our options are.

Thanks!

[griffin]

You can have many TXT records for the same SAN. Just not too many.

[webprofusion]

@bradpcmac

Is there any way to have 2 certs with the same SAN yet use 2 different DNS verification records?

The _acme-challenge record what Let's Encrypt looks at can only have that name, so you can't have 2 records pointing at different CNAMEs and there is no way to tell Let's Encrypt to do it differently etc.

You could CNAME to a record you control, and dynamically CNAME from there to the correct resource, but that super complex. Key thing with DNS challenges is you must allow enough time for ALL of your nameservers to give the same response. That can be 1 minute, 5 minutes 15 minutes or even longer depending on your DNS setup. 5 seconds is generally not enough.

For your example it sounds like HTTP domain validation would be much less complex.

[Edit: one trick/hack is to get certs for the individual names, then immediately request a cert for the combined names. Cached validation with LE means that the order would complete without requiring further challenge completion. It's perhaps a little wasteful of LE resources however.]

[rmbolger]

This is also the primary use-case for the still-in-draft dns-account-01 challenge, right?

The dns-01 challenge specified in section 8.4 of [RFC8555] uses a single DNS authorization label (_acme-challenge) for domain validation. This single-label approach creates a limitation in domain validation: each domain can only delegate its validation to one ACME client at a time. Since delegation requires the use of CNAME records, of which only one can exist per DNS name, operators are forced to choose a single ACME challenge solver for their domain name.

This limitation becomes particularly problematic in modern deployment architectures. In multi-region deployments, separate availability zones serve the same content while avoiding cross-zone dependencies. These zones need to independently obtain and manage certificates for the same domain name. Similarly, during zero-downtime migrations, two different infrastructure setups may coexist for extended periods, with both requiring access to valid certificates. Other use cases include multi-CDN deployments and the provision of backup certificates for use when an active certificate must be quickly revoked.

This document specifies a new challenge type: dns-account-01, which addresses these operational needs. The dns-account-01 challenge incorporates the ACME account URL into the DNS validation record name, allowing multiple independent ACME clients to perform domain validation concurrently. Since these authorization labels depend on the ACME account KID ([RFC8555], Section 7.3), operators can generate and configure the necessary DNS records in advance.