SSL web certificate behavior in Access Server
Self-signed web certificate
When you first access the web interface of Access Server it uses a self-signed certificate. Your web browser displays a warning that it is not possible to verify the identity of this server or that the certificate cannot be trusted. That is because the self-signed certificate isn’t from a certificate authority that is trusted automatically by your web browser. You can override this warning in your web browser to proceed with accessing and configuring your Access Server.
The self-signed certificate is considered a fallback method when no valid web certificate is installed, because an HTTPS web service requires a certificate in order to function. We recommend replacing this with a signed and validated web certificate. With such a certificate, the identity of the server is verified automatically and a man-in-the-middle attack can be avoided. A prerequisite of this is that you have 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 then install a valid web certificate that has a CN (Common Name) that matches the FQDN. A valid wildcard certificate that has 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.
The web interface of Access Server is only available via HTTPS, which requires a web certificate. Access Server version 2.9 and greater will generate a self-signed web certificate automatically that is valid for one year. When Access Server starts up and sees that the self-signed web certificate is going to expire within 180 days (about half a year) it regenerates the web CA and the web certificate automatically. If the host name is updated in Access Server they will also be regenerated so the CN will match 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).
- Must contain EKU attributes.
- The CN must match the FQDN address of the server.
- 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 will have no effect on 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 certain 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. When Access Server finds certificates and keys configured in the configuration database, it uses those. 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 is not provided with SSL web certificates it uses its own self-signed certificates and regenerates those when certain conditions are met. If these files have been tampered with it is 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 host name 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 will manage these by itself again then you can follow the instructions below. Following these instructions will delete the web certificates data from your server. We recommend that you take a backup of your Access Server files before you continue, just in case you accidentally wipe a web certificate or key that you wanted 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 some kind of 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 that 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: