P4SSLDIR

Description

Directory containing a server’s SSL keys and/or certificates.

Usage Notes

Used by Client? Used by Server? Command-Line Alternative Can be set in P4CONFIG file?

No

Yes

None

No

Value if not Explicitly Set

Operating System Value

All

If P4SSLDIR is set to any value, the directory named by P4SSLDIR stores the files that contain server ssl credentials. If this variable is unset, or if the permissions of P4SSLDIR or its contents are incorrect, the service will not start in SSL mode.

Examples

/path/to/dir

Notes

All Perforce server processes (p4d, p4p, p4broker) that accept SSL connections require a certificate and key pair (stored in this directory) on startup. In order for any of these processes to start, the following additional conditions must be met:

  • P4SSLDIR must be set to a valid directory.
  • The P4SSLDIR directory must be owned by the same userid as the one running the Perforce server, proxy, or broker process. The P4SSLDIR directory must not be readable by any other user. On UNIX, for example, the directory’s permissions must be set to 0700 (drwx------) or 0500 (dr-x------).

  • Two files, named privatekey.txt and certificate.txt, must exist in P4SSLDIR.

    These files correspond to the PEM-encoded unencrypted private key and certificate used for the SSL connection. They must be owned by the userid that runs the Perforce server, proxy, and broker process, and must also have their permissions set such as to make them unreadable by other users. On UNIX, for example, the files' permissions must be set to 0600 (-rw-------) or 0400 (-r--------).

    You can supply your own private key and certificate, or you can use p4d -Gc to generate a key and certificate pair. For more information, see the Helix Versioning Engine Administrator Guide: Fundamentals.

  • To generate a fingerprint from your server’s private key and certificate, run p4d -Gf. (P4SSLDIR must be configured with the correct file names and permissions, and the current date must be valid for the certificate.)

    After you have communicated this fingerprint to your end users, your end users can then compare the fingerprint the server offers with the fingerprint you have provided. If the two fingerprints match, users can use p4 trust to add the fingerprint to their P4TRUST files.