This section provides details about the Certificate Authority (CA) certificate, the Appliance certificates, and their usage.
For web-based TLS (HTTPS) connections and most VPNs, it is required to have a proper, trusted certificate. This is because you only use a domain URL to specify the target server and you want to make sure that server is genuine. In these cases, the browser or the VPN client will make sure (via the external trusted cert) that the webserver or VPN Gateway is the correct one. The browser or VPN client will use the trusted cert stores within the OS or browser for this validation.
Mutual TLS (mTLS)
For the Appgate SDP Client and appliances, the situation is different because we use mutual TLS. This means that the TLS connection will be validated at both ends, each having their proper signed certificate, so certificates need to be generated on the server side and on Client side. The Client will validate if the server side is trusted, and the server side will check if the Client certificate is trusted. Because of the need to generate appliance and Client certificates, as well as having to renew these certificates thereafter, the Controller(s) cannot easily delegate this task so acts as the CA for the Appgate SDP Collective.
Certificate Authority
Being the CA means that the Appgate SDP system initially uses a self-signed root CA certificate to issue certificates. These in combination with out-of-band seeding processes are used to establish trusted communications between appliances and from the Client to appliance.
At first connection we don’t need to rely on any of the OS or browser trusted cert stores.
For new appliances, you have to export a unique seed file that contains a temporary certificate valid for a given time. This has to be passed to the new appliance by some means such as SCP.
For new Clients, Client profiles are used that can be installed via solutions such as SCCM/jamf/MDM. The Client profile contains a domain URL, the SPA key, and the CA fingerprint (to create the trust). After verification, a Client cert is generated which the newly seeded Client stores safely in the OS trusted cert store for future use.
Admin access on port 8443 relies on a browser. Initially you can just trust the certificate but you need to established proper trust for production use.
When the CA certificate is due to expire within 90 days, the appliance healthcheck will be set to Warning, so be sure to sign in to the admin UI regularly.
The alternative to the Controller self-signed CA certificate is to upload the next CA using an internal company self-signed root certificate. But either way, the Controller remains the certificate authority.
Controller CA certificate
Downloading the current CA certificate
The certificate can be downloaded from the Controller. It has a number of uses including adding it to the local certificate stores in administrator's devices (if you are not adding a trusted certificate). This will reduce the warnings that you get if you are an administrator.
The CA cert may also be required when using the Admin UI, sdpctl, and for Auto-scaling.
Adding the next CA certificate
The initial Controller in a Collective creates a CA certificate that has a 10 year lifetime; you should generate the next CA certificate well before it expires. There is also the option for you to upload the next CA certificate based on an externally generated root certificate. We recommend generating the internal CA certificate.
If you select the option to upload the next CA certificate, you need to correctly build a P12 file and then upload it, adding a password if required.
Use of Certificate Revocation List
When uploading your own certificate you have the option to Enable CRL. The Controller is not able to perform the role of the CRL distribution point because it is designed to be protected by SPA so is not readily accessible. When CRL is enabled, you need to specify a remote CRL Distribution Point URL; this is where the CRL will be hosted and will usually be an HTTP web server configured to deliver the content-type: application/pkix-crl.
The web server's URL will be used by the Appgate SDP Clients and appliances to check for any revoked certificates. Once the Next CA is activated then a Download CRL button will be available; this can be used to download the CRL and which can then be manually uploaded to the remote CRL Distribution point. When enabled and the CRL is not available, an appliance will show a Warning state. The CRL is checked every hour. To update the CRL now, you can run sudo cz-config update-crl.
When CRL is enabled, then Issued Certificates will appear under the Usage menu. From this list it is possible to revoke one or more certificates, if required.
NOTE
CRL should only be used in advanced use cases as it introduces a single point of failure that can completely disable an Appgate SDP Collective.
License update
The license is based on the CA certificate, so the existing one will “expire” when the next CA certificate is activated. During this transitional phase a replacement license should be obtained from AppGate Support. This will use a new request code, i.e.164186314c5_v2. For details about licensing the Appgate SDP system, refer to Licenses.
Distributing the next CA Certificate
The Appgate SDP system has a built in facility for dealing with any CA change that should be transparent to users. Once the Next CA certificate is added, this will become the next Controller CA certificate. The current CA certificate and the next CA certificate will sit alongside each other for as long as you need to leave the Collective in this transitional phase.
During the transitional phase, the next CA certificate is distributed to every client that connects. Sufficient time should be allowed to ensure all clients have connected at least once; a client will only pick up the next CA certificate at sign-in or when the claims token is renewed.
Appliances in the Collective use the same process, but this should be almost immediate. New client profiles generated after this time will include the next CA certificate.
You can utilize the LogServer to help identify any Clients that have not yet connected. Ensure the log retention period is set to longer than the planned transitional period first. In OpenSearch, select Visualize from the menu.
The saved visualization “Last next Controller CA Certificate generation” will remind you of the date you generated the next Controller CA certificate.
The saved visualization “Last authentication date per distinguished name” will show you the last seen dates of all Clients.
To identify the device IDs, go to the on-boarded devices screen in the admin UI and search for the full distinguished name or the device ID.
Activating the Next CA certificate
Once you are ready, you can activate the next Controller CA certificate and replace the current one. The replacement license will be automatically applied at that time.
Admin UI will:
be disconnected
a refresh will be required which will include accepting the new certificate before signing in
Peers will:
need to be connected to the Controller
be health-checked by the Controller using the next appliance certificate thumbprint
be told to switch and will move the next appliance certificate to the current appliance certificate and apply the configuration
Clients will:
move the next Controller CA certificate to the current Controller CA certificate
renew their VPN certificate causing a short period of disconnection
NOTE
Devices or users that have not received the new Controller CA certificate will not survive the CA switch. The next time they try to sign in, they won't be able to get any further than "Invalid certificate". This will require that the certificate store is cleaned up manually and an updated profile provided. More details can be found in Client Deployment and Management.
Appliance Certificates
Hostname settings
Each appliance is identified by the Appliance Hostname/IP in System Settings.
NOTE
On this form, Interfaces allows you to add additional interfaces if required (eth1,2,3, etc.) which might be extra NICs linked to some internal networks.
When an appliance is first configured, relevant hostnames, IP addresses, and DNS names are automatically added to the appliance certificate. Extra hostname aliases can also be included in the certificate in Extra Hostnames in Certificate. This enables TLS connections to be set up to other hosts, for instance when a load balancer is used in front of the appliances. If any hostname or IP address details are changed within the appliance configuration, the certificate will need to be renewed. In certain situations certificate renewal will be triggered automatically when the change is committed, in others you will be reminded to renew the certificate manually.
Client hostname
Client Hostname/IP in Secure Tunnel Settings is not a hostname setting as such, but it is the name passed to the Client when it signs in that will later be used to connect to Gateways. This will be auto-filled with the appliance hostname but can be overridden if required. Saving any changes will not impact active Client sessions.
When a change is made to the Client Hostname/IP on an active appliance, you will need to renew the appliance certificate manually after saving. New Client connections to the Gateway may fail until the appliance certificate is renewed.
Certificate renewal
New appliances have a certificate that is valid for about two years and three months. Renewing the certificate before it expires is critical for Controllers because if it does expire, the trust model used throughout the Collective breaks down completely.
When an appliance certificate is due to expire within 30 days, then the appliance healthcheck will be set to Warning, so be sure to sign in to the admin UI regularly.
Auto-renewal of the certificate
Because it is hard to recover when a Controller certificate expires, the system will automatically renew any expiring appliance certificates 24 hours before it actually expires. This will cause some slight disruption.
To manually renew the certificate
After saving any changes: From the Appliances screen, click the Renew Certificate button.
You will be asked to confirm and select OK if you want to continue.
At renewal
When renewal occurs, the appliance will be deactivated temporarily until the certificate has been successfully renewed.
The appliances screen may show the appliance as Not Activated for a short period. You do not need to take any action. When the certificate has been successfully renewed, the appliance will be shown as Activated again
Any active Client connections will be dropped but automatically reconnected once the certificate has been renewed. In an HA situation, the users will likely be failed over to alternative Gateways.
If the information in the certificate is changed, you may need to confirm that the new connection is trusted.