Hi Samuli, David, list,
Samuli Seppänen wrote:
Hi,
Here's the summary of the previous community meeting.
Discussed common's "Use extv3 extensions such as subjectAltName as
common_name" patch which had not been ACKed:
<http://thread.gmane.org/gmane.network.openvpn.devel/4185>
Common fixed a few minor, stylistic issues with the patch.
In deeper analysis it was noted that this feature, or using an external
CA for OpenVPN certs in general, may be dangerous. Consider the
following scenario:
- An external root CA (e.g. Verisign) is used for OpenVPN certificates,
with or without an internal sub-CA
- A certificate field such as subjectAltName contains an email address
and is used as common_name in OpenVPN
Even if a sub-CA is included in the certificate signing chain, it's
likely that OpenVPN/OpenSSL will happily accept certificates signed
_only_ by the external root CA. So, a malicious person could connect to
the VPN by having a certificate with a faked email address signed by the
external CA.
This feature could be implemented more safely as a separate plugin using
the new v3 plug-in API, as that will provide full access to the X509
certificate object in C code. Dazo sent the second version of the v3
plug-in API to openvpn-devel mailing list today.
David and I discussed this a little bit last week on IRC ; OpenSSL (and
thus, OpenVPN) will accept all certificates signed by *any* of the CAs
present in the --ca file (or --capath directory). That's more or less
the way OpenSSL is supposed to work - the CA file/directory contains the
set of "trust anchors" which are considered valid (self-signed) CA
certificates.
Adding , for example, the Verisign public CA cert as a cert to this file
or directory is quite dangerous, even without the aforementioned patch:
all certs signed by Verisign would pass the validation test!
What some people get confused about is a stacked certificate vs a
certificate chain: OpenVPN only supports stacked CA certificates,
meaning that any of the certs present in the stacked file are considered
trusted.
What some people want is a certificate chain, like some websites use:
the website has a server certificate signed by a sub-CA which in turn is
signed by Verisign. The webserver sends the entire chain (server cert +
sub-CA cert + verisign cert) to the client for verification. That way
the client only needs the Verisign cert to trust a particular website
(the Verisign CA cert is installed in most browser by default). OpenVPN
does not support this at the moment. It would require changing
SSL_CTX_use_certificate()
to
SSL_CTX_use_certificate_chain()
to ensure that the entire certificate chain is sent to the remote end
(client or server).
In nearly all cases this is not needed, as both client and server can be
configured to use the list of sub-CAs that you want to be trusted.
Simply do NOT include the root CA (verisign in the example above) and
everything should be OK. Also, there does not need to be any
relationship between the CA certs listed in the stacked ca.crt file.
cheers,
JJK
