I've been assured that this isn't a problem for the OpenVPN AS commercial server and that the documentation that implies it is required should be viewed as being specific to the open source version.
I don't understand that claim. Regardless of whether Sonic has an OpenVPN AS commercial server or the open source server, how can it prevent a client from connecting to some other server (commercial or otherwise) that has a valid certificate? It can't.
I have read through the ovpn files you're currently generating for customers. As of today, they contain only two tests to determine whether a client is talking to a valid server:
#1: The <ca> clause says to check that the certificate presented by the server is signed with Sonic's CA key. That's a start, but since every customer's client certificate is also signed with that same CA key, anyone in the world who can get a Sonic account (or borrow or compromise someone else's) can set up a server that passes that test. That's practically no protection at all.
#2: The "ns-cert-type server" directive says to check that the certificate presented by the server contains the corresponding nsCertType property. Since you're only putting that property in the server certificate (not in customer certificates), this test works in concert with the <ca> clause to effectively validate the server, but only on openvpn clients that honor the ns-cert-type directive. I learned yesterday that this directive is deprecated (meaning it won't be supported in newer openvpn clients) and is already ignored by certain systems in the field (I happen to have one).
I have downloaded and examined your server certificate. As far as I can tell, there simply isn't anything else in there that your client configs are checking.
This means that, with your current configuration, some systems are already vulnerable to a man-in-the-middle attack, and more will become vulnerable when support for the deprecated ns-cert-type directive is dropped.
The following directives could fix this problem
. I suggest implementing at least the first two, along with the server certificate properties to support them. The third is deprecated, but might still be worthwhile for the sake of older clients. (For anyone else reading along, the "OpenVPN Server" text could really be anything; its only importance is that it match Sonic's server certificate and not match any of the customer certificates they issue.)
Code: Select all
verify-x509-name 'CN=OpenVPN Server'
The assurance you mentioned receiving just doesn't make any sense to me. If your vendor has more information that would illuminate the problem, or call attention to something I might have missed, I'd love to see it. At the moment, though, it looks like that person was just confused.