Understanding DST Root expiry and the older default cert chain

[MikeMcQ]

@psykid

Queries:

1. How do servers know which chain to vend (I am assuming they can vend whatever chain they want)? Or is it on the client side to ask for specific chain?
   A: Server admin chooses chain to send in server config
2. If its on the client side to ask for the type of chain (which I don't think it is), is there a sample c/c++ client code?
   A: n/a
3. If the servers only vend "New default chain", how would non-android devices work (since #3 above applies only for android).
   A: They see ISRG Root X1 in the chain, if in their CA trust store they can trust the chain. This cert was issued over 5 years ago so is common in trust stores.
4. In the "New default chain", since the root CA is still DST Root (which already expired), will calling SSL_get_verify_result on such cert cause errors? (specifically cert expired errors).
   A: Depends on openssl version, or in your case BoringSSL which is a fork of openssl.
5. How is removing the DST root cert from the device is working? How can the system validate the cert without the root with which it got signed? (fyi, I used SSL_CTX_load_verify_locations and gave the /etc/security/cacerts-sha1 as the ca certs folder, so even if there is another file in the system I dont think it should matter).
   A: See A to #3

Also see:

Production Chain Changes

M…

Previously posted by petercooperjr but related to Q #4

Old Let's Encrypt Root Certificate Expiration and OpenSSL 1.0.2 - OpenSSL Blog