SSL/TLS Security

Managing Certificated

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 Certificated

PrivX Servers

Issue new certificate(s) according to SSL/TLS Security.

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 PrivX CA as Sub CA in CA Hierarchy.

PrivX ICAP

Trusted Server Certificated

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 Access Certificated

PrivX Authorizer issues access certificates using its own CA, which is self-signed by default. For production deployments we recommend replacing the Authorizer CA with one signed by a trusted certificate authority, as described in PrivX CA as Sub CA in CA Hierarchy.

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