Max retries exceeded with url: /directory

Help
1

certificate renew error

Failed to renew certificate capacitacionrueps.ieps.gob.ec with error: HTTPSConnectionPool(host='acme-v02.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate in certificate chain (_ssl.c:1123)')))

1 Like
2

Welcome to the Let's Encrypt Community :slightly_smiling_face:

I'm going to ask for some help with this one.

@lestaff

I know in the past that these "HTTPSConnectionPool(host='acme-v02.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory" errors have frequently been associated with IP address blocks. Sometimes they go unsolved or seem to mysteriously resolve themselves without explanation or followup.

Here's a recent, very similar case:

Does the staff have any thoughts here?

2 Likes
3

Hi, @jdavasco05,

What output do you get when you run these commands on the same server as your Certbot installation?

dig acme-v02.api.letsencrypt.org
traceroute acme-v02.api.letsencrypt.org
curl -v https://acme-v02.api.letsencrypt.org/
openssl s_client -connect acme-v02.api.letsencrypt.org:443 -servername acme-v02.api.letsencrypt.org
3 Likes
4

I think this is one of those error messages that can result from very different causes; the last ("Caused by") part of the message is most relevant. "Certificate verify failed" errors are probably not caused by an IP address block.

2 Likes
5

I suspected as much, but wasn't entirely sure. I surmise then that this might have something to do with the local trust store being unable to verify the certificate being sent by the directory endpoint.

1 Like
6

Agreed. Most likely DNS for acme-v02.api is going somewhere unexpected; one of its CDN nodes is serving something unexpected; or the client is using an old trust store without ISRG Root X1.

3 Likes
7

acme-v02.api is still serving a chain rooted in DST Root CA X3 for now, though of course I'm curious when it'll change to just be ISRG Root X1.

Had this server been able to connect before, but can't now? I'm assuming the problem isn't the API endpoint using the "long" chain now, though I suspect that's the only thing that's changed on the Let's Encrypt side of things in the past couple months.

2 Likes
8

Thanks all answers, the problem finally was a Firewall problem

3 Likes
9

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