IPv6 broken on acme-v01.api.letsencrypt.org?


#1

Just had an interesting issue on a host with nativ IPv4+IPv6, registration just wouldn’t work. After digging around I found out that it had problems connecting to the API:

# curl -v https:/ /acme-v01.api.letsencrypt.org

  • Rebuilt URL to: https:/ /acme-v01.api.letsencrypt.org/
  • Trying 2a02:26f0:e5:186::3d5…
  • Connected to acme-v01.api.letsencrypt.org (2a02:26f0:e5:186::3d5) port 443 (#0)
  • Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
  • successfully set certificate verify locations:
  • CAfile: none
    CApath: /etc/ssl/certs/
  • TLSv1.2, TLS handshake, Client hello (1):
    wait 60 seconds
    ^C

For whatever reason the handshake doesn’t finish.
On another host which already uses LetsEncrypt but does not have native IPv6, the output looks like this:

# curl -v https:/ /acme-v01.api.letsencrypt.org

  • Rebuilt URL to: https:/ /acme-v01.api.letsencrypt.org/
  • Trying 104.66.172.12…
  • Connected to acme-v01.api.letsencrypt.org (104.66.172.12) port 443 (#0)
  • ALPN, offering http/1.1
  • Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
  • TLSv1.2 (OUT), TLS header, Certificate Status (22):
  • TLSv1.2 (OUT), TLS handshake, Client hello (1):
  • TLSv1.2 (IN), TLS handshake, Server hello (2):
  • TLSv1.2 (IN), TLS handshake, Certificate (11):
  • TLSv1.2 (IN), TLS handshake, Server key exchange (12):
  • TLSv1.2 (IN), TLS handshake, Server finished (14):
  • TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
  • TLSv1.2 (OUT), TLS change cipher, Client hello (1):
  • TLSv1.2 (OUT), TLS handshake, Finished (20):
  • TLSv1.2 (IN), TLS change cipher, Client hello (1):
  • TLSv1.2 (IN), TLS handshake, Finished (20):
  • SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
  • ALPN, server accepted to use http/1.1
  • Server certificate:

Anybody else having this issue?


#2

Seems to work for me right now.

Are you sure ipv6 is working on your end? i.e. does curl -v -6 https://google.com succeed?


#3

Yes, Google works. Now I also get packet loss(~5%), might be a routing issue at my ISP. I’ll force IPv4 for now and monitor this for a few days…


#4

Although LetsEncrypt doesn’t yet support IPv6 all of the machines I’ve run the client on are dual stacked (with both static public IPv4 & IPv6 addresses) and I’ve not seen that problem.


#5

The API is fronted by Akamai, which does provide IPv6 access. The missing piece is validation requests to IPv6-only hosts.

That is interesting that you are getting timeouts, though. Does it happen 100% of the time?


#6

Timeouts often are issues with MTU and/or Path MTU Discovery… If everything works when you lower your MTU, perhaps some firewall interferes with pMTU discovery…