On Wed, Apr 20, 2016 at 05:53:18PM +0200, Jan Just Keijser wrote:
> On 19/04/16 16:12, Lionel Elie Mamane wrote:
>> On Tue, Apr 19, 2016 at 06:46:27AM -0400, Colin Ryan wrote:
>>> On 2016-04-19 1:41 AM, Lionel Elie Mamane wrote:
>>>> I run my own private CA with a structure like:
>>>> rootCA ---- vpnSubCA
>>>> | |-------- vpnCertificate1
>>>> | |-------- vpnCertificate2
>>>> | |-------- vpnCertificate3
>>>> |
>>>> |---- otherCertificate1
>>>> |---- otherCertificate2
>>>> |---- otherCertificate3
>>>> |---- otherCertificate4
>>>> I need OpenVPN to accept (for verify-x509-name and ccid-exclusive)
>>>> only certificates signed by vpnSubCA, *not* any certificate signed
>>>> directly by "root CA" nor by any other sub-CA of rootCA.
> 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
--
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
