Does Windows require the full certificate chain in order to trust a certificate?

Question

I'm putting together a Root CA to sign multiple intermediate CAs which will then be used to sign VPN server and VPN user certificates.

When I provide a user with their certificate, ideally I only want to give them their keypair/cert and the cert of the signing intermediate. This will mean that if the root CA is compromised that exposure should be minimal if no users trust it directly.

Upon testing the above setup, I imported the intermediate CA cert into a Windows 10 machine followed by the user cert, but the certificate has a warning on it to say "Windows does not have enough information to verify this certificate."

I assume that importing the root CA cert would then remedy that issue, but why is it that Windows requires the full chain if it's been given the issuing intermediate CA's certificate to trust certs from that?

Answer 1

The PKI is based on CA certificates, which are certificates you trust to vouch for other certificates.

You will always have a copy the certificate for the CA. Let's call it "bdxCA"

When Bob comes with a certificate saying "Hi, I'm Bob, here's my certificate signed by bdxCA", the computer looks up his copy of bdxCA, see it did sign the certificate and that it trusts bdxCA for the stated purpose (e.g. user identity).

Now come Intermediate CAs. These are certificates that are able to sign other certificates but you are not trusting directly, but whose trust derives from a "real" CA.

So, you may have bdxCA signing bdx_HR_CA which itself signs Bob certificate. Here Bob should provide both his own certificate as the intermediate one(s): "Hi, I'm Bob, here's my certificate signed by bdx_HR_CA, and you can see that one is signed by bdxCA". You check that it is indeed the case, and accept it.

If Bob hadn't provided the intermediate certificate, it might or might not be accepted. If the receiving side don't have a copy of bdx_HR_CA, they won't be able to validate it, and will thus reject it. However, it is possible that the intermediate CA was imported locally (so it will be able to find it), or perhaps Alice had already shown her own certificate as well as bdx_HR_CA one, and thus the later had been automatically stored. Moreover, in some cases certificates include a url from which the parent (intermediate) certificate can be downloaded, and certain clients are able to helpfully download them.

All of this leads to the case that when intermediate certificates are missing, they may or may not validate, depending on the software used, and the previous machine history, all of which results in inconsistent problems, as they only sometimes fail.

Then, it is also possible for a CA certificate to also be signed by another CA. This is generally done when a new CA may not be trusted by all clients. Signing the CA by another one that they do trust allows them to trust certificates emitted by this new CA (by treating it as an intermediate one).

In your case, you have imported the CA certificate, but you probably haven't marked it as trusted, so Windows doesn't have a route to a trusted CA to verify it.

Finally, as your use case is about at VPN server and VPN user certificates, please note that these generally use their own CA, with the server CA provided within the VPN configuration. In which case, it doesn't matter if it's trusted by windows or not, as the VPN client will simply check if the VPN certificate is the one it is expecting it to be.

Answer 2

This will mean that if the root CA is compromised that exposure should be minimal if no users trust it directly.

The above doesn't make sense. Another name for the Root CA certificate is the trust-anchor. As the anchor of trust, you must install it in order for any subordinate CAs and subsequently end-entity certificates to be trusted. If you expect the chain to start at the subordinate CA, or in other words, you expect the subordinate CA to be the trust-anchor, then what is the point of the Root CA? All you've succeeded in doing is shortening your certificate chain by one. You'll have the same envisaged problem if you compromise your subordinate CA.

If you have concerns about your Root CA being compromised (and you should do) then keep your Root CA off when not in use and never connect it to the network (use an USB-stick for example to move files). If you're still worried, invest in a Hardware Security Module to store the Root CA's private key. Even better, invest in one for your Root CA and another for your subordinate CAs.

When I provide a user with their certificate, ideally I only want to give them their keypair/cert and the cert of the signing intermediate.

That is the correct way to present the client certificate. Your VPN client will send both to the server, at which point the server will use them to build a chain to the Root CA certificate it has in its trust-anchor store. If all is well, this will verify the client.

Similarly, the server will present its certificate to you (along with any subordinate CA certificates) which your client will use to build a chain to any Root CA certificates in your trust-anchor store. If the Root CA isn't installed, there's no way for your VPN client to confirm that you've chosen to trust it.

This is mutual authentication, and two things are happening:

1. Your server sends all certificates bar the Root CA certificate to your client, which it checks against the Root CA certificate installed in your trust-anchor store.
2. Your client sends all certificates bar the Root CA certificate to your server, which it checks against the Root CA certificate installed in its trust-anchor store.