Lets Encrypt Automatic Update Killed All Sangoma VPN connected connections?

[steve_pbuk (Steve)]

This morning when I logged on FreePBX I had the usual warning message regarding Lets Encrypt renewing certificate. This has worked flawlessly in the past without me having to do anything such as restarting services, etc.

This morning all of my Sangoma S500 connected via VPN had dropped and failed to reconnect. I check /var/log/messages and could see a stream of errors similar to the following:

OpenSSL: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed

To fix this I tried the following:

1. Rebooted the server - Didn’t fix the issue.
2. Issued the “fwconsole -r” command - Didn’t fix the issue.
3. Did some Google and came across the following page - https://forums.openvpn.net/viewtopic.php?t=23166 I changed “default_days” and “default_crl_days” but the command to regen the files didn’t work. - Didn’t fix the issue

The fix for me was:
Via the web frontend I went into the VPN Server under Admin and I disabled the VPN server. I then re-enabled the VPN server and almost instantly the phones started to connect back in via VPN.

Questions:

1. Has anyone else experienced this?
2. Am I correct in thinking this was due to the Lets Encrypt Auto renewal or was it just bad timing?
3. Is it possible to stop and start the VPN server via CLI incase this problem happens again?

Thanks

[steve_pbuk (Steve)]

Anyone had this issue before?

I’m worried it will happen again the next time Let’s Encrypt renews.

[matthewljensen (Matthew Jensen)]

I’m running a number of servers that are using the System Admin VPN, and I’ve had the same problem. I also fixed it by turning the VPN server off and then back on again. But it doesn’t seem to correlate to the renewal of the Let’s Encrypt certificates. It does relate to certificates, though. I get the same error as you in my vpn logs:

OpenSSL: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed

A google search for FreePBX and that error revealed this item in the issue tracker which has been closed for some reason. The ticket indicates the problem likely lies with the renewal of CRL and that a potential solution is to set the nextUpdate value far into the future.

What I do know is that over the past few months, I’ve had this problem occur a number of times on various systems.

I’ve tried restarting the vpn service from the CLI by running
systemctl restart [email protected]_server1.service, but that hasn’t actually fixed the problem. So far, only cycling it from the GUI has been the solution.