Clients can't connect after 2.6.0

Stewart

Since upgrading to 2.6.0 our clients are unable to connect. I've seen other people posting the the same issue but don't see a resolution. This post seems to mirror my situation: link

The client errors with:

Thu Sep 15 16:00:37 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]x.x.x.x:1194
Thu Sep 15 16:00:37 2022 Attempting to establish TCP connection with [AF_INET]server.wan.ip.address:1194 [nonblock]
Thu Sep 15 16:00:37 2022 TCP connection established with [AF_INET]server.wan.ip.address:1194
Thu Sep 15 16:00:37 2022 TCPv4_CLIENT link local: (not bound)
Thu Sep 15 16:00:37 2022 TCPv4_CLIENT link remote: [AF_INET]server.wan.ip.address:1194
Thu Sep 15 16:00:37 2022 VERIFY ERROR: depth=0, error=unable to get local issuer certificate: CN=nnnnn, C=nnnnn, ST=nnnnn, L=nnnnn, O=nnnnn, serial=1
Thu Sep 15 16:00:37 2022 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Thu Sep 15 16:00:37 2022 TLS_ERROR: BIO read tls_read_plaintext error
Thu Sep 15 16:00:37 2022 TLS Error: TLS object -> incoming plaintext read error
Thu Sep 15 16:00:37 2022 TLS Error: TLS handshake failed
Thu Sep 15 16:00:37 2022 Fatal TLS error (check_tls_errors_co), restarting
Thu Sep 15 16:00:37 2022 SIGUSR1[soft,tls-error] received, process restarting

The server shows:

Sep 15 13:27:34 	openvpn 	5853 	TCP connection established with [AF_INET]y.y.y.y:51630
Sep 15 13:27:35 	openvpn 	5853 	client.remote.it.address:51630 VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: CN=internal-ca, C=nnnnn, ST=nnnnn, L=nnnnn, O=nnnnn, serial=0
Sep 15 13:27:35 	openvpn 	5853 	client.remote.it.address:51630 OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
Sep 15 13:27:35 	openvpn 	5853 	client.remote.it.address:51630 TLS_ERROR: BIO read tls_read_plaintext error
Sep 15 13:27:35 	openvpn 	5853 	client.remote.it.address:51630 TLS Error: TLS object -> incoming plaintext read error
Sep 15 13:27:35 	openvpn 	5853 	client.remote.it.address:51630 TLS Error: TLS handshake failed
Sep 15 13:27:35 	openvpn 	5853 	client.remote.it.address:51630 Fatal TLS error (check_tls_errors_co), restarting

The OpenVPN Server Certificate is good until 2030. I've created a new user with their own certificate with the same problem. Is it an issue with the client export utility? If so, how do we circumvent it? I need it to be both username/password and certificate to pass MFA.

I do notice the client shows depth=0 and the server shows depth=1 if that's an issue.

viragomann

@stewart
Check this out, please: https://redmine.pfsense.org/issues/13424

Stewart

@viragomann

I've not manually applied patches before. It says:

The patch has been committed into the System Patches package and will be available to users there soon once some work on the build system is complete.

In the meantime, users can install the System Patches package and then create an entry for a3c1589086ea67d25a28ec14ab95d7fd9ab25fa2 to apply the fix immediately.

I don't know how to do that. I've installed the System Patches Package. Do I just put in a description and a URL/Commit ID of a3c1589086ea67d25a28ec14ab95d7fd9ab25fa2? What about the rest of the fields?

About auto apply... It seems like if left unchecked then it applies but does not persist after reboot and if checked it is permanently applied and will persist after reboot. Is that correct?

viragomann

@stewart
Add a new patch. Enter a description and the patch ID and save it.
Then you can apply the patch.

Stewart

@viragomann

I gave it a description and used a3c1589086ea67d25a28ec14ab95d7fd9ab25fa2 as the ID and saved. I then clicked fetch and viewed it and it seemed right. Then I applied and it said it was successful but the problem still persists.

Stewart

@stewart

Actually, the diff on that appears to be affecting /src/etc/inc/auth.inc which is something else. Looking in the thread the files that should be adjusted are /src/etc/inc/certs.inc and /usr/local/www/system_crlmanager.php.

viragomann

@stewart
Did you also reboot. CRL expiration is updated at boot.

On my home installation this resolves exactly the "OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed" error.

Stewart

@viragomann I have not but I did go into the certs.inc file and the system_crlmanager.php file and it appears that the updated lines are in there. I'll verify I can reboot and will respond when that's done.

Stewart

@viragomann Unfortunately the issue is the same after a reboot.

Stewart

I now see other posts where this seems to have happened when they upgraded to 2.5. We did an inplace upgrade from 2.4.4 to 2.5.0 to 2.6.0. I've now created a second CA, issued a second certificate to a second server, created a second user certificate but it still fails. How common is this issue?

Stewart

OK, so I found this page with a post by anakha that suggests editing /usr/local/sbin/ovpn_auth_verify and changing:

RESULT=$(/usr/local/sbin/fcgicli -f /etc/inc/openvpn.tls-verify.php -d "servercn=$2&depth=$3&certdepth=$4&certsubject=$5&serial=$serial&config=$config")

to

RESULT=$(/usr/local/sbin/fcgicli -f /etc/inc/openvpn.tls-verify.php -d "servercn=$2&depth=$3&certdepth=$4&certsubject=\\"$5\\"&serial=$serial&config=$config")

lo and behold, that worked!

Why? What does that do and why is it effective? This post is from 2 years ago. I can't believe this is still a wide spread problem. How can I mitigate this in the future with our other boxes?

Edit: Nope. It worked once and now it fails every time again. Grrr...

Stewart

I may have found the issue but only once I completely removed all of everything and started from scratch. The previous certificate was set for 10 years but the new version shows when setting up a certificate that it should be under 398 days. I've recreated it all from scratch (removed server, certificates, CA) and it's working now. The only problem is that I'll need to reinstall on all of the users since it's all new certificates.