Certbot, certificate verify failed

Hi everyone, I had certbot working last year. Plans didn't go through and now I'm at it again, but now it doesn't work. I'm running it in a FreeBSD jail, if that is of any importance. I don't care if it throws warnings as long as it will work again.

Thanks in advance!

My domain is: thijsvanderwoude.nl

I ran this command: certbot

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Unable to read ssl_module file; not disabling session tickets.
Enter email address (used for urgent renewal and security notices)
 (Enter 'c' to cancel): (my real email)
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(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired (_ssl.c:1136)')))
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): Apache/2.4.52

The operating system my web server runs on is (include version): FreeBSD 13.0-RELEASE-p7

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 version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.22.0

Check which certificate has expired. (openssl s_client -connect acme-v02.api.letsencrypt.org:443 -showcerts)

There's a possibility your system is complaining about DST Root X3.

In that case, you should install the ISRG Root X1 (and X2) certificate.

2 Likes

No, not for that URL as it uses the "short chain" ending in ISRT Root X1

The CA cert store on the system is missing that cert and needs to be updated. Off-hand I don't know how to do that with FreeBSD

4 Likes

I can only see the X1 certificate, and it says that one is expired somehow.

depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = acme-v02.api.letsencrypt.org
verify error:num=10:certificate has expired
notAfter=Jun  2 16:00:30 2022 GMT
verify return:1
depth=0 CN = acme-v02.api.letsencrypt.org
notAfter=Jun  2 16:00:30 2022 GMT
verify return:1
---
Certificate chain
 0 s:CN = acme-v02.api.letsencrypt.org
   i:C = US, O = Let's Encrypt, CN = R3
-----BEGIN CERTIFICATE-----
(removed for legibility)
-----END CERTIFICATE-----
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
-----BEGIN CERTIFICATE-----
(removed for legibility)
-----END CERTIFICATE-----
---
Server 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 3408 bytes and written 410 bytes
Verification error: certificate has expired
---
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: 10 (certificate has expired)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 7582FBD6DC2109AB162574483BB92F4DDEE65C4E7D9BE9D7772D67AEDE469E8A
    Session-ID-ctx: 
    Resumption PSK: DF93CC5BB8F75C8F081E5518A71A416297D3CD309A58190AEB61746A55232587AFD5983A0F2D8031914C110B64717B5E
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 86400 (seconds)
    TLS session ticket:
    0000 - 6e 4b 1e 56 7b 2c b7 5f-56 07 4d ec b7 1e d9 5e   nK.V{,._V.M....^
    0010 - 09 8a 23 a2 43 2f ae 64-11 fa 5a 0f 1b 5f 1f d0   ..#.C/.d..Z.._..

    Start Time: 1654368999
    Timeout   : 7200 (sec)
    Verify return code: 10 (certificate has expired)
    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: E7BC4F17CA85BAA68F9166E71A79C774C0DF28CD0745F6B92ED8ECB63955DE90
    Session-ID-ctx: 
    Resumption PSK: CD77E71674B4B19D46D64B78C52C596C12C369EE6B42DB026F1952EB31B31A05DB16445923ACB424988E1A1671A66700
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 86400 (seconds)
    TLS session ticket:
    0000 - 82 1a 38 70 0a 40 a5 25-76 5c 1b c4 01 07 c1 d1   ..8p.@.%v\......
    0010 - 66 3a 3d ff cf 00 9d 0a-bd 2b 60 f1 ac 05 fa c8   f:=......+`.....

    Start Time: 1654368999
    Timeout   : 7200 (sec)
    Verify return code: 10 (certificate has expired)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
verify return:1
verify return:1
HTTP/1.1 400 Bad Request
Server: nginx
Date: Wed, 09 Mar 2022 19:58:03 GMT
Content-Type: text/html
Content-Length: 150
Connection: close

<html>
<head><title>400 Bad Request</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx</center>
</body>
</html>
closed

What does your server believe today's date is?

3 Likes
Wed Mar  9 21:05:05 CEST 2022

And the jail has access to that?

(CEST in March? What country is that?)

1 Like

That's an odd notAfter date and does not reflect current chain being sent. Here is the current chain:

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

subject= /CN=acme-v02.api.letsencrypt.org
issuer= /C=US/O=Let's Encrypt/CN=R3
notBefore=Feb 25 15:54:15 2022 GMT
notAfter=May 26 15:54:14 2022 GMT
serial=04642AFBC83DBEE4E8B09B0BEFD7110069F1
SHA1 Fingerprint=42:51:85:F1:4A:37:88:9A:B1:6B:53:97:DA:DB:52:CC:40:C2:7F:DD

subject= /C=US/O=Let's Encrypt/CN=R3
issuer= /C=US/O=Internet Security Research Group/CN=ISRG Root X1
notBefore=Sep  4 00:00:00 2020 GMT
notAfter=Sep 15 16:00:00 2025 GMT
serial=912B084ACF0C18A753F6D62E25A75F5A
SHA1 Fingerprint=A0:53:37:5B:FE:84:E8:B7:48:78:2C:7C:EE:15:82:7A:6A:F5:A4:05

2 Likes

What's your OpenSSL version?

2 Likes

I just rebooted the system and checked what the BIOS said, the BIOS says it is the 4th of June. But date says, Wednesday, March 9th. Could it be that the motherboard uses American notation somehow...???

OpenSSL 1.1.1k-freebsd 24 Aug 2021

Netherlands, if that helps anything :sweat_smile:

No, that doesn't make any sense. And your OS should update the bios clock.

The issue with the hardware clock is usually that Windows stores the local time but unix like os store UTC time. And they fight when they dual boot.

2 Likes

So it's just wrong. It should say CET.

CEST is the summer version of CET.

Set your timezone correctly, to Europe/Amsterdam, Europe/Berlin, Europe/Paris, etc etc, they're all the same: List of tz database time zones - Wikipedia

2 Likes

FreeBSD is the only OS installed.

I guess I might know why this server was so cheap... I'll check in with the seller just in case.

The whole CET area, actually. CEST starts March 27 (if it starts).

It looks like the os starts with a wrong date, it updates it, but keeps the wrong offset.

2 Likes

I'm not the only person who uses this server. Someone else could have noticed this and set the time manually.

I just heard back from the guy, the board DOES use mm/dd/yyyy, not the way I expected it at all. Weird. Just replaced the battery, set the date right (03/09/2022).

I shall try again.

1 Like

It no longer gives me this issue! Thanks so so so much everyone!

5 Likes

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