SSL/TLS Security

Managing Certificates

On Monitoring→Certificates, you can review and download TLS certificates for the following:

  • PrivX Server certificates, required for GUI and API access.
  • PrivX Extender certificates, required for script-based host deployment over Extender connections.
  • PrivX Carrier certificates, required for web connections.
  • PrivX Web-Proxy certificates, required for web connections.
  • PrivX access groups, required for certificate-based access to targets in each access group.

Renewing Certificates

PrivX Servers

Issue new certificate(s) according to Trusted Server Certificates.

PrivX Extenders

  1. At Administration→Deployment→Deploy PrivX VPC/VPN Extenders, click ☰ next to the Extender configuration, then Unregister the Extender.

  2. Gain root terminal access to the Extender. Remove the current Extender certificate at /opt/privx/extender/extender.crt. Then run Extender postinstall:

    sudo /opt/privx/scripts/extender-postinstall.sh

    The Extender postinstall creates a new Extender certificate, and also registers the Extender.

  3. Back at Administration→Deployment→Deploy PrivX VPC/VPN Extenders, verify that the Extender status is Registered.

PrivX Carriers and Web Proxies

Certificates for Carrier and Web-Proxy pairs should be renewed at the same time. To do this:

  1. At Administration→Deployment→Deploy PrivX Web Access Gateways, click ☰ next to the Carrier and Web-Proxy configuration, then Unregister the Carrier and Web Proxy.

  2. Gain root terminal access to the Carrier. Remove the current Carrier certificate at /opt/privx/carrier/carrier.crt. Then run Carrier postinstall:

    sudo /opt/privx/scripts/carrier-postinstall.sh

    The Carrier postinstall creates a new Carrier certificate, and also registers the Carrier.

  3. Similarly to the previous step, gain root terminal access to the Web Proxy. Remove the current Web-Proxy certificate at /opt/privx/cert/web-proxy.*. Then run Web-Proxy postinstall:

    sudo /opt/privx/scripts/web-proxy-postinstall.sh

    The Web-Proxy postinstall creates a new Web-Proxy certificate, and also registers the Web Proxy.

  4. Back at Administration→Deployment→Deploy PrivX Web Access Gateways, verify that the Carrier and Web-Proxy statuses are Registered.

PrivX Access Groups

Generate and replace access-group certificates as described in Trusted CA for Certificate Authentication.

Renewing PrivX-Component CAs

Besides access-group CAs, PrivX features other CAs for certain components. These CAs need to be renewed periodically (every 5 years by default).

  • The PrivX ICAP CA handles certificates for Web-Proxy intermediate CAs
  • The PrivX Extender CA handles certificates for Extenders and Carriers.
  • The DB Proxy CA handles certificates for native-database-connection intermediate CAs

The CA that issues server certificates for PrivX components needs to be renewed periodically. To do this:

  1. Locate the current CA keys. You can do this using the keyvault-tool on any PrivX Server:

    sudo /opt/privx/bin/keyvault-tool list-asymmetric

    In the list of keys, find the PrivX ICAP CA Key and the PrivX Extender CA Key. Note their Ids, which will be required lated.

    Name                    Id                                   Type                Size OwnerID           Flags
-------------------------------------------------------------------------------------------------------------
PrivX ICAP CA Key       <icap_ca_key_id>                     ...                 ...  ...               ...
PrivX Extender CA Key   <extender_ca_key_id>                 ...                 ...  ...               ...

    Also locate the dbproxy CA's Id with:

    sudo /opt/privx/bin/keyvault-tool -nv list-asymmetric | grep "/ca/dbproxy"

    Which should return something similar to:

    /ca/dbproxy             <dbproxy_ca_key_-_id>                  ...

  2. Delete the current CA keys:

    sudo /opt/privx/bin/keyvault-tool -id <icap_ca_key_id> delete-asymmetric
sudo /opt/privx/bin/keyvault-tool -id <extender_ca_key_id> delete-asymmetric
sudo /opt/privx/bin/keyvault-tool -id <dbproxy_ca_key_id> delete-asymmetric

    In the previous commands, replace the example values:

    • <icap_ca_key_id> - Id of the ICAP CA key
    • <extender_ca_key_id> - Id of the Extender CA key
    • <dbproxy_ca_key_id> - Id of the dbproxy CA key

  3. Create new CA keys:

    sudo /opt/privx/bin/keyvault-tool -name "PrivX Extender CA Key" -size 4096 -type RSA -owner $(sudo /opt/privx/bin/keyvault-tool -name authorizer get-client-id) create-asymmetric
sudo /opt/privx/bin/keyvault-tool -name "PrivX ICAP CA Key" -size 4096 -type RSA -owner $(sudo /opt/privx/bin/keyvault-tool -name authorizer get-client-id) create-asymmetric
sudo /opt/privx/bin/keyvault-tool -name "PrivX DB Proxy CA Key" -size 4096 -type RSA -owner $(sudo /opt/privx/bin/keyvault-tool -name authorizer get-client-id) create-asymmetric

    In a HA deployment, you will need to manually synchronize local-keyvault changes. To do this, copy /opt/privx/keyvault/asymmetric/ and its contents to all your PrivX Servers.

  4. Create new CA certificates:

    sudo /opt/privx/bin/cert-tool -command create -type icap-ca \
   -subject "CN=PrivX ICAP CA" \
   -keyname "PrivX ICAP CA Key" \
   -store-db \
   -valid 1825d

sudo /opt/privx/bin/cert-tool -command create -type extender-ca \
   -subject "CN=PrivX Extender CA" \
   -keyname "PrivX Extender CA Key" \
   -store-db \
   -valid 1825d

sudo /opt/privx/bin/cert-tool -command create -type dbproxy-ca \
   -subject "CN=PrivX DB Proxy CA" \
   -keyname "PrivX DB Proxy CA Key" \
   -store-db \
   -valid 1825d

  5. Restart PrivX to apply your changes.

    Subsequently-created certificates are signed using the new CAs. You should also renew your Extender, Carrier, and Web-Proxy certificates as described earlier under PrivX Extenders and PrivX Carriers and Web Proxies.

Trusted Server Certificates

For production deployments we recommend replacing the self-signed server certificates with server certificates issued by a trusted Certificate Authority (CA).

To set up trusted server certificates on PrivX servers:

  1. Obtain the Certificate-Signing Request (CSR), located in your PrivX server at

    /etc/nginx/ssl/nginx.csr

    Enroll this CSR with your CA. In response, the CA should provide you with the following:

    • The server certificate.

    • The CA-certificate chain of the CA itself.

To certificate-signing authorities: The PrivX CSR contains subjectAltName definitions for DNS and IP addresses. These are critical to PrivX operation and must be preserved in the signed server certificate.

  1. Copy the PEM (Base64) encoded server-certificate file to the ssl_certificate location on the PrivX instance. By default, the location is:

    /etc/nginx/ssl/nginx.crt

    Ensure that the server-certificate file has correct ownership, permissions, and SELinux context:

    # chown root:nginx /etc/nginx/ssl/nginx.crt
# chmod 0640 /etc/nginx/ssl/nginx.crt
# restorecon /etc/nginx/ssl/nginx.crt

  2. Update the trust anchor for PrivX microservices. To do this, run the following command (replace /path/to/ca_chain.crt with the path to the CA-certificate-chain file):

    # /opt/privx/scripts/init_nginx.sh update-trust /path/to/ca_chain.crt

In single-server deployments, provide the CA chain of the PrivX-server certificate. In HA deployments, provide the CA chain of the load-balancer certificate.

init_nginx.sh requires PEM-encoded certificate files to have Unix line endings. If the command fails, ensure correct line endings in the CA-certificate-chain file, then rerun the command.

  1. Finally, restart the Nginx and PrivX services to start using the new server certificate. Run the following as root:

    systemctl restart nginx
systemctl restart privx

  2. PrivX components (Extenders, Carriers, and Web Proxies) must be configured to trust the new PrivX-server certificate. You can do this by redeploying the components.

Trusted CA for Certificate Authentication

PrivX issues access certificates using its own CA. These CAs are unique per access group, and self-signed by default. For production deployments we recommend setting up trusted access-group CAs.

High-level steps for setting up trusted access-group CAs includes:

  1. Obtain and set up trusted CA certificate for an access group.
  2. Configure the hosts within the access group to trust the new CA certificate.
  3. Set the new CA certificate as primary CA for the access group.

To set up a trusted CA for a PrivX access group:

  1. Generate a Certificate-Signing Request (CSR) for the access group. To do this, gain terminal access to a PrivX Server and generate a CSR as follows:

    sudo /opt/privx/bin/cert-tool -command create -access-group <ag> \
-csr -csrout privx-im-ca.csr

    Replace <ag> with the access group's name or ID. If the access group has multiple CA keys, you will be prompted to select one. You may add the -latest option to automatically select the CA key with the latest certificate expiration date.

    The CSR will be in privx-im-ca.csr, under your current working directory.

  2. Request your trusted CA to sign the CSR with the following constraints:

    • keyUsage - Digital Signature, Key Agreement, Certificate Sign, CRL Sign
    • basicConstraints - CA:TRUE, pathlen:0

    Optionally the CA may attach name constraints. See X.509 Certificate Name Constraints for more information.

    After the trusted CA provides you with the signed certificate, you may verify its constraints with:

    openssl x509 -text -noout -in privx-im-ca.crt

    Replace privx-im-ca.crt with the path to the signed certificate.

  3. Replace the access-group CA certificate in PrivX.

    sudo /opt/privx/bin/cert-tool -command replace -nv -access-group <ag> -in privx-im-ca.crt

    Replace the example values as follows:

    • <ag> - Access group's name or ID.
    • privx-im-ca.crt - Path to the signed certificate.

    The command will find the matching CA key and ask for confirmation.

  4. On all PrivX servers, restart the PrivX services to apply the changes:

    systemctl restart privx

    Subsequent certificate authentications to the access group's hosts may be signed using the new trusted CA certificate.

Hosts belonging to the access group must be configured to trust the new access-group CA.

  • OpenSSH hosts: SSH hosts that are configured to accept OpenSSH certificate authentication store the CA public key in /etc/ssh/privx_ca.pub. You may do this manually, or by running the host-deployment script with the --rotate-ca option.

    When an access group has multiple CAs, the host-deployment script with --rotate-ca will always fetch the CA with the furthest validity.

    PrivX SSH bastion and SSH proxy will attempt authentication using certificates issued by all access group's CA keys, but prioritizing the primary CA key. Thus, SSH targets will continue to be reachable during the migration period regardless of which CA key is currently trusted by the host.

    In access groups with multiple CAs and supported public-key algorithms, you may need to increase OpenSSH servers' MaxAuthTries to prevent disconnects due to too many authentication attempts.

  • Tectia SSH hosts: Replace the previous PrivX certificate with the newly created one and ensure that any configured certificate rules match the new certificate. Run ssh-server-ctl reload to apply the new certificate.

  • Windows RDP hosts: Windows hosts that are configured to accept RDP certificate authentication need to import and publish the new PrivX CA certificate on the domain. Follow the instructions in RDP Certificate Authentication on how to accomplish this.

For more information about how target hosts should validate access certificates, see Validating X.509 Access Certificates.

After all hosts in the access group trust the new certificate, set it as the primary CA within the access group:

  1. Access PrivX GUI as a PrivX admin. On Administration→Access Groups, find your access group and expand CA Key Details. Find the new CA and click Set as Primary.

  2. After you have confirmed that the new CA works, you may remove the old CA with Revoke CA Key.

Allowed SSL Protocols and Ciphers for GUI Connections

Connections to the PrivX GUI are secured using TLS. The allowed SSL protocols and SSL ciphers may be adjusted if some browsers cannot establish connections to the PrivX GUI, or if you want to harden the PrivX instance.

The allowed SSL protocols and SSL ciphers are defined in the Nginx configuration file /etc/nginx/conf.d/privx.conf, by the parameters ssl_protocols and ssl_ciphers respectively, similarly to the following:

...
http {
    sendfile on;
    server_tokens off;

    ssl_protocols  TLSv1.2;
    ssl_ciphers 'AESGCM+EECDH:AESGCM+EDH:AES+EECDH: ... ';

    tcp_nodelay on;
...

After any adjustments to Nginx settings, restart the Nginx web server to apply the changes:

# systemctl restart nginx

For enabling TLS 1.3 support for PrivX frontend, see Enabling TLS 1.3

Was this page helpful?

On this page