SSL Certificates on Access Server's Web Services
Introduction
This topic details web certificates for Access Server's Client and Admin Web UI services.
These web interfaces are only available via HTTPS, which requires a web certificate. Access Server 2.9.0 and newer automatically generate self-signed web certificates valid for one year.
Access Server's self-signed certificate
A new Access Server installation comes with self-signed certificates, leading to web browser warnings.
While the connection between the web browser and the web server is encrypted, and you can use the fingerprint of the SSL certificate to provide proof of identity, this identity verification is a manual process. Web browsers employ a method of trust that allows the automatic establishment of the web server's identity and trust by its FQDN, its web certificate, and a chain of trust leading up to a trusted root authority.
We recommend replacing the SSL certificate so you no longer receive warning messages and you enhance security. When you have things set up correctly with a signed and verified SSL certificate, your web browser displays the padlock icon in the browser's address bar for a secure connection.
Note
SSL web certificates are not related to VPN certificates. They are separate and managed differently. Alterations to the web certificates don’t affect VPN certificates.
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 certificate using the tutorial linked above.
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.
Access Server automatically regenerates the CA and certificate within 180 days of the self-signed certificate's expiration date. Additionally, updating the hostname triggers certificate regeneration so the CN matches the FQDN.
To manually regenerate these, refer to this tutorial:
SSL web certificate and CA locations
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/.
Tip
We recommend loading the SSL web certificate and CA into the configuration database. Access Server uses those when it 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 where 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 file path. |
cs.priv_key | Private key contents or its file path for the above certificate. |
cs.ca_bundle | CA Intermediate bundle contents or its file path, if needed. |
cs.ca_key | CA key contents or its file path 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 contain file paths or actual in-line certificates and keys. These values are not initially set by default and use the above file paths. 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.
Recover SSL web certificates from the config DB
If you need to extract the SSL web certificates from your Access Server, refer to this tutorial:
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, resetting them with the instructions found here is possible. 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, they are regenerated when you upgrade to Access Server 2.9 and newer.
You can find the steps to do this in our tutorial:
Here's a brief explanation of how SSL certificates play a role in securing internet traffic.
SSL secures HTTP
SSL stands for Secure Sockets Layer. It's an add-on to an existing system: hypertext transfer protocol (HTTP).
Web browsers transfer information from a web server to your computer in the browser using HTTP. Access Server's web server displays in your web browser this way, giving you the Admin and Client Web UIs.
HTTP alone is insecure. Anyone intercepting traffic between your browser and a web server can see everything flowing over the network. This is especially insecure when visiting sites like banks or financial institutions.
Therefore, we add a security layer, SSL, and HTTP becomes HTTPS, a secure version of HTTP.
SSL sets up an encryption layer so everything flowing over the connection is unreadable to outsiders. This is done using a clever system using prime numbers and mathematical calculations that make it impossible for anyone trying to intercept the traffic to see what's going through the encryption connection.
SSL establishes trust
Encryption alone isn't the only purpose; another essential SSL certificate purpose is establishing trust.
You can trust the server you are connecting to if it's verified to be the server you think it should be. The SSL certificate determines the server's identity and holder of the private and public keys.
An SSL certificate has two major components: a private and a public key.
The server generates the private key, which stays with the server. It stays private. It's used to create a certificate signing request (CSR). The CSR is a standardized form with identifying questions like your website's common name, your contact details, where you are located, etc. After answering the questions, a file connected to the private key cryptographically without containing the key itself is generated. The CSR is sent to a certificate authority (CA).
A CA confirms and validates the identities of website owners so they can issue public certificates with their keys. Root authorities trust these keys, and web browsers and SSL-capable programs automatically trust root authorities' keys and certificates.
Certificates work with a hierarchy: the SSL certificate chain. The SSL certificate on your website (your end-user certificate) includes a chain that starts with your issued certificate and then identifies the certificate above it, an intermediate certificate. There may be several intermediate certificates in the chain, and at the top is the root certificate.
Installing your end-user certificate must include all intermediate certificates, or it isn't trusted. This is because it's seen as a broken or invalid chain.
SSL keys
The SSL certificate chain means that a web browser sees your public key (the end-user certificate) as trusted when it finds the root authority certificate at the top of the chain. Thus, the private key you get from the CA is also trusted.
This signed key is a public key cryptographically tied to your private key without containing the private key. The public key, stored on the web server, is shared publically, while the inextricably linked private key remains private.
Anytime someone visits your website, the web server shares a copy of the public key.
Think of it like showing your passport to someone who needs to confirm your identity. Your passport shares public details about you, including information like the country and authority that issued it. Only a trusted authority can issue a passport; only they know your private information, like where you were born, where you live, etc. This is like a CA that issues you your certificate. Any browser seeing the SSL certificate can check with the CA to see if it's real.
The link between the public and private keys provides security. If a visitor receives the public key and checks with the CA before trusting it, it can be taken further: Does this web server presenting the public key also hold its linked private key?
If not, they're faking it. This needs to be tested.
Modern passports include biometric data for added security.
Likewise, anything encrypting using the public key can only be decrypted by the holder of the private key linked to it. So, by sending information encrypted with the public key and receiving a sensible response, you can be sure it's the correct web server. Only the private key used to create the original CSR, approved and signed by a certificate authority, can decrypt data encrypted with the linked public key.
That's your proof of identity and method of establishing trust. That's a simplified overview of how SSL certificates secure internet traffic by ensuring you're connected to the correct web server.