Can --extra-certs be used for a trust chain?

ShelLuser

Hi guys,

I've setup OpenVPN between two FreeBSD servers and got everything working, however there's one thing puzzling me and I'm trying to get my fingers behind it. So I'm hoping someone can give me a hint.

I have my own CA structure, but to prevent the risk of given out certificates to be (ab)used for VPN authentication I've set up a sub-ca for the sole purpose of issuing / signing certificates for VPN usage. So my chain of trust is: root ca => vpn ca => client/server certificate (root ca signed the vpn ca certificate and this certificate was used to sign the client/server certificates). This setup works. However, the only way I could get it to work was by combining both CA certificates in one file and using --ca to point to this file. This is not fully desirable because if I read correctly this also means that the root ca is now also trusted to issue client certificates used for authentication.

Originally I specified the vpn ca using the --ca parameter, and the root ca using --extra-certs. I already determined that this doesn't work (the error being "unable to get issuer certificate") but I don't understand why. From what I read in the manualpage the --extra-certs option is used to complete the local certificate chain. And I believe that's exactly what I was doing.

Now, I am fully aware of the --verify-x509-name option which allows me to limit the accepted certificates for authentication, but that's also not the point of my post.

I'm merely trying to figure out why my chain of trust isn't working as I expected it to work.

Thanks in advance for any comments you can give me!

Nicolas Jungers

Hello,

I'm wondering how you did it. I just tried to do the same and end with a TLS error.

My setup is the same as yours: root ca => vpn ca => client/server certificate (root ca signed the vpn ca certificate and this certificate was used to sign the client/server certificates).

with: ca keys/sub+ca.chained.crt
cert keys/server.crt
key keys/server.key ca keys/sub+ca.chained.crt
cert keys/client.crt
key keys/client.key The log says:

[24278]: VERIFY OK: depth=2, CN=mydomain.net CA
[24278]: VERIFY OK: depth=1, CN=mysub subCA
[24278]: VERIFY nsCertType ERROR: CN=server.mydomain.net, require nsCertType=SERVER
[24278]: TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

My server is running smartos and the client is ubuntu, but both have a fairly recent openvpn/openssl combo.

(see post https://forums.openvpn.net/viewtopic.php?f=22&t=24629#p72167)

bobv

This kept me busy for a little while too, but I finally figured it out.

There's no need to reference an external file. In the .ovpn file, you can include the entire certificate chain like so:

<ca>
----BEGIN CERTIFICATE-----
[SECONDARY INTERMEDIATE CERTIFICATE]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[PRIMARY INTERMEDIATE CERTIFICATE]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[ROOT CERTIFICATE]
-----END CERTIFICATE-----
</ca>

The root certificate goes at the bottom. I wish there was a little more documentation about this floating around, but there you go.

As far as OP's concern about the root certificate, unfortunately that's just how a chain of trust works. For purely academic purposes, I suppose you could eliminate the root CA from the handshake process, but you'd have to coax a server somehow into doing that, and to me that kind of negates having an intermediate CA. At that point, you're authenticating clients without establishing a complete chain of trust or checking for revocation of the intermediate CA's certificate, and you'd be just as well to have your server and client certificates issued directly by the root CA.

The server and clients with certificates issued by the intermediate CA are trusted because the intermediate CA trusts them, but only because the root CA trusts the intermediate CA. You see what I'm saying? The process of demonstrating trust all the way back to the root CA is necessary. You're not exposing anything secret by including the root certificate in the same file as the intermediate certificate. Those are public keys, and they have arbitrarily little cryptographic value without their respective private keys. This is the essence of a public key infrastructure. Jack can use his private key to decrypt a message that Jill sent him by using her public key. The root CA is what enables this mathematical relationship between the private key of one individual, and the public key of another. Without a root CA and origin of trust, there's no such thing as a public key infrastructure.

TinCanTech

bobv wrote Jack can use his private key to decrypt a message that Jill sent him by using her public key

Technically, Jill uses Jack's public key to encrypt a message to Jack,
which Jack then uses his private key to decrypt.