Certificate validation routine fails with NotTimeValid when changing time zone on Linux while client app is still running

[lukegeor]

Description

While a .Net application is running, if you change the system time zone ahead (i.e. if your current time zone is US Pacific time and you change the system time zone to US Eastern time), if your server has a newly-created TLS certificate, if the age of the certificate (not valid before date) is smaller than the amount of time you changed your time zone, certificate validation fails with a NotTimeValid error in the certificate chain.

This only occurs on Linux. I tested on Oracle Linux 8. I'm using .Net SDK 8.0.303 and runtime 8.0.7.

Reproduction Steps

See https://github.com/lukegeor/HttpsValidationTimeZone for the full demo project. A simplified explanation follows.

1. Create a new TLS cert where the not valid before date is now.
2. Launch an HTTPS server that uses that certificate.
3. Launch a HTTPS client app that repeatedly connects to this server. An important detail is that the HTTP client should be configured to re-establish its TLS connection on each request. The validation occurs during the TLS handshake, and if you re-use the HTTP connection, that handshake and thus the validation does not re-occur.
4. Change your system time zone ahead (east) by at least the age of the TLS cert.

Expected behavior

HttpClient certificate validation should succeed (or at least not fail due to time validity).

Actual behavior

HttpClient validation fails with NotTimeValid as the status of the chain element.

Regression?

No response

Known Workarounds

No response

Configuration

This only occurs on Linux. I tested on Oracle Linux 8. I'm using .Net SDK 8.0.303 and runtime 8.0.7. x64 CPU architecture. OpenSSL openssl-1.1.1k-12.el8_9.x86_64. I don't know whether this is specific to this configuration. I did not test Ubuntu, nor did I test any other CPU architecture.

Other information

No response

[Clockwork-Muse]

Change your system time zone ahead (east) by at least the age of the TLS cert.
Expected behavior
HttpClient certificate validation should succeed (or at least not fail due to time validity).

Why is your expected behavior that it should succeed? When you changed the timezone (presumably of the client), most operating systems will retain the local-time, which would have the effect of moving "forward in time" (when adjusting to a further eastward zone). This then means that the client process would consider time to be before the certificate was valid, which should cause validation to fail. Or is there something else you're expecting?

(side note: if this was wrapped up in a devcontainer you could automate the certificate creation via a bash script)

[lukegeor]

These kinds of timestamp comparisons should always be done with UTC timestamps (or at the very least the same time zone). The not valid before and not valid after dates on certificates are represented with UTC timestamps. The local time zone on the system should make no difference and changing it shouldn't affect any validation logic. 10 am eastern and 9 am central are the same time. The only exception is whn you're dealing with an operation that's specifically local time dependent like an alarm clock.

Also, if the code were actually supposed to behave like you say, then moving the time zone west, not east, would cause this validation error. In other words, if my computer said 10 am eastern and the not valid before time on the cert was 9:30 am, changing my time zone to central time, or 9 am, would be what caused this failure if we were using local times. But it's moving the time zone east that causes the problem.

Also, as I said, this problem doesn't occur on Windows.

[Clockwork-Muse]

Also, as I said, this problem doesn't occur on Windows.

Windows vs Linux might be because of how processes might handle "current timezone". But let's leave that aside for the moment.

These kinds of timestamp comparisons should always be done with UTC timestamps

They are. Your tooling is trying to be helpful to you, and display things in local time.

Also, if the code were actually supposed to behave like you say, then moving the time zone west, not east, would cause this validation error. In other words, if my computer said 10 am eastern and the not valid before time on the cert was 9:30 am, changing my time zone to central time, or 9 am, would be what caused this failure if we were using local times. But it's moving the time zone east that causes the problem.

The fundamental problem here is that the operating system is trying to help you, and in the process (probably) does something sneaky under the covers. For instance, earlier you said:

The local time zone on the system should make no difference and changing it shouldn't affect any validation logic. 10 am eastern and 9 am central are the same time.

This is correct, and the equivalent would be 14 UTC.

When you change timezone on a computer, there's a design choice to make;

• Keep local time and update UTC
• Keep UTC and update the local time

Of these, the second one is generally going to be more disruptive to the end user; it's more likely that the displayed (local) time will be correct and just the rules need to be adjusted, so instead the first behavior is used.

Which, because:
08 Central -> 09 Eastern -> 13 UTC
09 Central -> 10 Eastern -> 14 UTC

means that when you update the timezone eastward and retain the local time, the UTC time decreases (and thus puts the timestamp before the certificate start date).