Is it possible within the limits of the X.509 specification to mark an intermediate CA as trusted for a specific purpose, e.g. to verify a VPN, HTTPS etc. server key, just like it would work with a root CA?
My VPN client(s) all have a way to explicitly provide a trusted CA certificate, which is used to verify the VPN server's authenticity. As long as I provide the root CA certificate, this works as expected - the certificate is trusted. (The intermediate certs are provided as part of the TLS handshake.)
However, I'm using an intermediate CA, and would very much like to provide that certificate, instead of the root CA. In my understanding of X.509, that should work:
The VPN server's key is signed by the intermediate CA, and as far as I understand X.509, that's all that is required to establish a trusted chain.
But in practice, it doesn't work: My VPN client doesn't connect.
In addition to VPN, I've tried this with 802.1X/EAPOL authentification, and multiple clients - with the same results: providing the root CA cert to the client works; providing my intermediate CA cert doesn't.
Is that by design, or is it just how most implementations work?
(I use a TLS based VPN, but as I've also tried it with 802.1X and TTLS, it seems to be related to TLS or X.509, and not to my specific VPN client/server architecture.)
Update: I've fond an OpenSSL commit that implements adding non-self-signed CA certificates as trust anchors. Unfortunately, this is not yet included in any release version, so all the proposed workarounds in the comments still apply.