OpenVPN client export 2.4.3 configuration lacks the certificate name in SUBJ
I have the following setup related - OpenVPN server in Remote Access (SSL/TLS + User Auth) mode. LDAP authentication in place for the incoming VPN connections.
The (Win7) ovpn coniguration file, generated with the earlier versions of client-export package, includes the user certificate name for the "cryptoapicert" option, e.g. "SUBJ:user-cert".
The (Win7) ovpn coniguration file, generated with the latest version of client-export package, does not include the user certificate name for the "cryptoapicert" option, e.g. "SUBJ:". This makes impossible to use the connection, without manually editing the configuration file first.
This behavior has been spotted for Win7 client package only. No other OS installations, generated by the latest client-export package have been used/tested so far.
Unfortunately, I can't say for sure when the behavior changed, as there had been several client export package upgrades, before a new Win7 client was installed and the behavior observed.
Please, advise if this is and expected behavior.
You mean 1.4.12, which is what I show as the current package - it has dep on
openvpn-client-export-2.4.3_3 openvpn-2.4.3 zip-3.0_1 p7zip-16.02
Yep, that's correct.
You sure this ever worked how you say? There is bug filed in redmine that is over a year old.
OpenVPN Client Export package option for "Use Microsoft Certificate Storage" does not specify which certificate to use
There I have validated that it only puts in this option
For it to work shouldn't it need the FULL DN and not just a username anyway?
I have never used openvpn cryptoapicert, wish could be of more help..
While I agree, the bug description matches 100% the issue I have, I can confirm, after N-times checking of installation packages, generated with earlier versions of client-export, the SUBJ is set correctly and installation works without any intervention.
To be more specific about versions - OpenVPN GUI 220.127.116.11 works, the latest package includes 18.104.22.168, which doesn't.
I am not using the install package. Using just the file config download.
Thanks, but it seems it's "generate, then package" approach, e.g. same file.
Anyway, the main purpose of this post was to understand if it was a pfSense issue or not. Believe the answer is "yes". One possible explanation for the different behavior over time is "fix and re-introduce" has happened.
Appreciate the link from the bug database and the guidance provided.