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