SSL web certificate behavior in Access Server

Upgrade to Latest Version

Introduction

This document details web certificates for the Client and Admin Web UI services for OpenVPN Access Server.

Self-signed web certificate

A fresh installation of OpenVPN Access Server uses a self-signed certificate for the web services. When you open a web browser and enter the address for your Admin or Client Web UIs, the browser displays a warning stating it can’t verify the server’s identity or the certificate can’t be trusted. The self-signed certificate isn’t from a trusted certificate authority, so the web browser displays the warning. Override the warning and proceed to access and configure your Access Server.

We consider the self-signed certificate a fallback method until you install a valid web certificate because an HTTPS web service requires a certificate to function. We recommend replacing this with a signed and validated web certificate. With such a certificate, the browser automatically verifies the server’s identity, and you can avoid a man-in-the-middle attack. A prerequisite is having a valid FQDN (Fully Qualified Domain Name) like vpn.example.com. You should also configure this FQDN name in the Hostname or IP address field on the Network Settings page in the Admin Web UI. You can install a valid web certificate with a Common Name (CN) that matches the FQDN. A valid wildcard certificate with the wildcard on the same subdomain level is also acceptable. For example, *.example.com will match vpn.example.com but will not match vpn.something.example.com.

Refer to the steps for Installing a valid SSL web certificate in Access Server.

The web interface of Access Server is only available via HTTPS, which requires a web certificate. Access Server version 2.9 and newer generates a self-signed web certificate automatically valid for one year. When Access Server starts up and sees that the self-signed web certificate expires within 180 days (about half a year), it automatically regenerates the web CA and the web certificate. Updating the hostname in Access Server triggers certificate regeneration so the CN matches the FQDN.

Access Server generates self-signed certificates that meet these requirements:

  • RSA keys must use key sizes of 2048-bit or higher.
  • SHA1 algorithm must not be used (SHA256 is used).
  • It must contain EKU attributes.
  • The CN must match the FQDN address of the server.
  • It must not be valid for more than 398 days.

Note: The SSL web certificates are not related to VPN certificates. Those are separate and managed in a different way. Alterations to the web certificates don’t affect VPN certificates.

Where the SSL web certificates are stored

The SSL web certificate and CA can be stored in one of three locations: in the configuration database in specific configuration key values; referenced by filename and path in these configuration keys; in the default fallback location /usr/local/openvpn_as/etc/web-ssl/.

We recommend loading the SSL web certificate and CA into the configuration database. It uses those when Access Server finds certificates and keys configured in the configuration database. When the configuration keys are empty, Access Server uses the files from the fallback location. This allows a safe option for cases such as the SSL certificates provided aren’t working — you can then delete those configuration keys and use the fallback self-signed certificates.

We recommend against manually altering files in the fallback location. If you do, Access Server’s self-signed certificate management is skipped entirely.

Database configuration key values:

  • cs.cert — SSL web certificate contents or its filepath.
  • cs.priv_key — Private key contents or its filepath for the above certificate.
  • cs.ca_bundle — CA Intermediate bundle contents or its filepath, if needed.
  • cs.ca_key — CA key contents or its filepath, used only for internal self-signed certificates.

Contents of /usr/local/openvpn_as/etc/web-ssl directory:

  • server.crt — Self-signed SSL web certificate.
  • server.key — Private key for the above certificate.
  • ca.crt — CA public certificate.
  • ca.key — CA private key.

Note: The database configuration keys can either contain filepaths or actual in-line certificates and keys. By default, these values are not set and default to the filepaths shown above. You may change the filepaths — as long as the expected files are in the new path, Access Server can continue using its self-signed certificate management logic. But if you load certificates into these configuration keys, Access Server skips the logic for managing self-signed certificates.

Regenerating self-signed certificates

When Access Server isn’t provided with SSL web certificates, it uses its self-signed certificates and regenerates those when certain conditions are met. If these files have been tampered with, it’s possible to reset them with the instructions found here. This is to meet today’s stricter security requirements for self-signed certificates. EKU is one of those requirements, and since older versions of Access Server generated self-signed certificates without EKU, when you upgrade to Access Server 2.9 or newer, they are regenerated.

If all of the below conditions are met, the Access Server enables its internal logic for self-signed certificate management:

  • There are no certificates and keys stored in-line in these configuration keys: cs.cert, cs.priv_key, cs.ca_bundle, and cs.ca_key.
  • The file /usr/local/openvpn_as/etc/web-ssl/ca.crt has a CN that contains: “OpenVPN Web CA”.
  • The file /usr/local/openvpn_as/etc/web-ssl/ca.key exists.

In addition to the above, if any of the triggers below match, Access Server regenerates the certificates:

  • The certificate expiration date is less than 180 days away.
  • The certificate does not contain EKU parameters.
  • The certificate CN does not match the hostname configured in Access Server.

If you want to remove any web certificates loaded into Access Server and regenerate the self-signed certificates so that Access Server reverts to managing these by itself, follow the instructions below to delete the web certificate data from your server. We recommend taking a backup of your Access Server files before you continue, just in case you accidentally wipe a web certificate or key that you want to retain.

Regenerate self-signed certificates (overwrites existing ones):

cd /usr/local/openvpn_as/scripts/
./certool -d /usr/local/openvpn_as/etc/web-ssl --type ca --unique --cn "OpenVPN Web CA"
./certool -d /usr/local/openvpn_as/etc/web-ssl --type server --remove_csr --sn_off --serial 1 --name server --cn vpn.example.com
./sacli start

Remove web certificates and keys from the configuration:

cd /usr/local/openvpn_as/scripts/
./sacli --key "cs.cert" ConfigDel
./sacli --key "cs.priv_key" ConfigDel
./sacli --key "cs.ca_bundle" ConfigDel
./sacli --key "cs.ca_key" ConfigDel
./sacli start

Installing your own SSL web certificate

To obtain a valid web certificate, you must get one from a trusted root CA or one of its intermediates. You must go through a validation process to prove either the ownership of the particular FQDN name or the whole domain, or even provide personal or company details. This depends on which type of web certificate you choose. Extended Validation certificates, for example, require some additional validation, whereas normal certificates require only verification of domain ownership. Once you have the web certificate you want to install, you can do so in the Admin Web UI under Configuration > Web Server. We have a guide that explains the process: