This section describes the Certificate Authority (CA) certificate, appliance certificates, and their usage.
For web-based TLS (HTTPS) connections and most VPNs, a trusted certificate is required. In these cases, you specify the target server by domain URL, and the certificate ensures that the server is genuine. The browser or VPN client validates the server by using an externally trusted certificate from the operating system or browser trust store.
Mutual TLS (mTLS)
For the AppGate ZTNA client and appliances, a different model is used. The system relies on mutual TLS (mTLS), where both ends of the TLS connection are validated. Each side must present a properly signed certificate.
The client validates that the server is trusted.
The server validates that the client certificate is trusted.
Because certificates must be generated for both appliances and clients, and because these certificates must be renewed over time, the Controller cannot easily delegate this responsibility. As a result, the Controller acts as the certificate authority for the AppGate Collective.
Certificate Authority
As the certificate authority, the AppGate ZTNA system initially uses a self-signed root CA certificate to issue certificates. These certificates, together with out-of-band seeding processes, establish trusted communications:
Between appliances
Between the client and an appliance
At the initial connection, the system does not rely on any operating system or browser trusted certificate stores.
For new appliances, you must export a unique seed file. The seed file contains a temporary certificate that is valid for a limited time. This file must be transferred to the new appliance using a method such as secure copy protocol (SCP).
For new clients, client profiles are used. These profiles can be deployed using tools such as SCCM, Jamf, or MDM. A client profile includes:
A domain URL
The SPA key
The CA fingerprint
After verification, a client certificate is generated. The seeded client stores this certificate securely in the operating system’s trusted certificate store for future use.
Administrative access on port 8443 relies on a browser. Initially, you can manually trust the certificate, but for production use you must establish proper trust.
When the CA certificate is due to expire within 90 days, the appliance health check status is set to Warning. Administrators should sign in to the admin UI regularly to monitor this condition.
As an alternative to the Controller’s self-signed CA certificate, you can upload the next CA using an internal company self-signed root certificate. In both cases, the Controller remains the certificate authority.
Controller CA certificate
Downloading the current CA certificate
The current CA certificate can be downloaded from the Controller.
The certificate can be used for several purposes, including adding it to the local certificate stores on administrators’ devices when a trusted certificate is not used. This reduces browser warnings for administrative access.
The CA certificate may also be required when using the following components:
Adding the next CA certificate
The initial Controller in a Collective creates a CA certificate with a 10-year lifetime. You should generate the next CA certificate well before the current certificate expires. There is also an option to upload a next CA certificate that is based on an externally generated root certificate. Generating the internal CA certificate is recommended.
If you choose to upload the next CA certificate, you must correctly build a P12 file and upload it. A password can be added if required.
Use of Certificate Revocation List
When uploading your own certificate, you can enable the Certificate Revocation List (CRL). The Controller cannot act as the CRL distribution point because it is protected by SPA and is not readily accessible.
If CRL is enabled, you must specify a remote CRL distribution point URL. This is typically an HTTP web server configured to deliver the content type application/pkix-crl.
The specified web server URL is used by AppGate ZTNA clients and appliances to check for revoked certificates. Once the next CA is activated, a Download CRL button becomes available. You can use this button to download the CRL and manually upload it to the remote CRL distribution point.
When CRL is enabled and the CRL is not available, an appliance enters a Warning state. The CRL is checked every hour. To update the CRL immediately, run:
sudo cz-config update-crl.
When CRL is enabled, Issued Certificates will appear under the Usage menu. From this list, you can revoke one or more certificates if required.
NOTE
CRL should only be used in advanced use cases. It introduces a single point of failure that can completely disable an AppGate ZTNA Collective.
License update
The system license is based on the CA certificate. When the next CA certificate is activated, the existing license expires. During this transitional phase, you must obtain a replacement license from AppGate Support.
The replacement license uses a new request code (for example, `164186314c5_v2`). For details about licensing, see Licenses.
Distributing the next CA Certificate
The AppGate ZTNA system includes built-in support for CA changes that are intended to be transparent to users. After the next CA certificate is added, it becomes the next Controller CA certificate. The current CA certificate and the next CA certificate coexist for as long as needed during the transitional phase.
During the transitional phase, the next CA certificate is distributed to each client when it connects. Allow sufficient time for all clients to connect at least once, as a client receives the next CA certificate only at sign-in or when its claims token is renewed.
Appliances in the Collective follow the same process, but distribution is almost immediate. Any new client profiles generated after this point include the next CA certificate automatically.
You can use the LogServer to identify clients that have not yet connected. Before doing so, ensure that the log retention period is longer than the planned transitional period.
In OpenSearch:
Select Visualize from the menu.
Use the saved visualization “Last next Controller CA Certificate generation” to identify when the next CA certificate was generated.
Use the saved visualization “Last authentication date per distinguished name” to view the last authentication date for each client.
To identify device IDs, go to the onboarded devices screen in the admin UI and search for the full distinguished name or device ID.
Activating the Next CA certificate
When you are ready, activate the next Controller CA certificate to replace the current one. The replacement license is automatically applied at this time.
When activation occurs:
Admin UI:
The admin UI is disconnected.
A page refresh is required, and you must accept the new certificate before signing in again.
Peers:
Must be connected to the Controller.
Are health-checked by the Controller using the next appliance certificate thumbprint.
Are instructed to switch certificates and move the next appliance certificate to the current appliance certificate, then apply the configuration.
Clients:
Move the next Controller CA certificate to become the current Controller CA certificate.
Renew their VPN certificate, which causes a short period of disconnection.
NOTE
Devices or users that have not received the new Controller CA certificate will not survive the CA switch. On the next sign-in attempt, they will fail with an “Invalid certificate” error. Recovery requires manual cleanup of the certificate store and deployment of an updated profile. For more information, see Client Deployment and Management.
Appliance Certificates
Hostname settings
Each appliance is identified by its Appliance Hostname/IP in System Settings.
NOTE
The Interfaces field allows you to add additional interfaces (eth1, eth2, eth3, and so on) if required. These interfaces typically correspond to additional NICs connected to internal networks.
When an appliance is first configured, its hostname, IP address, and DNS names are automatically included in the appliance certificate. Additional hostname aliases can be added using Extra Hostnames in Certificate. This supports TLS connections to other hosts, such as when a load balancer is deployed in front of appliances.
If any hostname or IP address details are changed in the appliance configuration, the appliance certificate must be renewed. In some cases, renewal is triggered automatically when the change is committed. In other cases, you are prompted to renew the certificate manually.
Client hostname
The Client Hostname/IP field in Secure Tunnel Settings is not a hostname setting for the appliance itself. Instead, it defines the name passed to the client during sign-in, which the client later uses to connect to Gateways. This field is automatically populated with the appliance hostname but can be overridden if required. Saving changes does not affect active client sessions. If you change the Client Hostname/IP on an active appliance, you must manually renew the appliance certificate after saving. Until the certificate is renewed, new client connections to the Gateway may fail.
Certificate renewal
New appliances are issued certificates that are valid for approximately two years and three months. Renewing certificates before expiration is critical for Controllers. If a Controller certificate expires, the trust model across the Collective fails completely. When an appliance certificate is due to expire within 30 days, the appliance health check status is set to Warning. Administrators should sign in to the admin UI regularly to monitor this condition.
Auto-renewal of the certificate
To reduce the risk associated with expired Controller certificates, the system automatically renews expiring appliance certificates 24 hours before expiration. This process causes minor service disruption.
To manually renew the certificate
After saving any configuration changes:
From the Appliances page, click Renew Certificate.
Confirm the action by selecting OK.
At renewal
During certificate renewal:
The appliance is temporarily deactivated until renewal completes.
The Appliances page may show the appliance as Not Activated for a short period.
No administrative action is required during this time.
After renewal succeeds, the appliance status returns to Activated.
Any active client connections are dropped but automatically reconnect once renewal completes. In high-availability deployments, users are typically failed over to alternate Gateways.