Net::err_cert_date_invalid from Windows 7

Help
1

Hello, everyone!

Issue Summary
Today, I opened my site on someone's Windows 7 laptop where I got an error in Chrome. Just for info, the system was using Quick Heal anti-virus. Chrome version appears recent version by the look and feel.

URL in question: https://gulshankumar.net

Error message [PDF screenshot]

image
image960×1280 158 KB

What steps did I try?
At the same time, I can normally access in own devices with Win 10, and Android OS.

/var/log/letsencrypt

2022-07-09 11:26:07,445:DEBUG:certbot.ocsp:OCSP certificate status for /etc/letsencrypt/archive/gulshankumar.net/cert1.pem is: OCSPCertStatus.GOOD
2022-07-09 11:26:07,450:DEBUG:certbot._internal.display.obj:Notifying user: Certificate not yet due for renewal
2022-07-09 11:26:07,451:DEBUG:certbot._internal.plugins.selection:Requested authenticator webroot and installer None
2022-07-09 11:26:07,451:DEBUG:certbot._internal.display.obj:Notifying user:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2022-07-09 11:26:07,451:DEBUG:certbot._internal.display.obj:Notifying user: The following certificates are not due for renewal yet:
2022-07-09 11:26:07,451:DEBUG:certbot._internal.display.obj:Notifying user:   /etc/letsencrypt/live/gulshankumar.net/fullchain.pem expires on 2022-09-20 (skipped)
2022-07-09 11:26:07,451:DEBUG:certbot._internal.display.obj:Notifying user: No renewals were attempted.
2022-07-09 11:26:07,452:DEBUG:certbot._internal.display.obj:Notifying user: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2022-07-09 11:26:07,452:DEBUG:certbot._internal.renewal:no renewal failures

What I am aware of
There is no any TLS-related warning or error message in the Nginx error log file.

My site supports TLS 1.2 and later which is far enough to cover the majority of browsers.

So this makes me wonder why suddenly I see the error NET::ERR_CERT_DATE_INVALID

As per my experience, usually, this error happens when renewed cert is not reflected in NGINX Config and reloading/restarting fixes the problem instantly which I always maintain schedule by cron.

But the thing is ... cert is not due for renewal, and in the system where I checked I could open Google and other sites normally. I am sure, there were no bad clocking issues as well.

So, the cause of error seems mysterious. I couldn't debug further as the system where I tested was not mine.

Thanks

1 Like
2

From the looks of it, the computer in question does not have Let's Encrypts root certificate, ISRG Root X1, installed in its system trust store. This root certificate is a requirement since late 2021. Normally, Windows computers install this certificate automatically from Microsoft Windows update servers. However, it appears that this mechanism did not work on this computer. While we do not know the cause of this, possible reasons are blocked update servers, firewalls, or disabled services on the affected machine.

Fixing this requires the user to figure out why the system cannot install the certificate automatically (this should still work, even though Windows 7 no longer receives security updates), or installing the root certificate manually.

The error message shows an expired certificate, because Windows tried to build a path up to DST Root CA X3, a different root certificate Let's Encrypt used until 2021. This root certificate has now expired, thus causing the above error message. Systems must now validate against ISRG Root X1.

6 Likes
3

I'm not sure this is the case, looking at the error. The screenshot says "Issued by: R3", so I would think the computer actually has an issue with the end leaf certificate (although I haven't opened the PDF). That said, Windows systems aren't my expertise (luckily!), so maybe Windows does some weird stuff and actually has a problem with the expired DST root while still looking like the end leaf cert is the issue.

To me it just looks like the computers date is completely wrong..

6 Likes
4

No, Windows shows the "certificate has expired" error when any certificate in the chain has expired. It's a common thing, OpenSSL for example does it too.

I can reproduce this using a Windows machine where the staging DST Root is added to the trust store. Then it looks like this:

1
1405×510 9.55 KB

2
2405×510 7.76 KB

As shown here, the only certificate not validating is the root (as it's expired). But Windows displays the validation message on all certs.

The Chrome error message (in the PDF) shows that the system time is correct.

7 Likes
5

Uch, Windows. That's just plain stupid.

I'm hoping OpenSSL does mention something more sensible, e.g. referring to the chain or something like that and not literally saying "THIS CERTIFICATE has expired".

K. I just don't open random PDFs from the internet.. (PDFs can contain exploit containing content.)

6 Likes
6

OpenSSL's validation system only supports a single error return code, where the code would be "certificate has expired". It cannot indicate which certificate has expired, unless the caller performs tracing of the validation algorithm.

Therefore you get something like this.

SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
[...]
    Start Time: 1657373497
    Timeout   : 7200 (sec)
    Verify return code: 10 (certificate has expired)
    Extended master secret: no
    Max Early Data: 0
---

When it's the root that is expired. Just like the "certification path" tab on Windows, the s_client command actually performs tracing, where you get more info (assuming one understands the output, it's not obvious):

>openssl s_client -connect expired-root-ca-test.germancoding.com:443
CONNECTED(00000194)
depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Doctored Durian Root CA X3
verify error:num=10:certificate has expired
notAfter=Jan 30 14:01:15 2021 GMT
verify return:1
depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Doctored Durian Root CA X3
notAfter=Jan 30 14:01:15 2021 GMT
verify return:1
depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Pretend Pear X1
notAfter=Sep 30 18:14:03 2024 GMT
verify return:1
depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial Apricot R3
notAfter=Sep 15 16:00:00 2025 GMT
verify return:1
depth=0 CN = expired-root-ca-test.germancoding.com
notAfter=Aug 13 12:31:03 2022 GMT
verify return:1
---

Many implementations have issues like this, GnuTLS also has these weird error return codes and basically everything else that ships with OpenSSL compatibility layers.

7 Likes
7

Well, a generic "[a] certificate has expired" is always better than falsely specifying "THIS certificate".

7 Likes
8

Here's the screenshot of error. (Posting my PDF as JPEG to assure the safest experience)

Privacy error (1)_page-0001
Privacy error (1)_page-00011650×1275 198 KB

Privacy error (1)_page-0002
Privacy error (1)_page-00021650×1275 164 KB

1 Like
9

Please also show the "Certification Path" tab when the certificate is seen as invalid.

8 Likes
10

I think the theory is something along the lines of thinking that a certificate isn't allowed to sign a certificate with dates beyond its own dates (like, a root can't make an intermediate certificate expiring after itself expires, and similarly with an intermediate not signing a leaf certificate that expires after the intermediate itself does). That is, validity dates are "clamped" to the most restrictive of all certificates in the chain, and therefore with that thinking the leaf certificate is expired, because the most restrictive of all dates doesn't leave it with a validity period.

But that certainly makes the messaging confusing when there are multiple certificates using the same key but with different dates, and the client doesn't know about all of them.

7 Likes
11

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