Open jkroepke opened 7 months ago
I would like to discuss about mandatory client-side authentication methods, such as --cert/--key, --pkcs12, or --auth-user-pass
+1 to removing this restriction. I think the rationale for this was to protect users against insecure setups, but forcing this on the client side doesn't look very useful. Trying to warn/prevent server setups with no client authentication mechanism in place should be enough.
protect users against insecure setups
This if should be keep, a new config directive, like expect-webauth
could be introduces. If set, the OpenVPN client fail to connect unless WEBAUTH is used.
A potential workaround is define username/password inline (use dummy values):
<auth-user-pass>
username
pass
</auth-user-pass>
verify-client-cert none username-as-common-name auth-user-pass-optional
Hi,
I would like to discuss about mandatory client-side authentication methods, such as --cert/--key, --pkcs12, or --auth-user-pass
Currently, I had something in my find to fully delegate the authentication to WEBAUTH protocol.
WEBAUTH does not require client certificates and username/pass authentication is done via web browser. That also make auth-user-pass obsolete.
Running a OpenVPN server with
works fine, but from client side, it's an requirement to configure client certificates or
auth-user-pass
.A configuration without client-side authentication methods produces an config error:
which I would like to eliminate.
In such cases, I prefer
tls-crypt-v2
ortls-crypt
options as initial authentication as additional security layer.The current workaround is one pair of client certificates which I have to use at each client.