p4 trust

Establish trust of an SSL connection to a Perforce service.

If you have not yet established trust with your server, use the p4 trust -h command to get help for the server. You must do this because the command is implemented on the client rather than the server. When a command begins with p4 help, the client forwards it to the server to construct the text of what is displayed on the client machine.

In the case of the trust command, the client might not trust the server to send any commands to it, so the help must begin with p4 trust to get it serviced locally by the client rather than have it forwarded to the server.

Syntax

p4 [g-opts] trust [-l -y -n -d -f -r] [-i fingerprint]

Syntax conventions

Description

Use p4 trust to manage the P4TRUST file. By default, the .p4trust is in your home directory. This file establishes and manages the trust of an SSL connection.

The trust file contains the fingerprints of the keys received for SSL connections. When you first connect to a Helix Core service, you are prompted with its fingerprint. If the fingerprint is correct, you can use p4 trust to add the service’s fingerprint to your trust file. If the fingerprint changes or expires, subsequent attempts to connect to that service result in warning or error messages.

Your system administrator can help you confirm the accuracy of any fingerprint provided to you by a Helix Core service.

Only after you have added an SSL-enabled Helix Core service to your P4TRUST file can you connect to it by setting P4PORT to ssl:hostname:port.

SSL connections that do not require P4TRUST

2021.2 and later: P4TRUST is no longer required for SSL connections where the server provides a certificate that is not self-signed and can be verified by the client. Servers, proxies, and brokers can send complete SSL certificate chains to the client. This happens automatically when multiple certificates are included in the certificate.txt file. The chain certificates should follow the end-entity certificate.

Note

  • Clients based on the 2021.2 C/C++ P4API, and the APIs derived from it, such as P4Python, P4Ruby, and P4Perl, verify the server's SSL certificate against the local system's CA certificate store and compare the certificate's subjects with the host portion of the P4PORT used by the client. (See Helix Core C/C++ Developer Guide.)

  • If the certificate authority (CA) path is not present in the system's CA store, or if validation against a specific CA is required, the CA path can be specified with the ssl.client.ca.path client-side configurable.

  • To revert to the prior P4TRUST mechanism, set the ssl.client.cert.validate client-side configurable to 0 .

  • To skip the CA validation, and only ensure that the server certificate's subject matches the client's P4PORT, set ssl.client.cert.validate to 2.

  • The p4 trust command can still be used regardless of the server certificate validation, creating P4TRUST records for the IP of the server and, if the server's certificate isn't self-signed, also the hostname. The hostname recording can be disabled by setting the ssl.client.trust.name client-side configurable to 0.

  • Setting ssl.client.trust.name to 2 prevents p4 trust from recording the IP address of the server, but p4 trust will still only record hostnames for servers without self-signed certificates.

  • Both ssl.client.trust.name and ssl.client.cert.validate can be set for clients in P4CONFIG files, or passed into the client using -v of Global options.

  • Proxies and Brokers will accept the configurable as part of P4DEBUG or -v.

  • p4 configure set can be used to apply to all server-to-server SSL connections. This requires a complete stop and restart of the server for the change to take effect.

  • Client-side configuration on servers does not apply to clients connecting to the server.

Options

-d

Delete an existing trusted fingerprint.

-f

Force the replacement of a mismatched fingerprint.

-i fingerprint

Install the specified fingerprint.

-l

List all known fingerprints on this client workstation.

-n

Automatically refuse any prompts.

-r

List, install, or delete a replacement fingerprint. If a replacement fingerprint exists for the connection, and the primary fingerprint does not match (but the replacement fingerprint does), the replacement fingerprint replaces the primary. This option may be combined with the -l, -i, or -d options.

-y

Automatically accept any prompts.

g-opts

See Global options.

Usage Notes

Can File Arguments Use Revision Specifier? Can File Arguments Use Revision Range? Minimal Access Level Required

N/A

N/A

none because every user can run p4 trust, whether a standard user, operator user, or a service user