[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

Re: [Openvpn-users] Re: First OpenVPN 2.0 Release Candidate is available

  • Subject: Re: [Openvpn-users] Re: First OpenVPN 2.0 Release Candidate is available
  • From: James Yonan <jim@xxxxxxxxx>
  • Date: Wed, 8 Dec 2004 12:32:01 -0700 (MST)

On Wed, 8 Dec 2004, Niko Tyni wrote:

> In article <Pine.LNX.4.58.0412080430390.1206@xxxxxxxxx>, James Yonan wrote:
> > OpenVPN allows a lot of flexibility in terms of configuration, and some
> > users may purposely choose a configuration with less security than normal
> > simply because it makes sense for their application.  Normally, this kind
> > of usage gets a warning, and I think that running a TLS client without one
> > of tls-remote, tls-verify, or the new ns-cert-type directives should also
> > trigger a warning.  On the other hand, making it a fatal error would 
> > certainly get people's attention.  I'd want more feedback before taking 
> > that route, as it generally goes against the approach we've used so far of 
> > issuing warnings but otherwise assuming that people know what they're 
> > doing.
> Maybe I'm missing something, but isn't it secure to run without any of
> tls-remote, tls-verify or ns-cert-type if you are signing the client
> certificates with a different CA than the server certificate(s)? 
> This way a malicious client can't impersonate a server to other clients,
> eliminating the possibility of the MITM attack. 

Absolutely.  OpenVPN doesn't have any problem with running in dual-CA 
environment, where server certs and client certs are signed by different 

You would make this work by:

(1) Signing all server certs with CA #1.
(2) Signing all client certs with CA #2.
(3) Setting the server "ca" file to CA #2.
(4) Setting the client "ca" files to CA #1.


Openvpn-users mailing list