Derek Cole wrote:
> Great - thakns for the information. I had come across that nsCertType
> deprecation and spent the afternoon implementing the remote-cert-tls
> directive. So far I was able to issue certificates that are either client
> or server, with the right attributes. Am I correct in understanding you
> that if I isser a cert that has both clientAuth and serverAuth directives,
> it'd be able to connect in both ways? This would be good for me because I
> have one server that acts as a server for users, and itself is a client to
> another vpn server. If I could use the same cert there it'd be convenient
> for me.
That depends a bit how you set the key usage flags in the cert. See
OpenVPN's manpage for the --remote-cert-tls option, but it requires both the
'key usage' and 'extended key usage' match expected values. You could set
the key usage to 'digitalSignature' and 'keyAgreement' which is valid for
both.
An easier option might be to use the --remote-cert-eku directive instead
which only checks the TLS attribute for clientAuth or serverAuth, which will
happily ignore the key usage flags. You can then sign certs with both eKu
attributes, then do:
In client configs:
remote-cert-eku "TLS Web Server Authentication"
In server configs:
remote-cert-eku "TLS Web Client Authentication"
--
Josh
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
