HTTP-01 validation fails: no valid A/AAAA records found for domain

Hello,

We are using our own server-side implementation for requesting Lets Encrypt certificates.
For the past few years we only supported DNS-01 validation, which worked pretty fine.

Since May this year, we also started supporting HTTP-01 validation for our customers, because our clients are mostly using our webhosting. This makes it easier and faster to complete a Lets Encrypt request and installation.

However, we are experiencing some issues. These are the steps (process flow) we take:

  • Request new order for main domain and www. domain (altnames)
  • Set acme token on webserver document-root for this domain
  • Resolve token locally and validate
  • Request finalize challenge for HTTP-01 at Lets Encrypt (this is AFTER we've successfully validated HTTP-01 on our side)

Mostly, for non-www altNames, this will succeed immediately. The Lets Encrypt response after resolving the authorization (after finalizing) will be "valid".

However..., we are having trouble with www. altNames. The authorization response after finalizing the www. challenge is "invalid", and we cannot pinpoint the root cause of this...

Full challenge response:

"challenges": [
    {
      "type": "http-01",
      "status": "invalid",
      "error": {
        "type": "urn:ietf:params:acme:error:dns",
        "detail": "During secondary validation: no valid A records found for www.**domain**.nl; no valid AAAA records found for www.**domain**.nl",
        "status": 400
      },

This is strange, because all our domains within our DNS are using wildcard records for both A and AAAA. Besides that, when looking up the A and AAAA records manually for these domains using DIG+, the correct ip address is resolved.

I dont know what we are doing wrong in this case. Some help will be much appreciated!

You could try using unboundtest.com to see if it shows any problems. It uses similar method for DNS lookup as the Let's Encrypt servers.

You could also try dnsviz.net which often highlights issues that can lead to subtle problems.

These are two tools commonly used on the forum to debug DNS issues.

Oh, and welcome to the community @ramon024

8 Likes

This message indicates that some of the servers that Let's Encrypt checks from worked, but some other servers in other locations did not. Probably the first step is to double check that before you request Let's Encrypt to check the challenges, that you've confirmed that all of your authoritative DNS servers for the domain are responding the same way with the right IP.

9 Likes

Neither can we; Since you insist on hiding the domain.

No; You are clearly having DNS trouble.

8 Likes

Thank you all for the replies.

The reason im hiding the domain is because this problem exists for multiple domains not validating.
Two of them that had this issue today:

  • www.vincentdonders.nl
  • www.thijsenspeelt.nl

Yea, i did not stated that entirely correctly. I was meant to say that this problem only occurs for www. alt-names, and not for the main domains.

When checking both the DNS records for these domains, the A and AAAA records both resolve to the correct ip-address on all our authoritive nameservers.

This is where i get lost honestly. Because we retry the HTTP-01 method another time before switching to DNS-01. So whenever the HTTP-01 validation fails at Lets Encrypt (after it successfully resolved locally), we create a new order and retry the same proces. The second time, there are many domains that will get validated now.

Also, not all domains are experiencing this issue. It's mostly a certain percentage of all renewals we are doing. So yea, it might be some DNS issue we are experiencing.

Ah, and the message: During secondary validation: is mostly not even in the error. Many times its the same error, but without During secondary validation:

2 Likes

How many FQDNs renewals are being bundled together?

3 Likes

Let's Encrypt makes a bunch of DNS requests all at once, from around the world. Might there be some "smart" firewall in front of your DNS server interpreting it as an attack and blocking some of the connections? It wouldn't be the first time something like that had happened.

5 Likes

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