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.

Choose a certificate authority⁠

Choose the certificate authority that fits your deployment.

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.

Troubleshooting⁠

See also⁠