urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='acme-v02.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by SSLError(SSLError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897)'),))

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: nexusrepo.XXX.com

I ran this command: sudo certbot run -a manual -i nginx -d XXX

It produced this output: Saving debug log to /var/log/letsencrypt/letsencrypt.log An unexpected error occurred: requests.exceptions.SSLError: HTTPSConnectionPool(host='acme-v02.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by SSLError(SSLError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897)'),)) Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version):nginx -v
nginx version: nginx/1.14.1

The operating system my web server runs on is (include version): CentOS Linux release 8.2.2004 (Core)

My hosting provider, if applicable, is:

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): ssh

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.20.0

Other command executed.
I ran this command: curl -v https://acme-v02.api.letsencrypt.org/
It produced this output:

  • Trying 172.65.32.248...
  • TCP_NODELAY set
  • Connected to acme-v02.api.letsencrypt.org (172.65.32.248) port 443 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • successfully set certificate verify locations:
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt
    CApath: none
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
  • TLSv1.3 (IN), TLS handshake, Server hello (2):
  • TLSv1.3 (IN), TLS handshake, [no content] (0):
  • TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
  • TLSv1.3 (IN), TLS handshake, [no content] (0):
  • TLSv1.3 (IN), TLS handshake, Certificate (11):
  • TLSv1.3 (OUT), TLS alert, unknown CA (560):
  • SSL certificate problem: self signed certificate in certificate chain
  • Closing connection 0
    curl: (60) SSL certificate problem: self signed certificate in certificate chain
    More details here: curl - SSL CA Certificates

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page menioned above.

I ran this command: dig acme-v02.api.letsencrypt.org
It produced this output:

; <<>> DiG 9.11.13-RedHat-9.11.13-6.el8_2.1 <<>> acme-v02.api.letsencrypt.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58719
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;acme-v02.api.letsencrypt.org. IN A

;; ANSWER SECTION:
acme-v02.api.letsencrypt.org. 6157 IN CNAME prod.api.letsencrypt.org.
prod.api.letsencrypt.org. 184 IN CNAME ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com.
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com. 184 IN A 172.65.32.248

;; Query time: 0 msec
;; SERVER: 192.168.5.2#53(192.168.5.2)
;; WHEN: Mon Dec 06 19:17:54 IST 2021
;; MSG SIZE rcvd: 155

I ran this command: update-ca-trust --refresh
It produced this output: No output

Hi @Yuvaraj,

Are there other certificate-related packages that could be updated on your system? It does seem likely that the problem has to do with your trust store.

Here is a recent solution on CentOS related to this which I hadn't seen before:

If all of your certificate-related packages are already up to date, you might want to look at the solution in that thread.

2 Likes

Can you show the result of this command:

grep -E 'ISRG Root|DST Root|R3' /etc/pki/tls/certs/ca-bundle.crt | grep '#'

You should at least see a couple lines for GTS and GlobalSign

Also this:

ls -l /etc/pki/tls/certs/ca-bundle.crt

And also the ls -l for the file that symlinks to (if any).

3 Likes

3 posts were split to a new topic: Outage question

@MikeMcQ
grep -E 'ISRG Root|DST Root|R3' /etc/pki/tls/certs/ca-bundle.crt | grep '#'

# DST Root CA X3
# GTS Root R3
# GlobalSign Root CA - R3
# ISRG Root X1

ls -l /etc/pki/tls/certs/ca-bundle.crt
lrwxrwxrwx. 1 root root 49 Sep 22 19:24 /etc/pki/tls/certs/ca-bundle.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

@schoen I have updated all packages, but I keep getting the same message.

@Yuvaraj Your CA bundle looks OK. It no longer needs DST Root CA X3 as it has expired but that is not even used by the acme-v02... URL anyway.

Can you access any other URLs? Would you try:

curl -I https://www.digicert.com
1 Like

curl -I https://www.digicert.com

HTTP/2 200
server: nginx
date: Thu, 09 Dec 2021 05:08:20 GMT
content-type: text/html;charset=utf-8
content-length: 71870
x-content-type-options: nosniff
age: 4861
last-modified: Thu, 09 Dec 2021 03:47:19 GMT
etag: "118be-5d2ae7698164e"
accept-ranges: bytes
x-xss-protection: 1; mode=block
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
set-cookie: visid_incap_1323850=bQYK8IR5RwiL0bP2DvJHwUOPsWEAAAAAQUIPAAAAAACmrPW0rItWn4G+95W8hWdr; expires=Thu, 08 Dec 2022 11:47:16 GMT; HttpOnly; path=/; Domain=.digicert.com; Secure; SameSite=None
set-cookie: incap_ses_1137_1323850=PHBzYSdT4icoSOCu6W/HD0OPsWEAAAAAb9C/Wy0Tu0N0qah9GIVaKQ==; path=/; Domain=.digicert.com; Secure; SameSite=None
strict-transport-security: max-age=31536000
x-cdn: Imperva
x-iinfo: 10-66159674-66159675 NNNN CT(198 400 0) RT(1639026498535 0) q(0 0 6 -1) r(8 8) U12

Hmmm. What about this:

 echo | openssl s_client -connect acme-v02.api.letsencrypt.org:443 -servername acme-v02.api.letsencrypt.org | head

and this:

openssl version
2 Likes

@MikeMcQ Please find the details as below.
openssl version

OpenSSL 1.1.1k FIPS 25 Mar 2021

echo | openssl s_client -connect acme-v02.api.letsencrypt.org:443 -servername acme-v02.api.letsencrypt.org | head

depth=1 C = US, ST = California, L = Sunnyvale, O = Fortinet, OU = Certificate Authority, CN = FG4H0ETB20903376, emailAddress = support@fortinet.com
verify error:num=19:self signed certificate in certificate chain
verify return:1
depth=1 C = US, ST = California, L = Sunnyvale, O = Fortinet, OU = Certificate Authority, CN = FG4H0ETB20903376, emailAddress = support@fortinet.com
verify return:1
depth=0 CN = acme-v02.api.letsencrypt.org
verify return:1
CONNECTED(00000003)
DONE
/---
Certificate chain
0 s:CN = acme-v02.api.letsencrypt.org
i:C = US, ST = California, L = Sunnyvale, O = Fortinet, OU = Certificate Authority, CN = FG4H0ETB20903376, emailAddress = support@fortinet.com
1 s:C = US, ST = California, L = Sunnyvale, O = Fortinet, OU = Certificate Authority, CN = FG4H0ETB20903376, emailAddress = support@fortinet.com
i:C = US, ST = California, L = Sunnyvale, O = Fortinet, OU = Certificate Authority, CN = FG4H0ETB20903376, emailAddress = support@fortinet.com
/---
Server certificate
-----BEGIN CERTIFICATE-----

This shows that your outgoing connections are being proxied by a Fortinet firewall. Your server is probably rejecting the certificate because the Fortinet firewall is intercepting these connections, and your server isn't configured to permit that (so the interception is a fatal security error). Do you know who is operating this firewall? Can you get a direct connection to the Internet that doesn't go through it?

3 Likes

@Yuvaraj
If your certificate is very close to expiry (or has already expired), you could try adding:
--no-verify-ssl

2 Likes

@schoen Thanks, able to resolve the issue, it's due to a firewall.

3 Likes

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