Certbot fails with SSLError / Max retries exceeded /directory after domain name and host name change

Help
1

My domain is: https://meza.wiki

I ran this command: certbot certonly

It produced this output:

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)'),))

web server: Apache/2.4.37 (rocky)

operating system: Rocky Linux 8

hosting provider: DigitalOcean

root shell on my machine: Yes

using a control panel: No

certbot 1.22.0

Other notes: Certbot was working fine when the domain name was "meza-dev.io" (which I still own) but ever since I changed the domain name to "meza.wiki" I can not get certbot to make a cert.

2

Someone in a similar thread said it could be a TLS certificate error on the system itself and to run "openssl s_client -connect server:port" which resulted in:

"140610276710208:error:2008F002:BIO routines:BIO_lookup_ex:system lib:crypto/bio/b_addr.c:730:Servname not supported for ai_socktype connect:errno=0"

Not sure if this is relevant, I'm mostly an applications guy and am just starting to learn the server config and admin side of things. The server seems to work well in every other regard.

3

This new domain has a different IP than your older one so I assume this is a new server too. Is that right?

What do these show?

curl -I https://acme-v02.api.letsencrypt.org
curl -I https://cloudflare.com
2 Likes
4 
Name:    meza-dev.io
Address: 162.255.119.133

Name:    meza.wiki
Address: 142.93.176.107

Please show:

curl -4 ifconfig.io

2 Likes
5

Hi MikeMcQ, thanks for the quick response.

It's actually the same server. I just changed the hostname on the digitalocean droplet to "meza.wiki" and pointed the new domain to it. I don't think I have any control over the IP address DigitalOcean assigns me.

Here's the info you requested:

curl -I https://acme-v02.api.letsencrypt.org

HTTP/2 200
server: nginx
date: Thu, 07 Dec 2023 04:22:39 GMT
content-type: text/html
content-length: 1540
last-modified: Thu, 23 Jun 2022 21:25:45 GMT
etag: "62b4da59-604"
x-frame-options: DENY
strict-transport-security: max-age=604800

curl -I https://cloudflare.com

HTTP/2 301
date: Thu, 07 Dec 2023 04:22:51 GMT
location: https://www.cloudflare.com/
cache-control: max-age=3600
expires: Thu, 07 Dec 2023 05:22:51 GMT
set-cookie: __cf_bm=CTJTOlBsk.RsTukYmwZducVEd1S.FdenyzTWG68S.zg-1701922971-0-ARg7qAfVvwRR7aR3KOjMWRoM7bQgCx9rWWxWZK3cprZRVr/HYnzOWYwmoTXjWn8GwrICfUXxBBTpZ4ns1zO4MPs=; path=/; expires=Thu, 07-Dec-23 04:52:51 GMT; domain=.cloudflare.com; HttpOnly; Secure; SameSite=None
report-to: {"endpoints":[{"url":"https://a.nel.cloudflare.com/report/v3?s=jaYXVeHoJVXs1SjAtJSlpEbMGq4De8ASV6EVZ3Wv1Ot9vYHDk%2BR6FIM6dzsjpYFYYxW5TnYRuk49YlyEVg3pgq37NiomJskynOQpGZk3adjx4k8WigBzlmsHq3ZfDZxp"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
strict-transport-security: max-age=15780000; includeSubDomains
server: cloudflare
cf-ray: 8319fd6a4f75c461-EWR
alt-svc: h3=":443"; ma=86400

6

Hi rg305, thanks for the quick response.

Interesting! .. It's actually the same server. I just changed the hostname on the digitalocean droplet to "meza.wiki" and pointed the new domain to it. I don't think I have any control over the IP address DigitalOcean assigns me. Are you thinking there is a clear diagnosis and an easy solution to my issue?

7

If the IP is use isn't the IP in DNS, then you will never get anyone to reach your server [over the Internet].

2 Likes
8

curl -4 ifconfig.io

142.93.176.107

The server is viewable on the internet at https://meza.wiki

9

What shows?:
traceroute -T -p 443 acme-v02.api.letsencrypt.org

1 Like
10

traceroute -T -p 443 acme-v02.api.letsencrypt.org

traceroute to acme-v02.api.letsencrypt.org (172.65.32.248), 30 hops max, 60 byte packets
1 * * *
2 10.74.194.214 (10.74.194.214) 1.221 ms 1.215 ms 1.211 ms
3 138.197.251.8 (138.197.251.8) 1.182 ms 138.197.251.0 (138.197.251.0) 1.418 ms 138.197.251.10 (138.197.251.10) 1.184 ms
4 138.197.248.16 (138.197.248.16) 13.472 ms 138.197.248.58 (138.197.248.58) 1.118 ms 1.067 ms
5 138.197.244.36 (138.197.244.36) 1.361 ms 138.197.244.32 (138.197.244.32) 1.247 ms 138.197.244.36 (138.197.244.36) 1.343 ms
6 192.241.164.73 (192.241.164.73) 1.878 ms 1.932 ms 1.610 ms
7 172.70.228.4 (172.70.228.4) 2.257 ms 162.158.156.5 (162.158.156.5) 1.520 ms 1.506 ms
8 172.65.32.248 (172.65.32.248) 1.511 ms 1.353 ms 1.246 ms

11

Can you update certbot to a newer version?

2 Likes
12

dnf update says, "nothing to do".

13

Can you install "snapd" on "Rocky Linux 8" ?
If so, then try:
Certbot Instructions | Certbot (eff.org)

2 Likes
14

I have absolutely no clue what this error message means, but perhaps your OpenSSL is rather old and you'd need to use:

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

Also, what's the output of openssl verrsion?

1 Like
15

@rg305, I can't install snapd. It would violate the system's security plan... Continued thanks for your assistance, insights and help.

@Osiris, I've got OpenSSL 1.1.1k FIPS 25 Mar 2021. It is what the system considers up to date. Is that old to you?

I have to believe that, since certbot work when the exact same system simply had a different name, and that everything else seems fine, it must be some minor issue in the configuration (not the version) of some component - such as the certbot account and or user cache of something?

16

I hope that plan involves an upgrade (soon):

image

1 Like
17

What shows?:

2 Likes
18

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

CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify error:num=2:unable to get issuer certificate
issuer= O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
issuer= C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=0 CN = acme-v02.api.letsencrypt.org
issuer= C = US, O = Let's Encrypt, CN = R3
verify return:1
---
Certificate chain
 0 s:CN = acme-v02.api.letsencrypt.org
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
---
Server certificate
-----BEGIN CERTIFICATE-----
**************************************
************ OMITTTED ****************
**************************************
-----END CERTIFICATE-----
subject=CN = acme-v02.api.letsencrypt.org

issuer=C = US, O = Let's Encrypt, CN = R3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3350 bytes and written 406 bytes
Verification error: unable to get issuer certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 2 (unable to get issuer certificate)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 548F1BE8E88824814F2ECE5C494A5A1FB97405E89B75E1B2A09BFF05C6BBB375
    Session-ID-ctx: 
    Resumption PSK: 8D7AF59D92B8199B59C69F01E0481BC510484261B0E4D71BF778FECE7AFC96EE82302FEB72761CCE3934B24EABEE8F54
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 86400 (seconds)
    TLS session ticket:
    0000 - dd f6 d8 18 47 ac 6f 74-d6 aa c6 3a 14 f5 3e 61   ....G.ot...:..>a
    0010 - b3 f7 7b 8a 38 5f f2 78-ba 34 6c 04 84 8a 01 ab   ..{.8_.x.4l.....

    Start Time: 1701962066
    Timeout   : 7200 (sec)
    Verify return code: 2 (unable to get issuer certificate)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: B7C634A562A0A9C187F7AC8575F1735D29EF56C9B3F4C1DFAC88128E6E0538B3
    Session-ID-ctx: 
    Resumption PSK: F5153099AD7636621DE33FB07DD69F722C87C61742735FEA9F73FC07F43B6CBB9CC0B7C5F52CBAD80393037CE74E5109
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 86400 (seconds)
    TLS session ticket:
    0000 - a9 d0 37 f6 1d 26 11 ef-7b 2a 7f 59 c0 4e 17 da   ..7..&..{*.Y.N..
    0010 - 9b 0d df a9 23 08 29 cf-0a 4f 74 06 79 1e b6 64   ....#.)..Ot.y..d

    Start Time: 1701962066
    Timeout   : 7200 (sec)
    Verify return code: 2 (unable to get issuer certificate)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK

........2 minute wait.........

read:errno=0
19

Something looks really wrong here. Can you show the certificates you omitted? Those are not secret. Anybody can see them by issuing the same command. But, I am wondering if the real ones are being substituted with something else.

What is odd is the chain only has 2 certs which is what we expect. But, the depth level 2 is showing the ISRG Root X1 cross-sign with DST Root CA X3.

There shouldn't be any reason for your system to show that. At least, I can't think of one. I tried with an older openssl than yours and one more current and neither shows it like yours.

2 Likes
20

I don't understand this either. I know that browsers can build their own chain from either cached intermediates from other sites or use the Authority Information Access extension from the send intermediate. But as far as I know, OpenSSL does not do this.

So I'm also puzzled where the DST Root X3 signed by ISRG Root X1 intermediate cert suddenly comes from.. It was not in the chain send by the ACME API.

Anyway, I do think we can conclude that OPs server doesn't contain the ISRG Root X1 root certificate, right?

2 Likes