Domain not validating even after correct TXT record is setup

Help
1

Domain/SAN: bankaudipb.com

Issue:
Domain validations from Lets Encrypt are failing and therefore certificate is not being issued.

To validate the domain, the following DNS TXT record was asked to be configured in the Akamai portal.

image
image2263×687 67.2 KB

When doing a DNS lookup, we see the correct TXT record is configured on both authoritative nameservers.

dig TXT _acme-challenge.bankaudipb.com @sf.idm.net.lb.

; <<>> DiG 9.16.48-Ubuntu <<>> TXT _acme-challenge.bankaudipb.com @sf.idm.net.lb.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22312
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_acme-challenge.bankaudipb.com. IN TXT

;; ANSWER SECTION:
_acme-challenge.bankaudipb.com. 60 IN TXT "509QyQVojOJeVnv4r14ExRnvsmv7BthcMZeIZZz0gMs"

;; AUTHORITY SECTION:
bankaudipb.com. 3600 IN NS sf.idm.net.lb.
bankaudipb.com. 3600 IN NS ns0.idm.net.lb.

;; ADDITIONAL SECTION:
sf.idm.net.lb. 3600 IN A 174.142.61.239
ns0.idm.net.lb. 3600 IN A 194.126.10.18

;; Query time: 12 msec
;; SERVER: 174.142.61.239#53(174.142.61.239)
;; WHEN: Tue Jun 25 00:00:22 UTC 2024
;; MSG SIZE rcvd: 192

dig TXT _acme-challenge.bankaudipb.com @ns0.idm.net.lb.

; <<>> DiG 9.16.48-Ubuntu <<>> TXT _acme-challenge.bankaudipb.com @ns0.idm.net.lb.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43935
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: d2bdb4e3faafbf1d01000000667a089d89d70014b5c2cae0 (good)
;; QUESTION SECTION:
;_acme-challenge.bankaudipb.com. IN TXT

;; ANSWER SECTION:
_acme-challenge.bankaudipb.com. 60 IN TXT "509QyQVojOJeVnv4r14ExRnvsmv7BthcMZeIZZz0gMs"

;; Query time: 134 msec
;; SERVER: 194.126.10.18#53(194.126.10.18)
;; WHEN: Tue Jun 25 00:00:29 UTC 2024
;; MSG SIZE rcvd: 143

However the logs show that Lets Encrypt is finding additional & incorrect TXT records elsewhere and that's why domain is not getting validated.

Report Error: bankaudipb.com: Incorrect TXT record "piTue6iVPXdA5E1lYxcKlbhoBnFiJeIl8jWkpp1Cpxo" (and 1 more) found at _acme-challenge.bankaudipb.com

Report Error: bankaudipb.com: Incorrect TXT record "bMha7VGQIvjhVp1WEralzL3D9M0FROReGT_POJdqu5U" (and 2 more) found at _acme-challenge.bankaudipb.com

Ask:
From where is Lets Encrypt getting these incorrect TXT record? Can we get some kind of DNS lookup result showing that the authoritative nameservers are providing an incorrect TXT record?

2

Welcome @anoop.kulkarni66

The https://unboundtest.com site chases the auth DNS server tree and shows the results similar to how LE does it.

But, each new cert request will have a new TXT value. It is not a one-time set value. Are you updating the TXT value for each request?

Can you explain more about the ACME Client you use to request the cert? And, how that places the TXT record? Because usually that is done with an API to the auth DNS servers so cert renewals can be automated.

4 Likes
3

Thanks for your response.

  1. Yes I tested on unboundtest.com as well before creating this topic and I saw the correct DNS TXT record setup.
    https://unboundtest.com/m/TXT/_acme-challenge.bankaudipb.com/R3OKD5EF

  2. Yes everytime the DNS Token changes, a new TXT record is setup. If you look at my screenshot, the token was generated on June 24th, 2024 at 10:51 GMT. Looks like a new certificate request was created by the domain owner a short while ago and so the current token is different, which has not been setup on the authoritative DNS servers yet. The validation challenges are obtained from Lets Encrypt and populated in the Akamai portal. Every time there is a new cert request, a new challenge is generated, Akamai portal updates the tokens in its portal.

  3. The client in this case is Akamai Certificate Provisioning System (CPS). The CSR is generated from the Akamai's CPS and sent to Lets Encrypt. Lets Encrypt then responds with the necessary domain challenges which the domain owner needs to setup. In this case, we see the domain challenge was setup correctly, but the logs on Akamai side report that Lets Encrypt was getting multiple incorrect TXT records from the authoritative nameservers and therefore Let's Encrypt fails to validate the domain.

As of now, looks like the domain owner needs to setup the new TXT record on the authoritative nameservers. So once that is done, I will respond back if the domain validation goes through or not.

1 Like
4

Multiple TXT record values are allowed. As long as one of them matches what the Let's Encrypt Server expects to see the validation succeeds.

For example, it is common to have 2 values outstanding on the same DNS record name for wildcard certs. We sometimes see a large number of records when people delegate responsibility of the _acme-challenge record via CNAME as another example.

So, if the validation is failing it means the expected value is not found in the list of values present. There is a limit to how many TXT record values can exist. I am not sure of the current limit but it is far more than 2 or 3 (at least 20 and maybe as many as 60-80).

Are you sure the log is showing the response from the Let's Encrypt Server? Could it be that CPS is doing a pre-check and failing and showing its own failure? Is there a way to add a delay in CPS after it places the TXT record and when it sends the subsequent request to LE? Some DNS systems take awhile to sync between themselves and often delays are needed.

2 Likes
5

Supplemental the presently being served certificates are for the apex domain of bankaudi.com.lb as shown here Hardenize Report: bankaudipb.com

6

The cert was issued after a new certificate request was generated. So its not entirely clear what was causing the cert to be not issued earlier. Anyway, thanks for all the help. I am closing the topic as the issue is now resolved.

2 Likes
7

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