OpenVPN '--ns-cert-type' is deprecated

Help on building IPFire & Feature Requests
ummeegge
Community Developer
Community Developer
Posts: 4018

OpenVPN '--ns-cert-type' is deprecated

Postby ummeegge » June 9th, 2017, 1:37 pm

Hi all,
since later OpenVPN-2.3+ versions the following message appears in the client connection logs:

Code: Select all

WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.

i have searched a little around to find a solution for this.
The OpenVPN 2.3 manpages --> https://community.openvpn.net/openvpn/w ... n23ManPage points the following out:
--ns-cert-type client|server
Require that peer certificate was signed with an explicit nsCertType designation of "client" or "server".

This is a useful security option for clients, to ensure that the host they connect with is a designated server.

See the easy-rsa/build-key-server script for an example of how to generate a certificate with the nsCertType field set to "server".

If the server certificate's nsCertType field is set to "server", then the clients can verify this with --ns-cert-type server.

This is an important security precaution to protect against a man-in-the-middle attack where an authorized client attempts to connect to another client by impersonating the server. The attack is easily prevented by having clients verify the server certificate using any one of --ns-cert-type, --verify-x509-name, or --tls-verify.


and for --remote-cert-tls:
--remote-cert-tls client|server
Require that peer certificate was signed with an explicit key usage and extended key usage based on RFC3280 TLS rules.

This is a useful security option for clients, to ensure that the host they connect to is a designated server.

The --remote-cert-tls client option is equivalent to --remote-cert-ku 80 08 88 --remote-cert-eku "TLS Web Client Authentication"

The key usage is digitalSignature and/or keyAgreement.

The --remote-cert-tls server option is equivalent to --remote-cert-ku a0 88 --remote-cert-eku "TLS Web Server Authentication"

The key usage is digitalSignature and ( keyEncipherment or keyAgreement ).

This is an important security precaution to protect against a man-in-the-middle attack where an authorized client attempts to connect to another client by impersonating the server. The attack is easily prevented by having clients verify the server certificate using any one of --remote-cert-tls, --verify-x509-name, or --tls-verify.


whereby the OpenVPN 2.4 manpage --> https://community.openvpn.net/openvpn/w ... n24ManPage gives the deprecation warning:
--ns-cert-type client|server (DEPRECATED)
This option is deprecated. Use the more modern equivalent --remote-cert-tls instead. This option will be removed in OpenVPN 2.5.


Since i try currently to integrate OpenVPN-2.4.2 into IPFire environment --> viewtopic.php?f=50&t=18067 i do see a little urgency to stay compatible in a not so far away future (OpenVPN-2.5.x) without the hassle to regenerate a lot´s of certificates cause "they need to, now"...

A possible solution (the only one i could find until now):
To stay compliant to RFC3280 TLS rules --> https://www.ietf.org/rfc/rfc3280.txt IPFire misses the respective OpenSSL configuration entries.
The diff for the OpenSSL configuration file (findable under /var/ipfire/ovpn/openssl/ovpn.cnf) for OpenVPN can looks like this:

Code: Select all

--- /var/ipfire/ovpn/openssl/ovpn.cnf.orig   2017-06-09 13:17:22.431163012 +0200
+++ /var/ipfire/ovpn/openssl/ovpn.cnf   2017-06-09 15:07:25.831784061 +0200
@@ -77,6 +77,10 @@
 nsComment         = "OpenSSL Generated Certificate"
 subjectKeyIdentifier      = hash
 authorityKeyIdentifier      = keyid,issuer:always
+# Needed for --remote-cert-tls
+extendedKeyUsage      = clientAuth
+keyUsage          = digitalSignature
+#
 
 [ server ]
 
@@ -86,6 +90,10 @@
 nsComment         = "OpenSSL Generated Server Certificate"
 subjectKeyIdentifier      = hash
 authorityKeyIdentifier      = keyid,issuer:always
+# Needed for --remote-cert-tls
+extendedKeyUsage      = serverAuth
+keyUsage          = digitalSignature, keyEncipherment
+#
 
 [ v3_req ]
 basicConstraints       = CA:FALSE


Since IPFires current host certificate do not includes

Code: Select all

            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Key Usage:
                Digital Signature, Key Encipherment

the problem appears that all existing clients rely on the deprecated "Netscape" cert attribute which uses the '--ns-cert-type server' directive. IPFire´s host certificate (in that way the root certificate too) needs to be regenerated with the new defined key usage extension entries, changing only the client.conf directives (from '--ns-cert-type server' to '--remote-cert-tls server' ) won´t work and ends up in a

Code: Select all

Fri Jun  9 13:42:41 2017 Certificate does not have key usage extension
Fri Jun  9 13:42:41 2017 VERIFY KU ERROR
Fri Jun  9 13:42:41 2017 OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Fri Jun  9 13:42:41 2017 TLS_ERROR: BIO read tls_read_plaintext error
Fri Jun  9 13:42:41 2017 TLS Error: TLS object -> incoming plaintext read error
Fri Jun  9 13:42:41 2017 TLS Error: TLS handshake failed


If the new OpenSSL parameter has been set and new clients are generated with the new host certificate, both directives ('--ns-cert-type server' and '--remote-cert-tls server') can be used in client.ovpn. Whereby if the '--remote-cert-tls server' directive takes place in the client.ovpn the following client log entries appears:

Code: Select all

Fri Jun  9 14:10:54 2017 VERIFY OK: depth=1, C=DE, O=test, CN=test CA
Fri Jun  9 14:10:54 2017 VERIFY KU OK
Fri Jun  9 14:10:54 2017 Validating certificate extended key usage
Fri Jun  9 14:10:54 2017 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Fri Jun  9 14:10:54 2017 VERIFY EKU OK


All that seems like this are not so good news (smells like work :-( ), nevertheless i wanted to make a remark in the forum (too).

May someone knows better solutions for that (i call it) problem ? May someone have other better ideas for a new ovpn.cnf ? And for sure if someone wants to test this too, feedback (as usual) might be great.

Greetings,

UE
Image
Image
Image

fkienker
Posts: 68

Re: OpenVPN '--ns-cert-type' is deprecated

Postby fkienker » June 12th, 2017, 4:06 pm

Thanks so much for doing the investigation on this! Time (and software) marches on and being prepared is far better than being surprised.

Fred

ummeegge
Community Developer
Community Developer
Posts: 4018

Re: OpenVPN '--ns-cert-type' is deprecated

Postby ummeegge » June 12th, 2017, 7:18 pm

Hi Fred,
thanks for your positiv feedback.
fkienker wrote:Time (and software) marches on and being prepared is far better than being surprised.

This is exactly my point in here (same in the 2.4 development (arrangement)) whereby it might be nice if there can be made some good preparations for all that upcoming changes with as much if´s and elif´s, ..., in there as possible ;-) .

It might be interesting if e.g. iOS or Android´s can handle '--remote-cert-tls' , since i do not use smart?phones may someone comes along which knows more about that...

Best regards,

UE
Image
Image
Image

ummeegge
Community Developer
Community Developer
Posts: 4018

Re: OpenVPN '--ns-cert-type' is deprecated

Postby ummeegge » June 16th, 2017, 8:31 pm

Have pushed now a first idea to Git which includes:

- Extended key usage based on RFC3280 TLS rules for OpenVPNs OpenSSL configuration,
so '--remote-cert-tls server' can be used instead of the old and deprecated '--ns-cert-type server' if the host certificate (Root certificate by the way too) are newly generated with this options.
Nevertheless both directives should work also with new certificates.

Since i do not wanted to make those directives configurable over the webinterface (makes only confusion) i thought it might be a nice idea if the CGI do this by itself. So i added a

- Automatic detection in ovpnmain.cgi if the host certificate uses the new options.
If it does, '--remote-cert-tls server' will be automatically set into the client
configurations for N2N and RW.
If it does NOT, the old '--ns-cert-type server' directive will be set in the client
configurations for N2N and RW.

The patched files can be found in here --> http://git.ipfire.org/?p=people/ummeegg ... dceb3b3e53 .

Please give them some testings :P .

Thanks and greetings,

UE

EDIT: Interesting topics causing the smart?phone thing:
- https://github.com/schwabe/ics-openvpn/issues/168
- https://forums.openvpn.net/viewtopic.php?t=19382
Image
Image
Image

fkienker
Posts: 68

Re: OpenVPN '--ns-cert-type' is deprecated

Postby fkienker » June 19th, 2017, 4:09 pm

[quote="ummeegge"]Have pushed now a first idea to Git which includes:

- Extended key usage based on RFC3280 TLS rules for OpenVPNs OpenSSL configuration,
so '--remote-cert-tls server' can be used instead of the old and deprecated '--ns-cert-type server' if the host certificate (Root certificate by the way too) are newly generated with this options.
Nevertheless both directives should work also with new certificates.

Really like this idea and you seem to have implemented it in a very convenient fashion. As soon as we get our test box restored (yes, we blew it up which is what a test box is for) I will add this, generate new certs, and try it out.

Thanks in advance!
Fred


Return to “Development”



Who is online

Users browsing this forum: Bing [Bot] and 1 guest