OCSP responder not available using IPv6

My domain is: office.pc-tiede.de

I ran this command:
ping -6 ocsp.int-x3.letsencrypt.org

It produced this output:
PING ocsp.int-x3.letsencrypt.org(g2a02-26f0-00e7-0000-0000-0000-5f65-48c0.deploy.static.akamaitechnologies.com (2a02:26f0:e7::5f65:48c0)) 56 data bytes
^C
ocsp.int-x3.letsencrypt.org ping statistics —
7 packets transmitted, 0 received, 100% packet loss, time 202ms

A traceroute yields “network unreachable” - from my ISP’s border gateway, my other IPv6 connections, except towards Akamai, work okay.

My web server is (include version):
nginx 1.16.1

The operating system my web server runs on is (include version):
Gentoo Linux latest stable

My hosting provider, if applicable, is:
myself, ISP in use is TAL.de, AS8820.

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 problem, according to my ISP, is Akamai, as it seems to propagate wrong IPv6 routes to my ISP, rendering the OCSP responder hosted at Akamai unreachable from my network using IPv6 - IPv4 connectivity is good.

Another machine on a different ISP does not have the issue, but then my affected ISP is rather small. So far they’ve worked around it for a couple of machines at Akamai and will likely do so for the next bunch later today but advised again that Akamai seems to have provided them with invalid routing and asked if I could inform the organisation actually relying on Akamai services about the issue at hand, which I am doing here.

I don’t know if Let’s Encrypt or ISRG actually has some leverage to to work on this, but I would be grateful if it was tried.

1 Like

Hi, @ftiede,

I did some troubleshooting from my vantage point at NTS Workspace AG (AS15576) in Switzerland, and everything looks okay from there. DNS for ocsp.int-x3.letsencrypt.org gave me a different Akamai POP, but I was able to connect both to it and to the same POP you were given (2a02:26f0:e7::5f65:48c0, Telecity Frankfurt).

In our experience, Akamai won’t usually be able to work directly with us on routing issues with individual ISPs/ASNs like this. They’ll want to talk directly to the affected ISP’s network engineers. I’m sorry about the trouble, and thanks for checking with us!

5 Likes

I’ve also already got an answer from my ISP stating there are troubles with different routing providers on their end (i.e. SysEleven works at one of their POPs but not both, German Telekom works on neither and CenturyLink works at at least one of their POPs with CL).

They’ve switched their network to route via CenturyLink and that works for me now, so I will report that back to them.

My ISP’s statement is that they’re way too small to force Akamai to any action, as they’re probably representing less than a single percent (if that many at all) of german customers, even more so as IPv6 is still rather exotic here.

Meanwhile it turned out that my other machine (the one on the different ISP) apparently resolved ocsp.int-x3.letsencrypt.org to 2a01:4a0:1338:28::c38a:ff10, which isn’t Akamai at all and worked from my local (affected) ISP quite as well, so I do have a workaround by stuffing that v6 address into my host’s /etc/hosts to make it work again, albeit that’s actually a really dirty hack.

So, I wanted to let you know about current state of things and maybe it helps others if they run into the same issue.

I know it’s not on Let’s Encrypt’s end, so no need to be sorry, I’m grateful for you to take notice.

6 Likes

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