Cryptography is one of the areas that frustrates many of our users. While installing and managing SSL certificates for your Access Server may seem overly complex and complicated, this article tries to cover all the basics so you can get your Access Server secured in a snap!
This article will cover the following:
To order to generate the proper keying materials for your Access Server software, you will need a machine with openssl installed. For Debian/Ubuntu type distributions, this can be installed via the apt-get install openssl command. To check to see if OpenSSL is properly installed, invoke the command openssl version in a terminal session.
Once you are in a terminal or SSH session, invoke the following command:
openssl req -out server.csr -new -newkey rsa:4096 -sha256 -nodes -keyout server.key
You will then be asked a series of questions about the certificate signing request you are about to create (an example template of how this data should be entered is provided below):
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:California
Locality Name (eg, city) :San Francisco
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Exampletronix, Inc.
Organizational Unit Name (eg, section) :IT Support
Common Name (eg, YOUR name) :vpn.exampletronix.com <-- Please note that this must correspond EXACTLY to the domain or DNS name of your VPN server. Be advised that however, the second-level domain name, exampletronix.com and a third level domain name, vpn.exampletronix.com are treated differently, and a certificate created for exampletronix.com will not work for vpn.exampletronix.com. A wildcard certificate may be created for the second level domain name (e.g. *.exampletronix.com), which will match all SUBDOMAINS in the second level exampletronix.com zone (this does not include exampletronix.com itself). That being said, a wildcard certificate created on the second level (e.g. *.exampletronix.com) will only work for subdomains on that level (e.g. vpn.exampletronix.com and www.exampletronix.com, but not exampletronix.com or vpn.servers.exampletronix.com). If you use a certificate outside of these guidelines, you may receive a error message in your browser when trying to visit the Client Web Server (CWS).
Email Address :email@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password :
An optional company name :
Once all of these questions have been answered (some, like in the explanation above, can be left empty), two files, server.csr and server.key, will be created in the current directory. If you are working remotely, you can use a SFTP client such as Filezilla or Cyberduck to transfer these files to your machine.
You can then submit the certificate signing request (i.e. the server.csr file) to your certificate authority (CA) for signing. DO NOT send your certificate authority the server.key file. This file is meant for your safekeeping and you will need this file when installing the SSL certificate on your server. You will not be able to install your certificate if you ever lost access to your private key, so please keep this in a safe place! If you are asked for the common name of your certificate, enter the same common name as what you have entered earlier. You may also be asked what your server type is. If asked, please select Apache as the SSL server type.
Once your certificate authority has approved your certificate signing request, it will send you the signed certificate and a certificate bundle.
To be able to install the certificate on your Access Server software, you will need the following:
To install a commercial SSL certificate, you must first login to the Admin Web UI, as shown below:
Once logged in, visit the Web Server section on the left navigation panel:
Provide the three files necessary for certificate installation, then press the Validate button:
If you have provided all the necessary files correctly, a successful message should appear. Click the Save button to save your changes. You may also want to click the Update Running Server button to effect your changes immediately.
If you did not provide the necessary files correctly, you may experience some of the problems below:
Problem: Your private key does not match the one you have used to sign the CSR that you have submitted to your certificate authority.
Resolution: Make sure you are using the same key file that was used to generate your CSR. If you lost this file, you will need to restart the certificate generation process and ask your certificate authority for a certificate replacement.
Problem: Your private key is encrypted with a passphrase and Access Server does not know how to decrypt the private key (i.e. it does not know what your passphrase is).
Resolution: Decrypt your private key by running the openssl rsa -in server.key -out decrypted.key command in provide Access Server the decrypted.key file. You will be prompted for the passphrase you have used to encrypt your private key.
Problem: The certificate file you have provided is invalid.
Resolution: Make sure that you have provided the correct certificate file, and do not accidentally supply the private key as your certificate file. If the certificate file is valid, and Access Server is not accepting the certificate file, it is possibly due to the fact that your certificate authority is improperly formatting the certificate file (e.g. without line breaks, or using a different EOL (End-of-Line) standard). You may try to manually fix this problem using yourself with proper EOL conversion tools, or by contacting your certificate authority for assistance.
Problem: The private key file you have provided is invalid.
Resolution: Make sure that you have provided the correct private key file, and do not accidentally supply the certificate as your private key file. If the private key file is valid, and Access Server is not accepting the private key file, it is possibly due to the fact that your private key file was formatted incorrectly or created in another operating system (e.g. without line breaks, or using a different EOL (End-of-Line) standard). You may try to manually fix this problem using yourself with proper EOL conversion tools, or by contacting your certificate authority for assistance.
Problem: The file supplied seems like valid keying material, although it doesn't seem like the server certificate was provided.
Resolution: It is possible that the CA bundle and the server certificate was swapped. Try to swap the order of the CA bundle and the certificate and try again. If this does not work, make sure you are providing the signed certificate you have received from your CA, and not the CSR you have generated on your own machine.
If you are using the self-signed certificate and the certificate is close to expiration and/or you want to change the common name listed on the self-signed certificate, issue the following command on the SSH terminal / console (replace vpn.exampletronix.com with the domain name you are using) below. Please be advised this will ONLY work if you are using a self-signed certificate. You will need to ask your certificate authority for a certificate replacement if you are using a commercial SSL certificate.
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.exampletronix.com && ./sacli start
NOTE: This command will have no effect if a commercial SSL certificate is installed on your Access Server. If you would like to revert to using a self-signed certificate, please follow the instructions below before issuing this command.
If for any reasons you want to uninstall the commercial SSL certificate that was previously installed on your Access Server, you may issue the following command in a SSH terminal / console:
cd /usr/local/openvpn_as/scripts && ./sacli -k cs.priv_key ConfigDel && ./sacli -k cs.ca_bundle ConfigDel && ./sacli -k cs.cert ConfigDel && ./sacli start
You are very likely to receive SSL warnings after you revert to a self-signed SSL certificate, unless the self-signed certificate has been previously trusted in your system certificate store(s).