Tutorial: Install Web SSL Certificates on Access Server Using Google Trust Services, ZeroSSL, SSL.com, or Actalis
Overview
Access Server secures the Admin Web UI and Client Web UI with an SSL/TLS certificate. During installation, Access Server generates a self-signed certificate so you can access the web interfaces immediately. Because browsers don’t trust that certificate by default, users typically see a self-signed certificate warning when opening the interfaces.
This tutorial shows you how to replace the self-signed certificate with a browser-trusted SSL certificate issued by one of these certificate authorities:
Google Trust Services
ZeroSSL
SSL.com
Actalis
Access Server uses the ACME protocol, the standard used by Let’s Encrypt and other certificate authorities to automate certificate issuance and renewal. After you complete the configuration, Access Server uses sacli to request and install the certificate and handles automatic renewal through its ACME client.
The procedures in this tutorial require a fully qualified domain name that resolves to your Access Server.
For a Let’s Encrypt certificate, refer to Tutorial: How to Use ACME Client to Issue Web SSL Certificates for the Access Server UI.
If you prefer a system-managed Certbot deployment, refer to Tutorial: Install a Let's Encrypt Wildcard SSL Certificate on Access Server with Certbot. The Certbot method is the better option when you need a wildcard certificate.
Browser-trusted certificates are also a foundational requirement for secure zero trust network access deployments.
Prerequisites
Before you begin, ensure you have:
Access Server 3.1.0 or newer.
Console access and the ability to get root access.
A fully qualified domain name, such as
vpn.example.com.A public DNS record that resolves the domain to the Access Server IP address.
An account with the certificate authority you plan to use.
The required inbound ports allowed through any host firewall, network firewall, cloud firewall, or security group.
Required ports
The required validation port depends on the certificate authority:
Certificate authority | Challenge | Required inbound port |
|---|---|---|
Google Trust Services | TLS-ALPN-01 | TCP 443 or the configured web service port |
ZeroSSL | HTTP-01 | TCP 80 |
SSL.com | HTTP-01 | TCP 80 |
Actalis | HTTP-01 | TCP 80 |
The TLS-ALPN-01 challenge validates domain ownership over TLS port 443 without requiring port 80. The HTTP-01 challenge validates domain ownership by requesting a temporary validation resource over TCP port 80.
Issue a certificate with Google Trust Services
Google Trust Services uses the TLS-ALPN-01 challenge and is the certificate authority in this tutorial that supports Access Server cluster mode.
Issue a certificate with ZeroSSL
ZeroSSL uses the HTTP-01 challenge. TCP port 80 must be reachable from the internet during validation.
Issue a certificate with SSL.com
SSL.com uses the HTTP-01 challenge. TCP port 80 must be reachable from the internet during validation.
Issue a certificate with Actalis
Actalis uses the HTTP-01 challenge. TCP port 80 must be reachable from the internet during validation.
Verify the browser-trusted certificate
Complete these checks after requesting a certificate from any of the supported certificate authorities.
Automatic renewal
After the ACME configuration is enabled, Access Server’s ACME client manages automatic certificate renewal.
To avoid renewal failures:
Keep the required challenge port reachable.
Keep the domain pointed to the correct Access Server IP address.
Don’t replace the ACME-managed certificate manually.
Keep the certificate authority account and EAB credentials valid.
Review Access Server logs if the certificate approaches expiration without renewing.
After renewal, verify that the Admin and Client Web UIs present the new certificate.