Third party certificates, bundled with the private key, can be uploaded for use in a number of different places in AppGate ZTNA. When a third party certificate is due to expire within 30 days (90 days for the external root CA certificate), then the appliance healthcheck will be set to Warning, so be sure to sign into the admin UI regularly.
Admin/API access Use the Admin/API TLS Connection UI to add the PKCS#12 | Admin/API access is via the Unique Admin Hostname. This uses the self-signed root certificate which means there will be an 'unsafe' warning shown (the browser does not trust the certificate). To avoid the admin having to approve this certificate, an externally signed certificate can be used. This requires a PKCS#12 file containing a certificate (for the Unique Admin Hostname) signed by a trusted CA and the private key is required to terminate the admin/API HTTPS connection. |
URL user access Use the Sites UI to add the PKCS#12 | The URL access feature operates as a reverse proxy when handling Client traffic. This means that the appliance requires a PKCS#12 file to terminate any http(s) connections, decrypt, URL filter and then re-establish an onward https connection to the protected hosts. URL access can support multiple PKCS#12 files, each containing a certificate (for the protected host) signed by a trusted CA and the private key. An alternative to the use of multiple certs is a wild-card cert - but this should be limited in scope because of the security implications in the event of its loss. |
Portal Client Use the HTTPS Settings UI to add the PKCS#12 | The Portal requires a FQDN for the Portal Hostname where users go to sign-in using a web-Client. They will also be redirected here if they use the URL of the protected host they are trying to access. A PKCS#12 file containing a certificate signed by a trusted CA (for the Portal hostname) and the private key; these are required to terminate this HTTPS connection from the user. |
Portal user access Use the User Access Settings UI to add the PKCS#12 | The Portal operates as a reverse proxy when handling user traffic. This means that it must terminate any HTTPS connections, decrypt and then re-establish an onward HTTPS connection to the protected hosts. The Portal supports the use of multiple PKCS#12 files containing a certificate signed by a trusted CA (for the protected host) and the private key. An alternative to using multiple certs is a wild-card cert - but this should be limited in scope because of the security implications in the event of its loss. |
Metrics Forwarding Use the Metrics Aggregator Settings UI to add the PKCS#12 Use the Prometheus Exporter Settings UI to add the PKCS#12 | Metrics scraping requires a PKCS#12 file containing a certificate signed by a trusted CA (for the appliance hostname) and the private key; these are required to terminate the inbound HTTPS connection used to scrape the metrics. |
External root CA Use the CA UI to add the PKCS#12 | 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. |
Using an externally-signed certificate
For connections which terminate on the appliance there will be a specific (new) hostname; a suitable wild-card certificate (covering this hostname) and private key may already exist. These will just need to be packaged into a PKCS #12 file and exported to each appliance that requires it. However there can be security concerns relating to handling and exposure of private keys, so an alternative is to generate a new private key on the specific appliance and use that instead with a certificate covering just this (new) hostname.
The PKCS #12 file must meet certain criteria:
The Certificate needs to be verified, so include all relevant cert(s) and intermediate cert(s). This might include going all the way to the root cert for self-signed.
Do not encrypt the private key (no passphrase).
Add the cert(s) to the PKCS #12 file in order, i.e. webserver > intermediate cert > .... > root CA.
Wild-card certs are permitted.
Creating the certificate
Below is one specific example of the process for creating the PKCS #12 file for use with AppGate ZTNA. You can do this using alternate parameters or tools if you want. This example uses OpenSSL. If you are not familiar with this process then it is best handled by others who deal with Certificate signing.
You will need SSH terminal access to do this and it can be done on your own device or on the appliance. Plan this so as to minimize the any exposure of the private key.
Create a private key :
openssl genrsa -out /mnt/state/pki/my-appliance.pem 2048Create a CSR (certificate signing request) using the private key:
openssl req -new -sha256 -key /mnt/state/pki/my-appliance.pem -out /mnt/state/pki/my-appliance.csrYou can view it using this command: openssl req -text -noout -in /mnt/state/pki/my-appliance.csr
The generated CSR file
/mnt/state/pki/my-appliance.csris a public file that is now ready to be used to generate the Certificate. You will probably not be doing this yourself so it needs to be copied or sent to the appropriate authority (such as an external CA) who will generate the signed certificate for you.
Using the certificate
When you get the certificate (.crt) back, this needs to be combined into the PKCS #12 file (.pfx) before it can be used with the appliance. Where you do this is again up to you, but care needs to be exercised when handling the private key.
Create the PKCS #12 file:
openssl pkcs12 -export -out my-appliance.pfx -inkey my-appliance.pem -in my-appliance.crtUpload the PKCS #12 file using the admin UI