Logic for choosing a certificate chain during a “server-hello” message in a SSL/TLS handshake?

Question

In a client-server ssl handshake, my server sends a certificate chain back to the client in a server-hello message. But I want to understand as to how that particular certificate chain is getting selected.

My keystore has 5 chains

chain1>
privatekey (expired at let's say date1) --
intermediate or server cert (valid) --
root (valid)

chain2>
privatekey cert (valid for 6 more months)--
intermediate or server cert (valid)--
root (valid)

chain3>
privatekey cert (expired at lets say date2) --
intermediate or server cert (valid)--
root (valid)

chain4>
privatekey cert (valid for 1 year) --
intermediate or server cert (valid)--
root (valid)

chain5>
privatekey cert (expired at lets say date3) --
intermediate or server cert (valid)--
root (valid)

Now whenever a client tries to connect to my server (for a webservice) the below exception is being obtained and the client is not able to connect

sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: timestamp check failed. .................. more lines.. caused by java.security.cert.CertPathValidatorException: timestamp check failed........ more lines.. caused by java.security.cert.CertPathValidatorException: NotAfter : date1

Tried reconnecting but again the same error with date2 this time. Now this was not happening earlier even when there were expired certs in my keystore.

Can anyone explain as to how the certificate chain gets selected in the server hello message? I tried researching a lot but couldn't get something concrete

Answer 1

It's not 'impossible to answer', contrary to what you've been told in comments.

1. A certificate is chosen which satisfies the signers, cipher suites, and protocols supplied by the client in the ClientHello message.
2. If there is a choice, if you've installed a KeyManager, that's in control: otherwise, JSSE is in control and it isn't further specified.