Am running Chrome v.49 as it is the last version which runs on XP.
Many sites give the following error which suggests a problem with
security certificates:
NET::ERR_CERT_DATE_INVALID
Your clock is ahead
A private connection to english.stackexchange.com can't be
established because your computer's date and time (Monday, 17
January 2022 at 09:33:31) are incorrect.
To establish a secure connection, your clock needs to be set
correctly. This is because the certificates that websites use to
identify themselves are only valid for specific periods of time.
Since your device's clock is incorrect, Google Chrome cannot verify
these certificates.
It is not occurring with other browsers (eg Firefox v.52 or MyPal).
What steps in XP or Chrome are needed to renew the certificates and
where are they obtained?
Also XP's "Internet Properties" dialogue (inetcpl.cpl) shows SSL2.0 and SSL3.0 are disabled and TLS1.0 is enabled. Is this correct?
Am running Chrome v.49 as it is the last version which runs on XP.
Many sites give the following error which suggests a problem with
security certificates:
NET::ERR_CERT_DATE_INVALID
Your clock is ahead
A private connection to english.stackexchange.com can't be
established because your computer's date and time (Monday, 17
January 2022 at 09:33:31) are incorrect.
To establish a secure connection, your clock needs to be set
correctly. This is because the certificates that websites use to
identify themselves are only valid for specific periods of time.
Since your device's clock is incorrect, Google Chrome cannot verify
these certificates.
It is not occurring with other browsers (eg Firefox v.52 or MyPal).
What steps in XP or Chrome are needed to renew the certificates and
where are they obtained?
Also XP's "Internet Properties" dialogue (inetcpl.cpl) shows SSL2.0 and SSL3.0 are disabled and TLS1.0 is enabled. Is this correct?
...
Pamela <pamela.private.mailbox@gmail.com> wrote:
Am running Chrome v.49 as it is the last version which runs on XP.
Many sites give the following error which suggests a problem with
security certificates:
NET::ERR_CERT_DATE_INVALID
Your clock is ahead
A private connection to english.stackexchange.com can't be
established because your computer's date and time (Monday, 17
January 2022 at 09:33:31) are incorrect.
To establish a secure connection, your clock needs to be set
correctly. This is because the certificates that websites use to
identify themselves are only valid for specific periods of time.
Since your device's clock is incorrect, Google Chrome cannot
verify these certificates.
It is not occurring with other browsers (eg Firefox v.52 or MyPal).
What steps in XP or Chrome are needed to renew the certificates and
where are they obtained?
Also XP's "Internet Properties" dialogue (inetcpl.cpl) shows SSL2.0
and SSL3.0 are disabled and TLS1.0 is enabled. Is this correct?
The handshaking for site certs to establish and HTTPS connection
requires the endpoint hosts be close in time. During the
handshaking, timestamped tokens are passed which must be used
immediately (within a short time, like a few minutes). If the
endpoint hosts are off on their clocks, the tokens can be already
expired when received, or are premature (too early) to be usable.
Your Chrome sees a different host clock than do other web browsers.
Clocks are used for certificate validation. The certs define the
validity period which is why how far the clocks can be off can vary.
Else, a hacker could capture your handshaking session to reuse it
later.
When the server presents its certificate, it includes the server's
present time in the validity range. The cert, as presented to the
client, has notBefore and notAfter fields, and the server's time must
fall within that range. The client's clock also has to fall within
that range. Outside of that range, and the [tokens during the
handshaking for the] cert will be considered expired or not yet
usable.
When the error reports what Chrome sees as the host's clock time, how
far different is it from the time shown by the Clock app (in the
Taskbar) or when you run the Clock app? Do you have automatic
timezone adjust enabled? Are you using the timezone for where you
are? Could be your timezone is off by 1, or more, hours. Is your
system clock configured to update to reflect when Daylight Savings is
on or off? If you check your smartphone for the time, or another
reliable time source, like an atomic-sync clock, how far off is your
Windows XP's time from the real time?
The reported error can be misleading, too. It may be their server's
clock that is off instead of yours. The client is merely reporting
the endpoint hosts are too far apart in their clocks to handle the timestamped tokens used during the handshaking to establish a secure connection. HTTPS is secured. There are no certs used in an HTTP connection, but those are quickly fading as everyone is switching to
HTTPS, especially since site certs can be obtained for free, like
from LetsEncrypt.
If the error is on your end (instead of on the server end), the
question is why only Chrome sees a different system clock time. The
other web browsers see the correct system clock, but not Chrome.
That is weird. A presumption of "not occurring with other browsers"
is that those other web browsers are running on the same host within
the same Windows account as when you use Chrome to get the clock
error. The expectation is each web browser is going to see the same
system clock. When all web browsers are running on the same host, I
can't think of why some clients can see the system clock, but one
cannot, or sees the wrong time.
Content > Certificates.
When you boot the computer, the CMOS clock gets copied as the system
clock maintained separately by the OS. So, it is possible for the
CMOS and OS clocks to get out of sync when leaving the computer on
for long periods. When was the last time you booted your computer?
No, not from hibernate mode, but a cold boot that loads the OS from
scratch. While there is a clock sync function in Windows, it doesn't
run too often. I think it runs when you log into a Windows account
(when in a domain, but perhaps not for a local login) and at
intervals specified by registry settings (I think the default is 1
week). A problem is Windows is, by default, configured to connect to Microsoft's NTP (Network Time Protocol) server, and that one gets
very busy with the vast majority of Windows users trying to connect
to the same server. Servers don't have infinite resources, so an NTP
connect request can get rejected which means the time sync won't be
until the next login or update interval, and the reject can have
multiple times, and sequentially, so it could be many weeks before
you can connect to their NTP server. That's why some folks will do a registry edit to add other NTP servers, and pick a different on in
the Time wizard. However, within whatever results in the actual
interval between time syncs, you can run software that so overloads
the OS that it doesn't get the time to update its internal clock
resulting in the clock slowing down. The high CPU load for a long
time will result in slowed updates to the internal clock, so its gets
behind.
With the overly long sync intervals for the time service included in
Windows, and because a heavily loads CPU can result in a lag in clock updates, many users employ 3rd party atomic clock updaters. Those
connect to tier 3 NTP servers to get their atomic clock time. Tier 1
is reserved for sync between the primary NTP servers. Tier 2 are
rarely available to consumers. So, you hunt for Tier 3 NTP servers
that are both free and available for public access. Many
universities operate their own tier 2 NTP server to get it sync'ed,
and allow tier 3 access to it by consumers. You want to find an NTP
server that is logically close (lowest delay) which might be the
nearest one physically, but sometimes a farther away NTP server has
less lag. There are lots of atomic clock apps for Windows. I
remember using Socketwatch awhile back before I found how to edit the registry to add the university's NTP server to add it to the list to
let me select it in the Time setting dialog.
The default was to use time.windows.com for the NTP server, but the
vast majority of Windows users are hitting that server. Then I
changed to time.nist.gov for the NTP server. At one time, I used an
atomic clock app (SocketWatch), but I found the registry edits needed
to shorten the update interval down to 1 day. Then I changed to us.pool.ntp.org as the NTP server. I'm in the US, so I used that
pool to find the closest NTP server in my area although I could even
narrow it further to a region in the USA. You can see the hierarchy
of how NTP servers are group by county, region, and more granular at:
https://support.ntp.org/bin/view/Servers/NTPPoolServers
Have you yet purged all the browsing data in Chrome? Select to purge everything except any cached passwords. Other suggestions that I can
think of is to disable all extensions in Chrome, and restart Chrome
to retest, or start Chrome in its safe mode which eliminates the
extensions, or to start with a new profile in Chrome.
https://pureinfotech.com/add-new-user-profiles-google-chrome/ (I
haven't used Chrome in a few years to know this process is the same.)
A new profile won't have the extensions installed in your old
profile, but it also has none of the tweaked config settings in your
old profile. You start with a clean slate.
If Chrome's safe mode or a new profile don't help, my next suggestion
is to start Windows XP in its safe mode. Possibly something you load
on Windows start or upon Windows login interferes with Chrome seeing
the system clock's correct time, but doesn't interfere with your
other web browsers on the same host seeing the system clock's time.
SSL was found to be insecure, so TLS ensued. However, SSL3.0 and
TLS1.0 are mostly just name changes. SSL3.0 and TLS1.0 are exactly
the same except the handshaking sequence changed, so TLS1.0 became incompatible with SSL3.0. Just as SSL3.0 was considered vulnerable,
so it TLS1.0, so then came TLS2.0 and TLS3.0. Sites are moving to
TLS3.0, and may not even support earlier 2.0 and 1.0 versions. That
means you won't be able to connect to TLS3.0 sites that don't allow
fallback to 2.0 or 1.0. Does Internet Properties show TLS2.0 and/or
TLS3.0 are available, and enabled?
Well spotted. My clock sync is disabled because the displayed time
accurate enough for me and it doesn't drift enough to affect my
personal use. I hadn't realised accurate system time is used for
anything. I re-synced the time and briefly saw the standard Google
search screen before it goes to the error message I mention. So no
progress with the problem.
All the browsers are on the same machine. Yet only Chrome gets this
glitch. I thought maybe Chrome has its own security certificates and
ignores the system certificates but a look at Chrome's settings shows
a the very same dialogue and entries as "inetcpl.cpl" Internet
Properties
One offending site is http://english.stackexchange.com but I don't
know how to check which security protocols it uses. If my problem is
not to do with a certificate (as indicated by the error message) then
perhaps the choice of actual security protocols which you mention are
the issue.
This problem on Chrome only happens on some sites and not others.
Am running Chrome v.49 as it is the last version which runs on XP.
Many sites give the following error which suggests a problem with
security certificates:
NET::ERR_CERT_DATE_INVALID
Your clock is ahead
A private connection to english.stackexchange.com can't be
established because your computer's date and time (Monday, 17
January 2022 at 09:33:31) are incorrect.
To establish a secure connection, your clock needs to be set
correctly. This is because the certificates that websites use to
identify themselves are only valid for specific periods of time.
Since your device's clock is incorrect, Google Chrome cannot verify
these certificates.
It is not occurring with other browsers (eg Firefox v.52 or MyPal).
What steps in XP or Chrome are needed to renew the certificates and
where are they obtained?
Also XP's "Internet Properties" dialogue (inetcpl.cpl) shows SSL2.0 and >SSL3.0 are disabled and TLS1.0 is enabled. Is this correct?
Pamela <pamela.private.mailbox@gmail.com> wrote:
Well spotted. My clock sync is disabled because the displayed time
accurate enough for me and it doesn't drift enough to affect my
personal use. I hadn't realised accurate system time is used for
anything. I re-synced the time and briefly saw the standard Google
search screen before it goes to the error message I mention. So no
progress with the problem.
Every HTTPS web site? Or with a specific subset of them?
Which anti-malware program are you using? Some allow interrogating
your HTTPS web traffic looking for malicious content, but that
requires a MITM (Man In The Middle) scheme that has your web browser
use their transparent proxy to use its locally stored certificate (to complete the client's HTTPS connect to the proxy), and the AV's proxy
makes the HTTPS connect to the server. If the AV's certificate
expires, you can't make HTTPS connects from the client to their
proxy. Sometimes a new version of an AV is to primarily deliver a
new certificate to replace their soon-to-expire certificate. Since
some AVs work via BHOs (Browser Helper Objects) or extensions, a
problem with the AV's cert would exhibit only within those web
browser using that AV's BHO/extension.
Check your AV's config to see if you can disable its HTTPS
interrogation of your web traffic. Then retest after exiting and
reloading the web browser.
All the browsers are on the same machine. Yet only Chrome gets this
glitch. I thought maybe Chrome has its own security certificates and
ignores the system certificates but a look at Chrome's settings
shows a the very same dialogue and entries as "inetcpl.cpl" Internet
Properties
No, that's Mozilla's Firefox that has its own internal certificate
store. That's why programs the install their own cert to allow MITM
schemes have to not only install their cert into the global
certificate store of the OS (use certmgr.msc to see those), but also
install their cert into Firefox's internal or private cert store.
Chrome uses the OS global cert store. Mozilla has never explained
why they want to wrest control of certs away from the OS. Yes, they
are cross-platform, but the other OS platforms have their own global
cert store. Perhaps Mozilla didn't write the platform-specific code
to use the APIs of an individual platform to access the global cert
store. Yet there are many parts of Firefox that are different in
code to support different platforms. You can't just take Firefox for
Linux to copy over to Windows to run it there.
Chrome, however, is more picky about the definition of certificates.
Firefox, and other web browsers, may allow a sloppily defined cert,
but Chrome may not. For example, a cert defined for use on multiple
domains requires a specific data field that could be missing or not
identify the same multiple domains. Firefox would allow the cert,
but Chrome would puke on it (however, my recollection is the error
from Chrome was different than what you cite, like something about an
invalid cert).
One offending site is http://english.stackexchange.com but I don't
know how to check which security protocols it uses. If my problem is
not to do with a certificate (as indicated by the error message)
then perhaps the choice of actual security protocols which you
mention are the issue.
This problem on Chrome only happens on some sites and not others.
StackExchange.com uses LetsEncrypt for their CA (Certificate
Authority). I remember Chrome having problems with how those certs
were defined, and complained there were invalid. Been too long to
remember the specifics, only that Chrome and LetsEncrypt weren't
friendly awhile back. For example, the Owner field in LetsEncrypt
certs is undefined. Well, their free, so no way to "follow the
money". The way LetsEncrypt certs work to validate the owner of a
cert is to require the owner to deploy the LetsEncrypt at their site,
and then have LetsEncrypt validate where the cert got used (https://letsencrypt.org/docs/challenge-types/).
When I look at the details of the LetsEncrypt cert used by the
StackExchange site, it is a TLS 1.2 cert. You mentioned TLS 1.0 was
enabled in your web client (but SSL 3.0 was disabled), but not if
there were later versions of TLS that were available and enabled,
like TLS 1.1 and 1.2.
https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome& version=49&platform=XP%20SP3&key=136
That says Chrome 49 supports TLS 1.0 and 1.1 (not recommended as they
are vulnerable) and also 1.2, but not 1.3. That means eventually you
can't use HTTPS as many sites will migrate to the later encryption
version (1.3) to provide more secure connections. However, the
LetsEncrypt cert at StackExhange is using TLS 1.2 which the ssllabs
site says your client supports, but it must be enabled in your
client. Their LetsEncrypt cert is using the TLS_ECDE_RSA_WITH_AES_128_GGM_SHA256 cipher for a 128-bit key under
the TLS 1.2 protocol. According to ssllabs, your Chrome 49 supports
that cipher. To check TLS 1.2 is enabled in Chrome, see:
https://knowledge.digicert.com/generalinformation/INFO3297.html
I haven't used Windows XP since about 2004, or maybe a bit earlier.
I don't have a WinXP host on which to check if that old OS supports
TLS 1.2, so I have to hunt around the web to check.
https://www.emailarchitect.net/easendmail/sdk/html/object_tls12.htm
or
https://www.smartftp.com/en-us/support/kb/2754
That makes it look like you have several hurdles to get WinXP to
support TLS 1.2 which is what the StackExchange site cert uses. With
jumping through the hoops, apparently Windows XP only supports up to
TLS 1.0; see:
https://sockettools.com/kb/support-for-tls-1-2-on-windows-xp/
It's your choice if you want to hack at WinXP to add TLS 1.1 and 1.2
support.
To validate a cert, the client has to look at the CA for it to either
get the CRL (Certificate Revocation List) to see if the cert is not
expired and not revoked (you client gets the CRL list to check
status), or request the server to do the lookup (OCSP: Online
Certificate Status Protocol). If your web client cannot reach the
CA's CRL server, or to submit OCSP requests to the CA's server fail
(error, invalid request, unreachable server), it cannot validate the
cert, so it gets rejected. StackExchange's LetsEncrypt cert specifies "Authority Info: Method = OCSP" using http://r3.o.lencr.org".
When looking at client-side StackExchange's site cert, it is valid
from 4 Jan 2022 to 4 Apr 2022. Wow, that's a very short validity
range for a site cert. I think 3 months is the minimum duration you
can get for a cert. It is a multiple domain cert, but
stackexchange.com is one of them.
When you run certmgr.msc, you should find the LetsEncrypt client-side
CA or master cert under Certificates Current User -> Intermediate Certification Authority -> Certificates as "Let's Encrypt Authority
X3". They're not a traditional CA, so they can't be a root CA, only
an intermediate CA. certmgr.msc shows the global cert store of the
OS that Chrome uses (as well as most web browser except the Firefox variants). LetsEncrypt also has their "R3" cert, but that expired
back on Sept 19, 2021. The "Let's Encrypt Authority X3" client-side
cert is also expired back on March 17, 2021. Hmm, so just who is the
client using to validate the LetsEncrypt site cert? Since
LetsEncrypt is an intermediate CA, I noticed its "Let's Encrypt
Authority X3" and "R3" CA certs were issued by DST. I think that's
the one under Certificates -> Trusted Root -> Certificates as "DST
Root CA X3". Argh, that one's expired, too! Okay, I give up on
checking validity of the local and site certs. Oh wait, one more to
check. The LetsEncrypt site cert for StackExchange also shows ISRG
Root X1 as the root CA. That one is under Certificates -> Trusted
Root -> Certs as "ISRG Root X1", and it is not expired (valid from
6/4/2015 to 6/4/2035). Finally a root CA that LetsEncrypt uses as an intermediate CA.
So, I could find nothing wrong with StackExchange's LetsEncrypt site certificate. I'm not certificate expert, so I double checked by
going to https://www.ssllabs.com/ssltest/, entering the site you
mentioned (english.stackexchange.com), and let ssllabs have at 'em.
After waiting 6 minutes, the site cert got an A+ rating. Since
Chrome is more bitchy about the definition of certs is perhaps why it complains when the other web browsers do not that are more sloppy,
er, more tolerant. I've yet to find a problem with the site cert.
Booting Windows XP into its Safe Mode (with networking so you can
retest Chrome) is far easier than, say, Windows 10. Testing Chrome
in Windows' Safe Mode is not "going to be painfully slow".
However, as noted near the beginning, doesn't look like Windows XP
natively supports TLS 1.2 to handle StackExchange's site certificate
unless you hack Windows XP trying to get it to support TLS 1.2. Even
for yourself, stuff stops working right when you get old. Firefox
(and MyPal which is an early fork of Firefox) probably still works,
because it uses its own private cert store. Plus Firefox supported
TLS 1.2 way back to version 23. In Firefox, go to about:config, and
search on security.tls.version.max. My FF 97 on Windows 10 shows "4"
which means TLS 1.3; see
http://kb.mozillazine.org/Security.tls.version.* (alas, the site went
dead a couple years ago, so it doesn't get updated, but much of the
info is still valid). You'll have to dump the Chrome web browser.
Cleanup of remnant files and registry files is a huge mess if you
want to really eradicate Chrome from your computer.
Pamela <pamela.private.mailbox@gmail.com> wrote:
Well spotted. My clock sync is disabled because the displayed time
accurate enough for me and it doesn't drift enough to affect my
personal use. I hadn't realised accurate system time is used for
anything. I re-synced the time and briefly saw the standard Google
search screen before it goes to the error message I mention. So no
progress with the problem.
Every HTTPS web site? Or with a specific subset of them?
Which anti-malware program are you using? Some allow interrogating
your HTTPS web traffic looking for malicious content, but that
requires a MITM (Man In The Middle) scheme that has your web browser
use their transparent proxy to use its locally stored certificate (to complete the client's HTTPS connect to the proxy), and the AV's proxy
makes the HTTPS connect to the server. If the AV's certificate
expires, you can't make HTTPS connects from the client to their
proxy. Sometimes a new version of an AV is to primarily deliver a
new certificate to replace their soon-to-expire certificate. Since
some AVs work via BHOs (Browser Helper Objects) or extensions, a
problem with the AV's cert would exhibit only within those web
browser using that AV's BHO/extension.
Check your AV's config to see if you can disable its HTTPS
interrogation of your web traffic. Then retest after exiting and
reloading the web browser.
All the browsers are on the same machine. Yet only Chrome gets this
glitch. I thought maybe Chrome has its own security certificates and
ignores the system certificates but a look at Chrome's settings
shows a the very same dialogue and entries as "inetcpl.cpl" Internet
Properties
No, that's Mozilla's Firefox that has its own internal certificate
store. That's why programs the install their own cert to allow MITM
schemes have to not only install their cert into the global
certificate store of the OS (use certmgr.msc to see those), but also
install their cert into Firefox's internal or private cert store.
Chrome uses the OS global cert store. Mozilla has never explained
why they want to wrest control of certs away from the OS. Yes, they
are cross-platform, but the other OS platforms have their own global
cert store. Perhaps Mozilla didn't write the platform-specific code
to use the APIs of an individual platform to access the global cert
store. Yet there are many parts of Firefox that are different in
code to support different platforms. You can't just take Firefox for
Linux to copy over to Windows to run it there.
Chrome, however, is more picky about the definition of certificates.
Firefox, and other web browsers, may allow a sloppily defined cert,
but Chrome may not. For example, a cert defined for use on multiple
domains requires a specific data field that could be missing or not
identify the same multiple domains. Firefox would allow the cert,
but Chrome would puke on it (however, my recollection is the error
from Chrome was different than what you cite, like something about an
invalid cert).
One offending site is http://english.stackexchange.com but I don't
know how to check which security protocols it uses. If my problem is
not to do with a certificate (as indicated by the error message)
then perhaps the choice of actual security protocols which you
mention are the issue.
This problem on Chrome only happens on some sites and not others.
StackExchange.com uses LetsEncrypt for their CA (Certificate
Authority). I remember Chrome having problems with how those certs
were defined, and complained there were invalid. Been too long to
remember the specifics, only that Chrome and LetsEncrypt weren't
friendly awhile back. For example, the Owner field in LetsEncrypt
certs is undefined. Well, their free, so no way to "follow the
money". The way LetsEncrypt certs work to validate the owner of a
cert is to require the owner to deploy the LetsEncrypt at their site,
and then have LetsEncrypt validate where the cert got used (https://letsencrypt.org/docs/challenge-types/).
When I look at the details of the LetsEncrypt cert used by the
StackExchange site, it is a TLS 1.2 cert. You mentioned TLS 1.0 was
enabled in your web client (but SSL 3.0 was disabled), but not if
there were later versions of TLS that were available and enabled,
like TLS 1.1 and 1.2.
https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome& version=49&platform=XP%20SP3&key=136
That says Chrome 49 supports TLS 1.0 and 1.1 (not recommended as they
are vulnerable) and also 1.2, but not 1.3. That means eventually you
can't use HTTPS as many sites will migrate to the later encryption
version (1.3) to provide more secure connections. However, the
LetsEncrypt cert at StackExhange is using TLS 1.2 which the ssllabs
site says your client supports, but it must be enabled in your
client. Their LetsEncrypt cert is using the TLS_ECDE_RSA_WITH_AES_128_GGM_SHA256 cipher for a 128-bit key under
the TLS 1.2 protocol. According to ssllabs, your Chrome 49 supports
that cipher. To check TLS 1.2 is enabled in Chrome, see:
https://knowledge.digicert.com/generalinformation/INFO3297.html
I haven't used Windows XP since about 2004, or maybe a bit earlier.
I don't have a WinXP host on which to check if that old OS supports
TLS 1.2, so I have to hunt around the web to check.
https://www.emailarchitect.net/easendmail/sdk/html/object_tls12.htm
or https://www.smartftp.com/en-us/support/kb/2754
That makes it look like you have several hurdles to get WinXP to
support TLS 1.2 which is what the StackExchange site cert uses. With
jumping through the hoops, apparently Windows XP only supports up to
TLS 1.0; see:
https://sockettools.com/kb/support-for-tls-1-2-on-windows-xp/
It's your choice if you want to hack at WinXP to add TLS 1.1 and 1.2
support.
To validate a cert, the client has to look at the CA for it to either
get the CRL (Certificate Revocation List) to see if the cert is not
expired and not revoked (you client gets the CRL list to check
status), or request the server to do the lookup (OCSP: Online
Certificate Status Protocol). If your web client cannot reach the
CA's CRL server, or to submit OCSP requests to the CA's server fail
(error, invalid request, unreachable server), it cannot validate the
cert, so it gets rejected. StackExchange's LetsEncrypt cert specifies "Authority Info: Method = OCSP" using http://r3.o.lencr.org".
When looking at client-side StackExchange's site cert, it is valid
from 4 Jan 2022 to 4 Apr 2022. Wow, that's a very short validity
range for a site cert. I think 3 months is the minimum duration you
can get for a cert. It is a multiple domain cert, but
stackexchange.com is one of them.
When you run certmgr.msc, you should find the LetsEncrypt client-side
CA or master cert under Certificates Current User -> Intermediate Certification Authority -> Certificates as "Let's Encrypt Authority
X3". They're not a traditional CA, so they can't be a root CA, only
an intermediate CA. certmgr.msc shows the global cert store of the
OS that Chrome uses (as well as most web browser except the Firefox variants). LetsEncrypt also has their "R3" cert, but that expired
back on Sept 19, 2021. The "Let's Encrypt Authority X3" client-side
cert is also expired back on March 17, 2021.
Hmm, so just who is the client using to validate the LetsEncrypt site
cert? Since LetsEncrypt is an intermediate CA, I noticed its "Let's
Encrypt Authority X3" and "R3" CA certs were issued by DST. I think
that's the one under Certificates -> Trusted Root -> Certificates as
"DST Root CA X3". Argh, that one's expired, too! Okay, I give up on checking validity of the local and site certs. Oh wait, one more to
check. The LetsEncrypt site cert for StackExchange also shows ISRG
Root X1 as the root CA. That one is under Certificates -> Trusted
Root -> Certs as "ISRG Root X1", and it is not expired (valid from
6/4/2015 to 6/4/2035). Finally a root CA that LetsEncrypt uses as an intermediate CA.
So, I could find nothing wrong with StackExchange's LetsEncrypt site certificate. I'm not certificate expert, so I double checked by
going to https://www.ssllabs.com/ssltest/, entering the site you
mentioned (english.stackexchange.com), and let ssllabs have at 'em.
After waiting 6 minutes, the site cert got an A+ rating. Since
Chrome is more bitchy about the definition of certs is perhaps why it complains when the other web browsers do not that are more sloppy,
er, more tolerant. I've yet to find a problem with the site cert.
Booting Windows XP into its Safe Mode (with networking so you can
retest Chrome) is far easier than, say, Windows 10. Testing Chrome
in Windows' Safe Mode is not "going to be painfully slow".
However, as noted near the beginning, doesn't look like Windows XP
natively supports TLS 1.2 to handle StackExchange's site certificate
unless you hack Windows XP trying to get it to support TLS 1.2. Even
for yourself, stuff stops working right when you get old. Firefox
(and MyPal which is an early fork of Firefox) probably still works,
because it uses its own private cert store. Plus Firefox supported
TLS 1.2 way back to version 23. In Firefox, go to about:config, and
search on security.tls.version.max. My FF 97 on Windows 10 shows "4"
which means TLS 1.3;
see http://kb.mozillazine.org/Security.tls.version.* (alas, the site
went dead a couple years ago, so it doesn't get updated, but much of
the info is still valid). You'll have to dump the Chrome web
browser. Cleanup of remnant files and registry files is a huge mess
if you want to really eradicate Chrome from your computer.
Pamela, look at my old thread "Invalid certificate". It might be useful.
GF
How did you solve your situation?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 88:07:13 |
| Calls: | 6,658 |
| Files: | 12,203 |
| Messages: | 5,333,954 |