Connect failed (99: Cannot assign requested address) while requesting certificate status


#1

Hello,

I get an error after restarting nginx and refreshing any page:

$ tail /var/log/nginx/error.log

2016/07/23 11:18:32 [crit] 13823#13823: connect() to [2a02:26f0:103::214:f4c1]:80 failed (99: Cannot assign requested address) while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org

The IPv6 address is that of your host ocsp.int-x3.letsencrypt.org:

$ host ocsp.int-x3.letsencrypt.org

ocsp.int-x3.letsencrypt.org is an alias for ocsp.int-x3.letsencrypt.org.edgesuite.net.
ocsp.int-x3.letsencrypt.org.edgesuite.net is an alias for a771.dscq.akamai.net.
…
a771.dscq.akamai.net has IPv6 address 2a02:26f0:103::214:f4c1
…

I can ping the host name fine and reach it’s port 80. I have disabled IPv6 on the system. Why is it trying to resolve it via IPv6?

Could it be related to cache?

Googling don’t give me much. Could it be related to the listen directive in /etc/nginx/sites-available/konsttorget.conf? Someone suggested I need IPv6 defined in there even though it’s inactive on the host.

URL: https://www.konsttorget.se
Ubuntu 16.04 everything upgraded
nginx/1.10.0
PHP 7 FPM


#2

Your nginx is trying to reach the OCSP (Online Certificate Status Protocol) server for Let’s Encrypt, and evidently when it performs a DNS query for the server’s name, it does get IPv6 addresses even though you say IPv6 is disabled. Then it tries to connect using IPv6, which fails, and it reports this apparently as a critical error in the logs.

It is very likely that nginx actually goes on to successfully communicate with the OCSP server over IPv4. In which case I suppose you might consider it a bug that nginx labels this “critical” in the logs. You might also consider it a bug that nginx is trying to use IPv6 when you say it’s disabled, but it may be that nginx people would say you’ve not disabled it correctly (I don’t know, try asking nginx experts)

Even if nginx is giving up there and never trying an IPv4 address for the OCSP server, which would definitely be a bug, the only effect is that your server won’t successfully do “OCSP stapling”, which makes things a tiny bit faster for visitors to your site. OCSP lets anybody check if a certificate has been revoked, either because the associated private key material was stolen, because it was obtained fraudulently or (not with Let’s Encrypt) because a payment bounced. Some web browsers check this, though not all of them. OCSP stapling is the idea that the since this status check is signed (in your case by Let’s Encrypt) and can be cached your own web server can provide it by “stapling” it to the certificate so then visitors don’t need to contact Let’s Encrypt.

Thus, even if OCSP checking is completely broken by the event that is being logged, your site will still work as you’ve probably realised, it will just be a tiny bit slower for some visitors than it might have been. If, as I suspect, the OCSP check does work, but this critical error is logged in the process, it’s just excessive logging and I suggest you investigate whether it’s fixed in newer nginx, or if not report it as a bug.

Anyway, nothing Let’s Encrypt specific here, sorry.


#3

Thank you, this must be the single best answer I’ve ever received in any form of support context.
I’ll continue investigating this with nginx.

Best regards,
Gabriel


#4

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