Currently if a user uses PKI CLI to connect to a PKI server but the server certificate was issued by an untrusted CA the CLI will ask the user whether to import (and trust) the CA certificate directly from the CA. If the CA is located on another server the CA URL can be specified. For example:

$ pki -c Secret.123 client-init --force
------------------
Client initialized
------------------
$ pki -U https://server.example.com:8443 -c Secret.123 cert-find
WARNING: UNTRUSTED ISSUER encountered on 'CN=server.example.com,OU=pki-tomcat,O=
EXAMPLE' indicates a non-trusted CA cert 'CN=CA Signing Certificate,OU=pkitomcat
,O=EXAMPLE'
Import CA certificate (Y/n)?
CA server URI [http://server.example.com:8080/ca]:

This mechanism has some limitations:
1. The CA must be running.
2. The CA must be a PKI CA such that the CA certificate can be downloaded from a specific path.
3. The CA certificate must be downloaded via unsecure port to avoid creating another SSL connection.

As a comparison, if a web browser receives a server certificate issued by an untrusted CA it will ask the user whether to trust the server certificate itself (that is already downloaded), it does not ask the user to download and trust the CA certificate from another location.

To avoid the above issues and for consistency with web browsers the PKI CLI could be modified to use a similar mechanism. For example:

$ pki -c Secret.123 client-init --force
------------------
Client initialized
------------------
$ pki -U https://server.example.com:8443 -c Secret.123 cert-find
WARNING: UNTRUSTED ISSUER encountered on 'CN=server.example.com,OU=pki-tomcat,O=
EXAMPLE' indicates a non-trusted CA cert 'CN=CA Signing Certificate,OU=pkitomcat
,O=EXAMPLE'
Available actions:
1. View certificate
2. Trust certificate temporarily
3. Trust certificate permanently
Select action (1/2/3):

In this case the CLI will import the server certificate into its NSS database and mark it as trusted peer. The user is responsible to ensure that the certificate can really be trusted.