The ca server validates my domain through ipv6, but my server only listens at ipv4

Server
1

How does the ipv6 support of the CA server work?

My server has both ipv4 and ipv6 enabled.

My client only listens at ipv4, sometimes, the Letsencrypt CA server is only able to resolve my ipv6 address, and connect to my ipv6 address to validate my domain. I got such error message:

{
  "type": "tls-sni-01",
  "status": "invalid",
  "error": {
    "type": "urn:acme:error:connection",
    "detail": "Failed to connect to [2607:xxxxx:xxxx:xxxx::1]:443 for TLS-SNI-01 challenge",
    "status": 400
  },
  "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/bbtWs_TDSNIlLJmRwle1BhcHE4let5Cfpf_snhNWI9Q/16278271",
  "token": "rBsjGPhW54ddlqkUgkbMZZ288e7bygmxpPzaT78OIdg",
  "keyAuthorization": "rBsjGPhW54ddlqkUgkbMZZ288e7bygmxpPzaT78OIdg.bUg9P6PAyURnYM3tuIQzYIIs1cRkw8RO-gTFX0lUXTY",
  "validationRecord": [
    {
      "hostname": "xxxxxx.xxxxxx.xxxxxx",
      "port": "443",
      "addressesResolved": [
        "2607:xxxx:xxxx:xxxx::1"
      ],
      "addressUsed": "2607:xxxxx:xxx:xxx::1"
    }
  ]
}

Please take a look at the addressesResolved field above. Only my ipv6 address is there.

The error only happens at very little chance. most of the time, it works well with my ipv4.

This is a working case:

{
  "type": "tls-sni-01",
  "status": "valid",
  "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/B97f6loM6NRFpmMJsygziFZx_tZ6-XfT1ocravZEeGI/16278267",
  "token": "QIfva0mzWqBSBucd3eeNwV8x-yi3zKP_CfwKJeTfZa0",
  "keyAuthorization": "QIfva0mzWqBSBucd3eeNwV8x-yi3zKP_CfwKJeTfZa0.bUg9P6PAyURnYM3tuIQzYIIs1cRkw8RO-gTFX0lUXTY",
  "validationRecord": [
    {
      "hostname": "xxxxxx.xxxxxx.xxxxxx",
      "port": "443",
      "addressesResolved": [
        "198.xxx.xxx.xxx",
        "2607:xxx:xxx:xxx::1"
      ],
      "addressUsed": "198.xxx.xxx.xxx"
    }
  ]
}

How does the CA server determine whether to use ipv4 or ipv6 address to validate the domain ?

2

BTW, my domain NS server is using cloudflare

3

Hi Neil,

How is the CA supposed to know that your domain only listens on ipv4 if it gives out an ipv6 AAAA record ?

Personally I’d remove the ipv6 AAAA record if you aren’t listening on it.

2 Likes
4

@serverco

You don’t read my question:

Please take a look at the addressesResolved field above. Only my ipv6 address is there.
5

If I do a lookup of your domain though, and ask your authoritative nameservers for your IP, I get your IPv6 IP address as a preferred location. My test was to do that on your domain name ( which I got from the above links), hence I’m not sure what you expect the CA should do in that case ?

To me it’s no different to if you had a round-robin type DNS setup. If LE gets an error / fail on the first IP, would you expect it to say “the domain failed the challenge” or “it failed, let me ask for a different IP and try again?”

Edit: to make my answer clearer. When I asked your authoritative nameservers for the IP address for your domain, I only got an IPv6 IP address. I was asking from an IPv6 enabled machine.

6

@serverco

There are a few questions:

  1. why are there both my ipv4 and ipv6 addresses in the "addressesResolved" filed, and why is there only ipv6 address in it for some time ?
    Does that mean there is something wrong with the CA server for resolving my domain ?
    How the ca resolves my domain ?

  2. If my certificate-issue request comes from a ipv4 network, why the CA use ipv6 ip address to validate my domain ? Is that reasonable?

Even if my domain resolves to both ipv4 and ipv6, the ipv4 address and ipv6 address may be on 2 different servers.

It doesn't make any sense for the CA to confuse ipv4 and ipv6 address.

Understand ?

My last question is:

How does the CA server determine whether to use ipv4 or ipv6 address to validate the domain ?

7

I'm not part of let's Encrypt - so I can't answer your question "How does the CA server determine whether to use ipv4 or ipv6 address to validate the domain ?"

I didn't do lots of tests, my first one only provided your IPv6 address though, so I'd guess it's worth checking with your NS's.

Personally I don't think there should be any connection between whether the client is on an IPv6 network and what network the domain is on. I often run a client in an IPv6 network but want to issue obtain certs for clients on IPv4 only, and that would be awkward if I had to change network settings just to obtain a cert.

To me I think if you advertise an IPv6 address for the domain, then you should really have the domain on that IP address, because it will affect many other users, not just the issuing of a cert.

They could be, yes. If you host the domain on multiple servers ( for whatever reason, load balancing, geographic sites ... ) then you need to provide the validation method at all of them, as there is no way of determining in advance which server the CA will reach. Personally I use the dns method for those situations, which overcomes that issue.

8

@serverco

We’d better leave the question to letsencrypt official guys.

Thanks.

9

IPv6 is tried first because it’s supposed to be (According to RFC 6724), and since DNS queries are separate (You can’t request both a v4 and v6 address, only one or the other per query) then it’s possible that sometimes the A request is timing out and LE is using the AAAA result (And vice versa, or sometimes they both pass, etc.)

The root problem though is that you’re announcing an address you aren’t listening to, that will lead to issues (Which all get resolved differently) when clients actually try to use the address. The only reason it’s not very visible is that clients try their hardest to work around this kind of broken configuration (It’s called Happy Eyeballs), but it will still slow them down.

3 Likes
10

What @The_Decryptor and @serverco describe (Thanks!) matches my understanding and the relevant Boulder code.

The A and AAAA queries are separate. If the A query fails (e.g. due to timeout) but the AAAA succeeds only IPv6 addresses will be returned for validation. As to why that may happen in some cases but not others for your specific hostnames you would have to ask your nameserver providers :slight_smile:

I would agree with suggestions elsewhere in the thread that if you aren’t able to resolve challenges over IPv6 you should refrain from publishing an AAAA record for those domains.

(P.s. You tried to sanitize your hostnames & IP addresses from the shared ACME challenge objects but you left the full challenge URIs. These are enough to fill in the blanks. This information is useful for debugging and I’d generally lean towards not sanitizing it at all, but since you did I thought I would point out that you need to sanitize the URIs as well).

Hope this helps,

1 Like
11

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