Feature #7767
closed
OCSP support for OpenVPN server
Added by Michael Voetter over 6 years ago. Updated over 3 years ago.
100%
Description
It would be great to have a possibility to enable OCSP checking for OpenVPN Server included in pfSense. It seems to be possible to perform OCSP checks without modifying the OpenVPN implementation (http://permalink.gmane.org/gmane.network.openvpn.devel/2492) by just adding a script performing the checks. Therefore, it seems to be possible to implement this feature in a relatively short amount of time which in return would add value to the OpenVPN Server feature of pfSense.
Files
Updated by Jim Pingle about 6 years ago
- Category set to OpenVPN
- Assignee set to Jim Pingle
Updated by Anonymous 
Updated by Jim Pingle over 4 years ago
The link above seems to be dead, but there is an example script in https://github.com/OpenVPN/openvpn/blob/master/contrib/OCSP_check/OCSP_check.sh
The example check could be adapted and added to source:src/usr/local/sbin/ovpn_auth_verify and source:src/etc/inc/openvpn.tls-verify.php
Updated by Viktor Gurov over 4 years ago
Updated by Jim Pingle over 4 years ago
- Status changed from New to Pull Request Review
Updated by Renato Botelho over 4 years ago
- Status changed from Pull Request Review to Feedback
- % Done changed from 0 to 100
PR has been merged. Thanks!
Updated by Ronald Schellberg over 4 years ago
I think this PR caused my OpenVPN TLS handshake to start failing. The openvpn.tls-verify.php call results in a "2" return code.
Updated by Jim Pingle over 4 years ago
- Status changed from Feedback to New
Can you provide any additional detail about your settings and certificate structure?
Updated by Steve Wilson over 4 years ago
OpenVPN TLS handshake also failing here after update. OCSP Verify box is unchecked, Certificate Depth check set to "One (Client+Server)". Changing Certificate Depth dropdown to "Do Not Check" allows handshake to complete successfully.
Reverting the patch using System Patches package allows successful handshake with Certificate Depth back on original setting of "One". So it seems like the patch is stepping on the Certificate Depth check setting even when the OCSP Verify selection box is unchecked.
Updated by Jim Pingle over 4 years ago
- Status changed from New to In Progress
OK, I see this now as well after updating a VM here. I'll look into it ASAP.
Updated by Jim Pingle over 4 years ago
I see the problems, push coming shortly.
Updated by Jim Pingle over 4 years ago
- Status changed from In Progress to Feedback
Applied in changeset 175f3ac6b671182e2cf9968f5e820188d9e1573f.
Updated by Ronald Schellberg over 4 years ago
- File Capture.PNG Capture.PNG added
See attached. The Certificate depth is set to One. The CA is a self signed pfsense with a number of certificates created in 2017. The OpenVPN log, with two sites attempting to connect, shows:
Jan 10 10:56:21 openvpn 85280 xxx.xxx.xxx.xxx:xxxxxx TLS Error: TLS handshake failed
Jan 10 10:56:21 openvpn 85280 xxx.xxx.xxx.xxx:xxxxxx TLS Error: TLS object -> incoming plaintext read error
Jan 10 10:56:21 openvpn 85280 xxx.xxx.xxx.xxx:xxxxxx TLS_ERROR: BIO read tls_read_plaintext error
Jan 10 10:56:21 openvpn 85280 xxx.xxx.xxx.xxx:xxxxxx OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
Jan 10 10:56:21 openvpn 85280 xxx.xxx.xxx.xxx:xxxxxx WARNING: Failed running command (--tls-verify script): external program exited with error status: 2
Jan 10 10:56:17 openvpn 85280 xxx.xxx.xxx.xxx:xxxxxx TLS Error: TLS handshake failed
Jan 10 10:56:17 openvpn 85280 xxx.xxx.xxx.xxx:xxxxxx TLS Error: TLS object -> incoming plaintext read error
Jan 10 10:56:17 openvpn 85280 xxx.xxx.xxx.xxx:xxxxxx TLS_ERROR: BIO read tls_read_plaintext error
Jan 10 10:56:17 openvpn 85280 xxx.xxx.xxx.xxx:xxxxxx OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
Jan 10 10:56:17 openvpn 85280 xxx.xxx.xxx.xxx:xxxxxx WARNING: Failed running command (--tls-verify script): external program exited with error status: 2
Jan 10 10:55:45 openvpn 85280 Initialization Sequence Completed
Updated by Ronald Schellberg over 4 years ago
hand applied the changeset, didn't fix the problem. Log now shows:
Jan 10 11:32:51 openvpn 64931 xxx.xxx.xxx.xxx:xxxxxx TLS Error: TLS handshake failed
Jan 10 11:32:51 openvpn 64931 xxx.xxx.xxx.xxx:xxxxxx TLS Error: TLS object -> incoming plaintext read error
Jan 10 11:32:51 openvpn 64931 xxx.xxx.xxx.xxx:xxxxxx TLS_ERROR: BIO read tls_read_plaintext error
Jan 10 11:32:51 openvpn 64931 xxx.xxx.xxx.xxx:xxxxxx OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
Jan 10 11:32:51 openvpn 64931 xxx.xxx.xxx.xxx:xxxxxx WARNING: Failed running command (--tls-verify script): external program exited with error status: 1
Jan 10 11:32:40 openvpn 64931 xxx.xxx.xxx.xxx:xxxxxx TLS Error: TLS handshake failed
Updated by Jim Pingle over 4 years ago
Did you apply all three commits? It works for me with all current changes. I tested it on three different lab boxes. All failed before, all work now.
Updated by Jim Pingle over 4 years ago
You will need 3db110612dbf30cbb5855490525f03e4742dfe6e , ffc44c36d9ac001bbebcc6334e014dde8a11c8f4 , and 175f3ac6b671182e2cf9968f5e820188d9e1573f (in that order). Or gitsync to master from the latest snapshot.
Updated by Ronald Schellberg over 4 years ago
confirmed working now with all three patches.
Updated by Jim Pingle over 4 years ago
Great, thanks!
I'm leaving this on feedback for now since the original functionality added here (OCSP support) still requires testing.
Updated by Steve Wilson over 4 years ago
Also working here after all patches applied - server and client logs are clean. Thanks for the quick fix Jim!
Updated by Orion Poplawski over 3 years ago
I'm poking around the code for this and have a question - is it possible to have both OCSP checking and user/password authentication at the same time? As near as I can tell, the answer is no as ovpn_auth_verify only calls openvpn.tls-verify.php or openvpn.auth-user.php. However, it seems to me that they are complementary - we want to both verify the validity of the certificate (including OCSP checks) and verify the user/password.