On Thu, Apr 21, 2016 at 09:58:19AM +0200, Jan Just Keijser wrote:
> 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).
Oh. That's interesting. Indeed, it helps a lot in my scenario. Thanks!
--
Lionel
------------------------------------------------------------------------------
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
