OpenVPN AS web interface does not work after upgrade to v. 2.9.1

[rpr.nospam]

On a Debian 10 (buster) machine I upgraded openvpn-as package from v. 2.8.8 to 2.9.1 but after that the OpenVPN web interface is not available any more.

The machine is using the following repository:

Code: Select all

deb http://as-repository.openvpn.net/as/debian buster main

In /var/log/openvpnas.log the following error is logged:

private key validation error: [Errno 2] No such file or directory: '/usr/local/openvpn_as/etc/web-ssl/ca.key': svc/svc:675,sagent/websvc:331,sagent/websvc:248,sagent/websvc:428,pki/validcert:31,pki/validcert:28,util/valid:137,util/simplefile:25 (FileNotFoundError)

In ver. 2.8.8 my OpenVPN AS used SSL certificates in /usr/local/openvpn_as/etc/web-ssl (which still exists after the upgrade):
-rw-r--r-- 1 root root 1818 Jul 4 2017 ca.crt
-rw-r--r-- 1 root root 2920 Apr 21 2020 server.crt
-rw------- 1 root root 3243 Apr 21 2020 server.key

where
server.key is the certificate private key
server.crt is the signed certificate
ca.crt is the intermediate CA certificate (TERENA SSL CA 3)

It seems that after the upgrade OpenVPN AS is not using those files but expects different files which do not exist.

How to solve this issue?

-- rpr.

[openvpn_inc]

Hello rpr,

The root cause is the valid signed certificates being loaded into the Access Server's SSL web certs fallback directory.

Access Server maintains a CA and server web certificate in the web-ssl directory. This is done so that Access Server has a fallback in case there are no valid certificates in Access Server's configuration database. It also as of version 2.9 will try to regenerate these automatically to meet stricter requirements. However in your case that fails and Access Server stops because the CA key is missing.

For some reason your ca.key file was deleted. Most likely what happened is that you removed these files at some point and then instead put your own validated signed certificates in this directory. Apparently you don't have any web certs in your configuration database so Access Server thinks it has no valid certificates, so it goes to the fallback, and that one happens to now be your signed certificates. But it is unable to do its programmed actions to ensure those certs are updated to current security standards for self-signed certificates.

I am making the assumption that the files now in the web-ssl directory are signed certificate, because you have TERENA SSL CA 3 in there, which is likely a valid party for providing signed certificates. So they shouldn't be regenerated anyways. They're just in the wrong place, basically.

To solve this properly there are 3 steps that you should do.

1: Backup.
2: Load these certificates into the Access Server configuration database.
3: Regenerate the self-signed certificates for Access Server.

Step 1:
Before you do anything though, make a backup. This guide shows how to backup the configuration of Access Server:
https://openvpn.net/vpn-server-resource ... figuration

Step 2:
Now with that backed up, I suggest you run these following commands to load your signed certificates into the Access Server database. This will load those files into the Access Server configuration database, and the web services should use those the next time Access Server tries to start up.
cd /usr/local/openvpn_as/scripts/
./sacli --key "cs.priv_key" --value_file "../etc/web-ssl/server.key" ConfigPut
./sacli --key "cs.cert" --value_file "../etc/web-ssl/server.crt" ConfigPut
./sacli --key "cs.ca_bundle" --value_file "../etc/web-ssl/ca.crt" ConfigPut

Step 3:
Now to restore the fallback certificates to normal, I recommend you first backup the files in web-ssl. Once you've done that, run these commands:
cd /usr/local/openvpn_as/etc/web-ssl/
rm server.key
rm server.crt
rm ca.crt
cd /usr/local/openvpn_as/scripts/
./certool -d ../etc/web-ssl --type ca --unique --cn "OpenVPN Web CA"
./certool -d ../etc/web-ssl --type server --remove_csr --sn_off --serial 1 --name server --cn "openvpnas"

You can replace "openvpnas" with a FQDN name of your server, but it's not really relevant. Whenever Access Server starts up, and it has no SSL certificates in its configuration database, it will use the fallback certificates. If it sees those do not have a CN that matches the current hostname setting in Access Server, it will regenerate those automatically for you. The only thing you were missing for this to work was the ca.key file, which with the above commands should be regenerated fine.

Now restart the Access Server service with "service openvpnas restart" and things should be operating correctly again.

Kind regards,
Johan

[openvpn_inc]

We will by the way be adding a detection for this type of case in a future release of AS so that it functions even under this condition.

Kind regards,
Johan

[rpr.nospam]

Johan, thank you for your advice. After running the commands you suggested the web interface started successfully with the signed SSL certificate.

I now understand that the problem occurred because I incorrectly installed SSL certificates for the Access Server web service: I just replaced files in web-ssl subdir (server.key, server.crt and ca.crt) with the files I got when obtaining new SSL certificate (and restarted AS). I did not understand that the files must be uploaded through the admin web interface (CONFIGURATION > Web Server > Upload your own Certificate) so that they are loaded in the Access Server database.

After fixing this problem with the web service, the users were still not able to establish VPN connections to the AS. There was another error in /var/log/openvpnas.log:

Code: Select all

Server Agent initialization status:
{
  "errors": {
    "openvpn_0": [
      [
        "error",
        "process started and then immediately exited: ['2021-07-02 11:51:22 Cannot load inline certificate file']"
      ],
      [
        "error",
        "service failed to start or returned error status"
      ]
    ]
  },
  "last_restarted": "Fri Jul  2 11:51:17 2021",
  "service_status": {
...
    "openvpn_0": "off. Error: [Error: service failed to start or returned error status.]",
...
  }
}

That has been fixed by generating new CA for OpenVPN:
- in admin web interface: CONFIGURATION > CA Management > Create New CA

-- rpr.

[openvpn_inc]

Hello rpr,

That most likely means you were still on a 1024-bit CA still and your operating system apparently doesn't like that.

For both your web certificate issue and the 1024-bit CA we have solutions in place that go out in release 2.9.2 this week, along with instructions on how to migrate to a newer CA that is more secure.

Kind regards,
Johan