Bug #7498
closed
Deprecated option included in OpenVPN client export
0%
Description
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 verify-x509-name or tls-remote.
James
Updated by Jim Pingle over 7 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 All added
- Affected Architecture deleted (
)
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.
Updated by James Webb over 7 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.
James
Updated by Jim Pingle over 7 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.
Updated by James Webb over 7 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.
Thanks Jim,
James
Updated by Jim Pingle over 7 years ago
- Status changed from New to Feedback
I just pushed a change to use remote-cert-tls and also adjusted the code around it to test for the proper EKU before adding it to the config.
Once 1.4.3 shows up, upgrade and try it out.