• Advanced Configuration

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 Components

PrivX Extenders, Carriers, and Web Proxies are issued certificates, which need to be renewed periodically. Each PrivX deployment issues these using the following Certificate Authorities (CA):

  • PrivX Extender/Carrier
  • PrivX Web-Proxy (ICAP)

By default, these CAs are valid for five years. Note that Carriers and Extenders share the same CA.

Each individual component is issued an End Entity (EE) certificate on registration, from its respective component CA. By default, these EE certificates are valid for two years.

In addition to the previous CAs, the Database Proxy also offers a CA certificate which can be optionally used by database clients to verify their connections to PrivX.

Renewing EE certificates

  1. Navigate to the appropriate component deployment page.

    • PrivX Extender: Administration→Deployment→Deploy PrivX VPC/VPN Extenders
    • PrivX Web-Proxy/Carrier: Administration→Deployment→Deploy PrivX Web Access Gateways

  2. Click ☰ next to the component configuration, then Unregister the component. Unregistering a Web-Proxy will unregister its associated Carrier as well.

  3. Gain root terminal access to the component server. Remove the current EE certificate:

    • Extender: /opt/privx/extender/extender.crt
    • Carrier: /opt/privx/carrier/carrier.crt
    • Web-Proxy: /opt/privx/cert/web-proxy.crt

  4. Run the component's postinstall script as root:

    • Extender: /opt/privx/scripts/extender-postinstall.sh
    • Carrier: /opt/privx/scripts/carrier-postinstall.sh
    • Web-Proxy: /opt/privx/scripts/web-proxy-postinstall.sh

    The postinstall script acquires a new certificate and registers the component.

  5. Back at the deployment page, verify that the component status is Registered.

Renewing CA certificates

  1. Navigate to the appropriate component deployment page. Note that Carriers use the Extender CA.

    • PrivX Extender/Carrier: Administration→Deployment→Deploy PrivX VPC/VPN Extenders
    • PrivX Web-Proxy: Administration→Deployment→Deploy PrivX Web Access Gateways

  2. Locate the CA Certificate section and click Renew. Creating a new CA may take a while depending on the PrivX environment.

  3. Once the new CA has been created, ensure that its Not Valid After time is later than that of the original CA and that the original CA is still designated as the Primary CA.

  4. Perform EE certificate renewal for each of the affected components as described in the previous section. Note that new EE certificates are enrolled using the CA with the furthest expiration time, not the Primary CA.

  5. Once all components are using the new CA, it can be set as the Primary CA and the old CA can be removed.

Renewing the Database Proxy CA certificate

  1. Navigate to Administration→Deployment→Native Client CA Certificates.

  2. Click Renew to create a new CA. After the CA has been created, you should see two Database Proxy CAs. The old CA should still be marked as the Primary CA.

  3. Instruct users to update their database clients with the new certificate bundle. This can be done by selecting any configured database target from the PrivX UI, opening CA Certificate Details, clicking Copy to Clipboard and saving it in the client configuration. The new certificate bundle includes both CAs and should work immediately.

  4. Once users have installed the new certificate bundle, the new CA can be set as the Primary CA. After this, any clients still using the old certificate bundle will be unable to verify the connection. You may remove the old CA.

PrivX Access Groups

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

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.

  2. 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

  3. 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.

  4. 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

  5. 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?