Deprecated option included in OpenVPN client export
As of OpenVPN 2.4 the directive:
ns-cert-type has been deprecated.
However, from my testing, the client export package includes the line
ns-cert-type server no matter what verification options you choose.
Could this be removed and verification directives be left to the dropdown box in the WebGUI? I.e. either
#1 Updated by Jim Pingle over 2 years ago
- Project changed from pfSense to pfSense Packages
- Category changed from OpenVPN to OpenVPN Client Export
- Assignee set to Jim Pingle
- Target version set to 2.4.0
- Affected Architecture set to All
The verification option you mentioned in the GUI controls verifying the name only, it does not verify the type, so it's not related to the warning message in the log.
We'll need a new way to control certificate type validation, there are a couple options. I'll look into it.
#2 Updated by James Webb over 2 years ago
Okay that makes sense - thank you :)
However, surely by having the
ns-cert-type option included in all exports you are causing the warning to be produced in the log?
Can it not be safely replaced with
remote-cert-tls up until Ovpn 2.5? Alternatively (and preferably) seeing as all these options are simply in place to prevent MITM attacks would it not be adequate to just have the problematic option removed and include
verify-x509-name as a verification option. In my mind that is equivalent in operation to either
ns-cert-type server or
remote-cert-tls server as type seems to be irrelevant here if you have a name to match against.
#3 Updated by Jim Pingle over 2 years ago
That should work fine for certificates made any time recently on pfSense.
The only potential problem I foresee is maybe that servers with really old certificates may not be signed with the correct KU/EKU to validate against that. Though if they are that old, it may be past time for them to make a new server cert anyhow. I spot checked a couple really old server certs I had laying around from a long time ago, and one from 2009 had the right properties so it's probably safe to assume others do as well.
#4 Updated by James Webb over 2 years ago
That makes sense. As you stated - if certs are being signed with the correct KU/EKU from 2009 in my mind it seems like a good inductive assumption to propose that any certs since then have also been signed correctly, thus imposing minimal risk to any users today.