Hi,
On 20/04/16 18:01, Lionel Elie Mamane wrote:
> [...]
> the "proper" way to do this is to use
> - do a full CA+sub CA check on the server side (i.e. stack ca.crt +
> subca.crt into a single file and use it as "ca ..." )
> - add a "tls-verify" script to ensure that the certificate chain always ends
> with the subCA signed by the CA.
>> I'd simply add a check for (argv1=1) that the supplied DN is that of
>> the sub-CA (vpnSubCA in your case) and reject all others.
> Yes, this works. It still puts some trust on the root CA that it won't
> issue another sub-CA with the same DN :)
>
> I thought of using the tls_digest_{n} environment variables to assuage
> taht, "but" this is SHA-1, which should start to be deprecated, hence
> I filed https://community.openvpn.net/openvpn/ticket/675
>
actually, you're safe here: if your evil root CA would generate another
sub-CA it would not change anything: a client cannot supply a
certificate chain to the server (like the server can to the client).
I've just tested this with an OpenSSL build of OpenVPN 2.3.10, and using
either a stack client cert or specifying --extra-cert .... does not
allow access.
So if an evil client gets a new evil subca.crt from your evil root CA
then your server would still be safe, as your server simply won't
recognize the sub-CA (unless you load it on the *server* side as a valid
CA certificate).
HTH,
JJK
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
