Updating internet security certificates on XP

[Pamela]

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?

[VanguardLH]

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.

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?

[G.F.]

"VanguardLH" <V...@nguard.LH> ha scritto nel messaggio
news:2bswduyy06vy$.dlg@v.nguard.lh...

> ...

I think Pamela wanted a shorter answer ...

[MikeS]

See if this helps:
https://msfn.org/board/topic/175170-root-certificates-and-revoked-certificates-for-windows-xp/

[Mayayana]

"Pamela" <pamela.priv...@gmail.com> wrote

| Also XP's "Internet Properties" dialogue (inetcpl.cpl) shows SSL2.0 and
| SSL3.0 are disabled and TLS1.0 is enabled. Is this correct?

That's only for IE and related system libraries. Other browsers
don't use that. I think it's probably using TLS1.1, anyway, but
older IE can't show that. (Internet Properties is basically IE.)

There's an update to TLS1.2 support for XP/Vista/7 ( on XP
it requires spoofing your computer as a kiosk system) but you
probably don't need it.
It would only be relevant if you're using software that uses the
Windows cryptography API. (I happened to run across this because
I was using the system winhttp library in my software.)

[Pamela]

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.

> 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.

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
> 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.

Long ago I added additional time servers to the ones which came with
XP. I'm in the UK and have chosen a time server ("xs4all") in the
Netherlands which is relatively close.

All non-settings data in Chrome has been purged. It has no plugins
and this problem occurs even when I disable the user profile and browse
anonymously.

> 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.

Checking through this in Safe Mode is going to be painfully slow. :(

> 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?

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.

[VanguardLH]

Pamela <pamela.priv...@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.

[Mayayana]

"VanguardLH" <V...@nguard.LH> wrote

| 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.
|

See my post below. But as far as I know it doesn't
matter. Browsers pack their own encryption libraries.
What's supported on Windows relates to using Windows
libraries.

[G.F.]

Pamela, look at my old thread "Invalid certificate". It might be useful.

GF

[Pamela]

On 13:25 19 Jan 2022, G.F. said:
>
> Pamela, look at my old thread "Invalid certificate". It might be useful.
>
> GF

It's a useful thread. Thank you.

I found it at MID: <sj74e2$15s4$1...@gioia.aioe.org>

I notice the same "letsencrypt" certificates as I had trouble with were
mentioned, although I have a hunch the problem exists with a wide range of
certificates than that.

How did you solve your situation?

[Pamela]

On 23:42 17 Jan 2022, VanguardLH said:
> Pamela <pamela.priv...@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.

This problem still occurs with my AV's file shield and web shield
disabled. (It's Avast v.10, the latest version my XP can run.)

I'm not familiar with security certificates and had hoped I could solve
my original problem simply by importing up-to-date certificates from
some trusted site (perhaps on a browser by browser basis if necessary).
Wouldn't this work? It saves the detailed configurations work you
mention below.

That web page lists SSL 2.0, SSL 3.0, TLS 1.0, TSL 1.1, TLS 1.3.

However, my Chrome v49 shows only SSL 2.0, SSL 3.0 and TLS 1.0 in total
... and only TLS 1.0 is enabled.

> 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.

My XP system has become a bit too fragile and it's also too important
to justify registry hacks that might cause problems. In the past I make
a lot of registry changes but now need to be more careful. Backing up
the registry or even whole system partition (and then testing to see if
there isn't a problem with XP stability) isn't worth it.

> 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.

On my system, the "Let's Encrypt Authority X3" certificate is present
with an expiration date of 17 Mar 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.

In certmgr.msc > "Trusted Root Certification Authorities" >
"Certificates", there is no "ISRG Root X1" entry. (The path I have
within certmgr.msc is very slightly different to what you wrote but it
looks to be effectively the same.

> 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".

Safe Mode screws up my monitor settings plus I have 16 virtual desktops
(via Dexpot) with over 100 icons that don't all go back into place
correctly.

> 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;

My Firefox "security.tls.version.max" has a value of "3" ... which is
TLS 1.2.

> 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.

Chrome is okay left where it is on my system. My XP isn't going to last
a lot longer and I expect to migrate it when I have the time and energy
but there are so many application (and system) settings over nearly two
decades since I installed it in 2003.

The answer to the certificate problem might be to install a browser
which has all this configured. The Serpent browser is mentioned in
another thread here about XP ceriticates (MID:
<sj74e2$15s4$1...@gioia.aioe.org>) Serpent was mentioned and that's a
replacement candidate. It runs the site I had trouble with.

https://www.basilisk-browser.org/

[G.F.]

"Pamela" <pamela.priv...@gmail.com> ha scritto nel messaggio
news:XnsAE2977C...@144.76.35.252...

> How did you solve your situation?

Unfortunately I still haven't solved it.

GF

[Mayayana]

"G.F." <nos...@grazie.it> wrote

|
| Unfortunately I still haven't solved it.
|

I've never entirely understood how all of this works. For
what it's worth, you can try some things. But I have 2 XP boxes
here and only one has had these updates. Neither has ever
had cert problems. Occasionally I get cert errors but they're
nearly always due to a small website piggybacking on a
sever's cert, so the names don't match and I have to tell
FF/New Moon to make an exception.

Here's the first link, for updated certs:

https://msfn.org/board/topic/175170-root-certificates-and-revoked-certificates-for-windows-xp/

It's a bit involved, but the instructions are clear. As far as
I know, these updates are only for Windows. I wouldn't
expect them to apply to Firefox, but as I said, I don't entirely
understand how this works.

Second link. This is to update TLS support to 1.2 On XP,
run this .reg file:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.1\Client]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.1\Server]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Client]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Server]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\WPA\PosReady]
"Installed"=dword:00000001

Watch for wordwrap. On Vista/7 you can run the same thing without
the POSReady entry, which enables XP to install the update.

Then download and install this update for XP:

http://download.windowsupdate.com/c/msdownload/update/software/updt/2017/10/windowsxp-kb4019276-x86-embedded-enu_3822fc1692076429a7dc051b00213d5e1240ce3d.exe

Win7 versions:

Win7-64-bit:

http://www.download.windowsupdate.com/c/msdownload/update/software/updt/2016/04/windows6.1-kb3140245-x64_5b067ffb69a94a6e5f9da89ce88c658e52a0dec0.msu

Win7-32-bit:

http://www.download.windowsupdate.com/c/msdownload/update/software/updt/2016/04/windows6.1-kb3140245-x86_cdafb409afbe28db07e2254f40047774a0654f18.msu

If those direct links don't work, you can try here:

http://catalog.update.microsoft.com/v7/site/search.aspx?q=kb3140245

---------------------------------

Why update TLS support? Because each version eventually gets
compromised. XP only supports TLS 1.0. I think Vista/7 is the same.
Eventually 1.0 won't be considered adequate. I don't know whether
that affects certs. Also, I would expect this support to be Windows-
specific. Firefox/Chrome should be using their own up-to-date
libraries. But I'm not certain about that.

The reason I know about this is because I wrote a software program
using the winhttp system library. Winhttp does depend on Windows
support for TLS, as I presume IE, Edge and anything using wininet.dll
or urlmon.dll would depend. The IE libraries are the Windows Internet
API.

So, you can try these things. The TLS patch is nice to have, in
any case.