Skip to main content

Tutorial: How to Install a Valid Web SSL Certificate in Access Server

Abstract

A verified and trusted SSL certificate guarantees you're connected to the right server. Here's how to install yours with Access Server.

Overview

Access Server’s web services secure the connection between the web browser and the web server using an SSL certificate. When you install Access Server, it generates a self-signed certificate so you can start and use the web server. This produces the inevitable warnings in the web browser like "Unable to verify authenticity" or other ominous messages. With a self-signed certificate, these messages are expected. To connect to the web services initially, you must bypass this warning message.

We recommend installing a signed SSL certificate for an FQDN (Fully Qualified Domain Name) for reaching your web services — the Admin Web UI and the Client Web UI — in a web browser.

When you've completed the steps outlined below, the web interface is automatically trusted and shows a green padlock icon in most web browsers to indicate that the connection is trusted and secure.

Important

The SSL certificates are not related to VPN certificates as those are separate and managed in a different way. Alterations to the SSL certificates don’t affect VPN certificates.

To generate the proper keying materials for your Access Server software, you need a machine with OpenSSL installed. You can do this on a Linux system, such as the system running your Access Server.

Check if OpenSSL is installed

  1. Sign in to your server.

  2. Obtain root privileges.

  3. See if OpenSSL is installed (if it is, skip the next section for installing it, but if you get an error, you need to install it):

    openssl version

Install OpenSSL (if needed)

  • Install OpenSSL on Debian/Ubuntu systems:

    apt install openssl
  • Or on CentOS/Red Hat systems:

    yum install openssl

Generate a private key and certificate signing request

  1. With OpenSSL installed, create a private key and certificate signing request (4096 bits SHA256):

    openssl req -out server.csr -new -newkey rsa:4096 -sha256 -nodes -keyout server.key
  2. Answer the set of standardized questions. This is how we answered it in our example situation:

    Example 4. Example certificate parameters
    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 <- This is the FQDN name for your server.
     Email Address []:support@exampletronix.com
    Please enter the following 'extra' attributes
     to be sent with your certificate request
     A challenge password []:
     An optional company name []:


In the example above, we didn't specify a challenge password or optional company name. Some certificate authorities don't let you specify an optional company name or know how to deal with a challenge password, so we recommend leaving those last two questions unanswered. You now have a server.key and a server.csr file.

The server.key file is the private key; ensure you keep it safe and secure. You will need this file once your certificate signing request has been approved and a certificate has been issued to you. Also, it is the underpinning of the SSL certificate security model. This private key stays with you and does not go to any other party.

The server.csr file is the certificate signing request. In the questions above, you provide a "Common Name," which is the FQDN name of your Access Server. For example, if you sign in to the Client Web UI with this address, https://vpn.exampletronix.com/, the Common Name is vpn.exampletronix.com. In our example, our certificate signing request is for the subdomain vpn.exampletronix.com on the domain exampletronix.com.

Now you’re ready to get an SSL certificate from a registered certificate authority (CA).

  1. Provide your certificate signing request and the server URL or domain to the CA.

  2. Choose an Apache or Apache2 certificate.

    Note

    Access Server doesn't use Apache software but uses that same type of certificate.

  3. Typically, the next step includes verification that you own the domain. The CA might use one of these methods to do that:

    • Requiring you to place a file on your webserver the CA can retrieve.

    • Using a verification email sent to a registered email address on the domain.

  4. Once the CA has verified your identity and received payment, they'll sign a certificate and send it to you.

  5. The CA also sends intermediary files or may have them separately on their website.

    Important

    Intermediary files are separate certificates that complete the chain of trust between the certificate and a root certificate authority trusted by most web browsers and SSL-capable programs. Without the intermediary files, it may not be possible to establish a chain of trust between your signed public certificate and a trusted certificate authority.

To install your SSL certificate in Access Server using the Admin Web UI, ensure you have these three files ready:

  1. The signed certificate from your CA.

  2. The CA bundle or intermediary files from your CA.

  3. The private key you created when making the CSR.

Important

Ensure these files are formatted with an Apache-compatible format, also called X509/Base64 or PEM/CER format. If the files are .p12 or .pfx format, those formats are suitable for Windows platforms but not for the Linux Access Server product. You can convert the certificates to the required format using a utility such as the DigiCert Certificate Utility.

The CA bundle — or the intermediary files — is a set of certificates that complete the chain of trust between your signed certificate for your server and a root certificate authority trusted by web browsers and other SSL-capable programs. Without these files, web browsers will still display your certificate as untrustworthy. The CA bundle may be a single file or separate files, and you need them to be in one file. If you have separate files, resolve this by opening them up in a text editor like Wordpad or notepad, copy and paste one after the other into a new file, and save the file as the CA bundle or intermediary file.

The private key must be the same one you created and used to create the CSR. You cannot use any other private key with the signed certificate. They are inextricably linked. If you have made the mistake of losing the original private key, your signed certificate is useless, and you must start over.

Tip

You can also install the SSL certificate using the command line interface.

Install the files in the Admin Web UI

  1. Sign in to the Admin Web UI.

  2. Click Configuration > Web Server.

  3. Under Do you want to change the web server certificate? Click Yes for User-provided Certificate.

  4. Provide the necessary files by clicking Choose File for the CA Bundle, Certificate, and Private Key.