The initial setup has generated a certificate-signing request (CSR), which can be enrolled with a trusted CA for a trusted server certificate. The CSR is located at the following path on the PrivX server:

/etc/nginx/ssl/nginx.csr

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

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

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

Finally, restart the Nginx and PrivX services to start using the new server certificate:

# systemctl restart nginx
# systemctl restart privx

Gain root-terminal access to a PrivX server, and display the PrivX-CA-key ID by running:

# /opt/privx/bin/keyvault-tool -name "PrivX CA Key" list-asymmetric

Generate a Certificate-Signing Request (CSR) for the CA private key (replace <key_id> with the PrivX-CA-key ID):

# /opt/privx/bin/cert-tool -command create -type authorizer-ca \
-subject "OU=PrivX Authorizer CA/CN=PrivX CA" \
-key <key_id> -csr -csrout privx-im-ca.csr

This creates the CSR to the file privx-im-ca.csr in your current working directory.

Request a trusted CA to sign the CSR with the following constraints:

After the trusted CA provides you with the signed certificate, you may verify its constraints with (replace privx-im-ca.crt  with the path to the signed certificate):

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

Replace the Authorizer certificate. First, obtain the ID of the current Authorizer certificate:

# /opt/privx/bin/cert-tool -command list -type authorizer-ca

Then delete the current Authorizer certificate (replace <cert_id> with the Authorizer-certificate ID):

# /opt/privx/bin/cert-tool -command delete -id <cert_id>

Finally, import the signed certificate (replace <key_id> with the PrivX-CA-key ID, replace privx-im-ca.crt  with the path to the signed certificate):

# /opt/privx/bin/cert-tool -command import -type authorizer-ca \
-key <key_id> -in privx-im-ca.crt

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

# systemctl restart privx

Subsequent certificates issued by PrivX are signed using the new trusted Authorizer CA certificate.

Run the rotation script from a PrivX server in the deployment:

# /opt/privx/scripts/rotate_privx_ca.sh

The old PrivX CA certificates are deleted and new ones are generated. The script will then restart PrivX.

On hosts with certificate authentication enabled, configure trust for the new PrivX CA. To do this:

Run the rotation command on a PrivX server in the deployment:

# /opt/privx/bin/keyvault-tool rotate-auth-keys

This generates new authentication keys.

On all PrivX servers, restart the PrivX services:

# systemctl restart privx

On all your PrivX servers, enable the forwarder_enabled setting in /opt/privx/etc/ssh-proxy.toml

And restart PrivX services to apply the changes:

systemctl restart privx

Session recording must be disabled on hosts that are to be accessed using proxied native-client connections. For more detailed instructions about toggling session recording, see the section called “Session Recording Setup”.

(Optional) To simplify native-client commands, specify the required connection parameters in the users' client configuration (typically at /etc/ssh/ssh_config or ~/.ssh/config). You can do this using Host blocks that at least specify:

For example:

Host bilberry
    HostName example-extender/bilberry.example.com
    ProxyCommand privx-nc -x $PRIVX_AGENT_PROXY %h %p

As the native-client user, start the PrivX agent (if not already started) and use it to log into PrivX.

If you have specified the required parameters in your SSH-client configuration, you can connect simply using the appropriate Host block. For example:

$ ssh target-user@bilberry

$ sftp target-user@bilberry

$ scp source/file/path target-user@bilberry:/target/file/path

Otherwise, you must additionally provide the ProxyCommand and the name of the PrivX Extender, similar to the following:

$ ssh -o "ProxyCommand privx-nc -x $PRIVX_AGENT_PROXY %h %p" \
target-user@example-extender/bilberry.example.com

$ sftp -o "ProxyCommand privx-nc -x $PRIVX_AGENT_PROXY %h %p" \
target-user@example-extender/bilberry.example.com

$ scp -o "ProxyCommand privx-nc -x $PRIVX_AGENT_PROXY example-extender/%h %p"\
source/file/pathtarget-user@bilberry.example.com:/target/file/path

Add the name of the session-affinity cookie to the known_lb_cookies setting. The setting is located in the following configuration file on the Extender:

Restart the Extender with:

# systemctl restart privx-extender

Verify and set the allowed target ports on your Web-Proxy machines in /opt/privx/etc/squid.conf

For example, to allow access to HTTPS target running on port 9443, you would need to add the port to SSL_ports:

acl SSL_ports port 443
acl SSL_ports port 9443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 1025-65535  # unregistered ports
acl CONNECT method CONNECT

Port 9443 is already included in Safe_ports by default.

Restart the squid service to apply the changes:

# systemctl restart squid

Add rules like the following to the Squid configuration at /opt/privx/etc/squid.conf

# Match all PrivX users belonging to the privx-admin role
acl is_privx_admin req_header User-Agent Role\=privx-admin

# Define restricted address(es)
acl restricted_to_certain_privx_roles ssl::server_name www.example.com

# Allow privx-admins to access restricted address(es)
http_access allow is_privx_admin restricted_to_certain_privx_roles

# Deny others access to restricted address(es)
http_access deny restricted_to_certain_privx_roles

Restart the squid service to apply the changes:

# systemctl restart squid

On your PrivX Web Proxy, add the CA-certificate chain of the web target to the system trust anchors: Save the CA-certificate-chain file under

/etc/pki/ca-trust/source/anchors/

Then run:

# update-ca-trust extract

Restart the Squid service to apply the changes:

# systemctl restart squid

(Optional) Perform this step if you need to enable websocket connections from the web target.

On your PrivX Carrier, add the CA-certificate chain of the web target to your PrivX-Carrier configuration at:

/opt/privx/etc/carrier-config.toml

Then restart the Carrier and Docker services to apply the changes:

# systemctl restart privx-carrier
# systemctl restart docker

Add the name of the session-affinity cookie to the known_lb_cookies setting. The setting is located in the following configuration files, for Carriers and Web-Proxies respectively:

Restart the Carrier and Web-Proxy services. On your Carriers, run:

# systemctl restart privx-carrier

And on your Web-Proxies, run:

# systemctl restart privx-web-proxy