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/path target-user@bilberry.example.com:/target/file/path

Verify and set the allowed target ports on your Web Proxy machines in /etc/squid/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.