R3 expiration: why `openssl s_client -connect` keeps stating `certificate has expired` if `openssl x509 -noout -dates` in all cert files inform they are still valid

tlforthewin · October 1, 2021, 12:36pm

nginx ssl_certificate directive pointing to /etc/letsencrypt/live/temporadalivre.com/fullchain.pem

I assured that we have correct dates in ALL our certificates:

sudo openssl x509 -dates -noout -in cert.pem
notBefore=Sep 11 20:57:45 2021 GMT
notAfter=Dec 10 20:57:44 2021 GMT

sudo openssl x509 -dates -noout -in chain.pem
notBefore=Sep  4 00:00:00 2020 GMT
notAfter=Sep 15 16:00:00 2025 GMT

sudo openssl x509 -dates -noout -in fullchain.pem
notBefore=Sep 11 20:57:45 2021 GMT
notAfter=Dec 10 20:57:44 2021 GMT

However, we have users reporting NET::ERR_CERT_DATE_INVALID.

I can open our site just fine using Chrome/Firefox/Safari, but if I try to run openssl s_client -connect temporadalivre.com:443, this is what I get:

CONNECTED(00000005)
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
---
Certificate chain
 0 s:/CN=temporadalivre.com
   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
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate

Any help is much appreciated.

tlforthewin · October 1, 2021, 12:40pm

Asked a colleague to run the same command in his Ubuntu machine (I'm on Mac Os 10.15.7), and surprisingly he doesn't see the X3 certificate nor the expiration error:

CONNECTED(00000003)
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 = temporadalivre.com
verify return:1
---
Certificate chain
 0 s:CN = temporadalivre.com
   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
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate

Is there some kind of cache going on?

Bruce5051 · October 1, 2021, 12:47pm

Check the date and time on each machine. If you machine's time appears to be in the future you could see a response like that. However mostly likely your machines are correctly time synced. But got to start somewhere.

tlforthewin · October 1, 2021, 12:56pm

Both have current date time (used date command in the terminal to be sure).

Bruce5051 · October 1, 2021, 1:06pm

Figured as much.

Bruce5051 · October 1, 2021, 1:14pm

And what version of OpenSSL do each have?

Bruce5051 · October 1, 2021, 1:28pm

And with Quick Chain Checker I see this:

## Certificate Chain for temporadalivre.com

temporadalivre.com :: R3 :: ISRG Root X1

### Let's Encrypt Modern Chain (May not support some older devices)

This Let's Encrypt chain uses the newer ISRG Root X1 root, which is trusted by current operating systems. This chain may cause issues for some old devices, particularly Android 7.0 and lower.

## temporadalivre.com

Serial 033002C862078ED05E5C27A146573C868544

Issuer R3

Start Sat Sep 11 2021

Expiry Fri Dec 10 2021

Type End-Entity

Status OK

## R3

Serial 00912B084ACF0C18A753F6D62E25A75F5A

Issuer ISRG Root X1

Start Thu Sep 03 2020

Expiry Mon Sep 15 2025

Type Intermediate

Status OK

## ISRG Root X1

Serial 008210CFB0D240E3594463E0BB63828B00

Issuer ISRG Root X1

Start Thu Jun 04 2015

Expiry Mon Jun 04 2035

Type Root

Status OK

And then SSL Report: temporadalivre.com (177.54.150.135) looks good, but has this:
|

**4**|In trust store|DST Root CA X3 Self-signed
Fingerprint SHA256: 0687260331a72403d909f105e69bcf0d32e1bd2493ffc6d9206d11bcd6770739
Pin SHA256: Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=
RSA 2048 bits (e 65537) / SHA1withRSA
Valid until: Thu, 30 Sep 2021 14:01:15 UTC
**EXPIRED**
Weak or insecure signature, but no impact on root certificate|
| --- | --- |

And then SSL Checker nothing jumped out at me.

Bruce5051 · October 1, 2021, 1:43pm

Yet on Windows 10 with

"C:\Program Files\OpenSSL-Win64\bin\openssl.exe" version
OpenSSL 1.1.1l  24 Aug 2021

I see this as the tail

-----END CERTIFICATE-----
subject=CN = temporadalivre.com

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 4654 bytes and written 400 bytes
Verification error: unable to get local 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: 20 (unable to get local issuer certificate)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 1E5B0E2558F0028878DEC55D9EE4DC42D65B8C0F8180F913BD144EFFF7675D78
    Session-ID-ctx:
    Resumption PSK: 70B00589F2AE856F89F1D7FE9C72906C1AAE5DC1D691DFAB0ECFFE7D54076E4E7FA37A58A42D77AFDAB1BB33CF36C5A3
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 86400 (seconds)
    TLS session ticket:
    0000 - cf ac 94 90 ed ce 91 b7-21 6c 33 73 f0 65 77 cd   ........!l3s.ew.
    0010 - 9e 1f 07 ba 1f 84 5c f3-b0 0d f2 84 80 a6 ca 62   ......\........b

    Start Time: 1633095010
    Timeout   : 7200 (sec)
    Verify return code: 20 (unable to get local 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: 4C71BC18084D92EB49524FFD60E225923609EC95F308F9C8035FB49439595ED6
    Session-ID-ctx:
    Resumption PSK: F864C26A7253F4D7BACD52D2CA17178C2D146929C2B532A27CB063CB07231538A21EFA9AE3372DC841BF019AF888AF29
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 86400 (seconds)
    TLS session ticket:
    0000 - 3b 4c d7 4a 1d e8 5b 87-ee d9 9a 00 66 ee 20 d6   ;L.J..[.....f. .
    0010 - ae 1f da c0 b2 c7 6c 34-8b 72 40 74 ce 2d 6b be   ......l4.r@t.-k.

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

A compared to Ubuntu 20.04.3 LTS with

openssl version
OpenSSL 1.1.1f  31 Mar 2020

I see this for the tail

-----END CERTIFICATE-----
subject=CN = temporadalivre.com

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 4654 bytes and written 390 bytes
Verification: OK
---
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: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 07928EBA9A95F6910E96D87C449CF9063233A37DD844D40F722D2F96B91A5907
    Session-ID-ctx:
    Resumption PSK: 714AA7B9D641B51D1F11E63C71D59632F5DBB3122BEA184E7C5CA7F723FEDA0D9A0D4648DA7E2D75DA8567EDD38294A3
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 86400 (seconds)
    TLS session ticket:
    0000 - f3 a9 f0 b2 c8 f8 59 f2-f9 f2 b7 20 7f af cb 15   ......Y.... ....
    0010 - 9f 17 06 80 50 c1 d8 48-9f cb c3 89 97 0a 60 e8   ....P..H......`.

    Start Time: 1633095545
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    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: 0FCA74AC4E1A54908F8445993BA2606D71A9432E147FB8E5791478498432B82A
    Session-ID-ctx:
    Resumption PSK: 04939E00FACA2940DFA787983622A5A8D2520688CB04147E0F4685C1E0FD0DCD9FC22E940ADDB46E1BDE7175AF8439CF
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 86400 (seconds)
    TLS session ticket:
    0000 - a9 34 7d 59 e9 1e 40 a5-ba 13 ea 0d 81 2e 9f f9   .4}Y..@.........
    0010 - fe a8 1e 88 01 8a 3e 12-97 eb 8c 05 c9 65 31 02   ......>......e1.

    Start Time: 1633095545
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK

The biggest difference I see is Windows gets
Verify return code: 20 (unable to get local issuer certificate)
Where Ubuntu get
Verify return code: 0 (ok)

And I do not have the knowledge to know why. Hopefully other on the forum can be of more assistance.

tlforthewin · October 1, 2021, 1:44pm

The output of openssl version on my colleague's Ubuntu,

OpenSSL 1.1.1f  31 Mar 2020

On my Mac:

LibreSSL 2.8.3

@Bruce5051 Is there anything we can/should do about the Weak or insecure signature alert?

Bruce5051 · October 1, 2021, 1:48pm

@tlforthewin sorry I do not know, need to open this up to a more experienced audience than me.

Nummer378 · October 1, 2021, 3:10pm

It looks like both your own openssl as well as some of your users do not have ISRG Root X1 in their trust store.

Not sure where this is from, but it's probably because of the SHA-1 signature of DST Root CA X3. This is expected and nothing to worry about.

ISRG Root X1 should have been installed into system trust stores as part of auto-updates years ago. However it looks like there were quite a few systems were this wasn't the case.

tlforthewin · October 1, 2021, 4:04pm

@Nummer378 isn't it weird that I can access the website normally using Chrome/Firefox/Safari, but my very own terminal, in the same machine, reports that certificate has expired when I run openssl s_client -connect temporadalivre.com:443 ?

Nummer378 · October 1, 2021, 4:08pm

They probably use different trust stores. Your browsers are most likely using the platform verifier build into your macOS, while openssl reads trust stores from a basic file/directory.

system · October 31, 2021, 4:09pm

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

Topic		Replies	Views
Certificate Expiration does not match Help	42	2368	December 4, 2019
Certificates Showing As Expired on some platforms Help	26	10345	November 1, 2021
Certificate end in the future but expired Help	6	795	November 1, 2022
NET::ERR_CERT_DATE_INVALID but certbot reported it is OK Client dev	6	8347	October 22, 2017
Expired certificates detected after a renewal ( Certbot, nginx ) Help	11	3593	November 16, 2020

R3 expiration: why `openssl s_client -connect` keeps stating `certificate has expired` if `openssl x509 -noout -dates` in all cert files inform they are still valid

Related topics