Certificate verification status TimeNotNested and TlsException

Question

We are using Rebex HTTPS Legacy 2019R3.3 in different Windows Embedded Handheld 6.5.3 devices. One one device with an older firmware, probably without Windows-integrated SHA-2 support, we found these lines in the Rebex log file:

15:53:58 INFO HttpRequest(3) HTTP: Connecting to 'https://api.reservix.de:443'...
15:54:02 INFO HttpRequest(3) TLS: Negotiating TLS 1.2, RSA with ephemeral ECDH, AES with 128-bit key in GCM mode, AEAD.
15:54:13 INFO HttpRequest(3) TLS: Certificate verification status: TimeNotNested (0x00000008)
15:54:13 INFO HttpRequest(3) TLS: Alert Alert:Alert was sent.
15:54:13 ERROR HttpRequest(3) HTTP: Error while sending request: Rebex.Net.TlsException: Server certificate was rejected by the verifier because of other problem. ---> Rebex.Net.TlsException: Server certificate was rejected by the verifier because of other problem.
at xube.ybwr(String ayv, CertificateChain ayw)
at xube.ybwt(Byte[] azb, Int32 azc, Int32 azd, xuam aze)
at xube.ybxf(Byte[] bjj, Int32 bjk, Int32 bjl)
at xubb.krpi(Byte[] atg, Int32 ath, Int32 ati)
at xubb.krpn()
at xubb.krpu()
at Rebex.Net.TlsSocket.Negotiate()
at xtvj.lxrx(String bke, Int32 bkf, Boolean bkg)
at qhio.lxre()
at qhio.lxri(Boolean aj)
at qhio.lxrk()
at Rebex.Net.HttpRequest.mxyh()
at Rebex.Net.HttpRequest.bjwi.pwjx()
at qhvi.rnjr(Object ejo)
at qhyj.aucr.xyrn()
at qhwo.wuib()

at xubb.krpn()
at xubb.krpu()
at Rebex.Net.TlsSocket.Negotiate()
at xtvj.lxrx(String bke, Int32 bkf, Boolean bkg)
at qhio.lxre()
at qhio.lxri(Boolean aj)
at qhio.lxrk()
at Rebex.Net.HttpRequest.mxyh()
at Rebex.Net.HttpRequest.bjwi.pwjx()
at qhvi.rnjr(Object ejo)
at qhyj.aucr.xyrn()
at qhwo.wuib()

The connection cannot be established due to the TlsException with the strange reason Server certificate was rejected by the verifier because of other problem.

Is this exception and reason related to the certificate verification status TimeNotNested mentioned two lines before?

The documentation describes this status as

Certificates in the chain are not properly time nested.

What does not properly nested mean?

Do you need more information? Unfortunately, we cannot enable debug logging on this device or try the newer Rebex HTTPS Legacy version 2019R3.5 at the moment.

Additional off-topic question: Will there be an update to Rebex HTTPS Legacy in the next weeks (with changes from Rebex HTTPS 2020R4)?

Answer 1

"Not properly time nested" means that the validity period of a certificate in the chain is not within the validity period of it's signing certificate. So, for example, if a CA certificate is valid between 2015-01-01 and 2020-01-01, it is not supposed to sign certificates with end of validity beyond 2020-01-01. Doing so would cause certificate validation to fail with TimeNotNested error.

In your, case, there apparently exist two variants of Amazon's "CN=Amazon Root CA 1, O=Amazon, C=US" certificate. Both have the same subject name and public key, which means one is actually supposed to be a replacement for an earlier one. One of these certificates (likely an older version) has a validity period from ‎2015-05-26 to 2038-01-17 and it is self-signed, while the other one is an intermediate CA certificate valid from 2015-05-25 to 2037-12-31 and signed by "CN=Starfield Services Root Certificate Authority - G2, O=Starfield Technologies, Inc., L=Scottsdale, S=Arizona, C=US".

However, Starfield certificate's validity period is 2009-09-02 to 2034-06-28, which means the nesting is invalid.

Furhermore, there to make the matter even more complicated, there is another intermediate CA certificate in api.reserix.de's certificate chain, again in two interchangeable variants, with subject of "CN=Amazon, OU=Server CA 1B, O=Amazon, C=US", which is signed by "CN=Amazon Root CA 1, O=Amazon, C=US" (see above). One variant has a validity period from 2015-10-22 to 2025-10-19, the other has a validity period from 2015-10-22 to 2040-10-22. So again, the second variant would cause invalid nesting error.

I have uploaded a ZIP file containing the two alternative chains in case you would like to have a look:

• alternative-amazon-chains.zip

So this actually looks like a mess-up on Amazon's and Starfield's part. Strangely, Windows certificate validation API does not mind, and validate the chain as valid. However, on Windows CE, we use a custom certificate validator, which is more strict.

Fortunately, the nesting check can easily be disabled using IgnoreTimeNotNested option. Example:

var client = new WebClient();
client.Settings.SslServerCertificateValidationOptions |= ValidationOptions.IgnoreTimeNotNested;
client.DownloadString("https://api.reservix.de/...");

(Similar option is available for HttpReqeustCreator.Settings.)

---

There will be an update for legacy Rebex HTTPS in November. If there are some new features you would like to have earlier, we can provide a custom build in the meantime.

Comments

Thank you very much for the fast response and detailed explanation! We have decided to set the option `IgnoreTimeNotNested` as recommended.

However, we do not understand, why we are able to connect to `api.reservix.de` on other devices without any error message. On those devices we run the same Rebex HTTPS version and settings, but a newer firmware version (AKU 6.5.3.12.48 vs. 6.5.3.12.15).

---

I guess those other devices might end up with a different certificate chain, which happens to validate fine. If you would like to look into this, save the chain on one of the other devices to a file (and check it out or mail it to us). You might use code such as this
            var client = new WebClient();
            client.ValidatingCertificate += (s, e) =>
            {
                e.CertificateChain.Save("/Storage Card/api_reservix.p7b");
                var result = e.CertificateChain.Validate(e.ServerName, client.Settings.SslServerCertificateValidationOptions);
                if (result.Valid)
                    e.Accept();
                else
                    e.Reject(result.Status);
            };
            client.DownloadString("https://api.reservix.de/");