Generate key and certificate

You can supply your own private key and certificate, or you can use p4d -Gc to generate a self-signed key and certificate pair.

Because the P4 Server can use self-signed certificates, you can also use third-party tools such as OpenSSL or PuTTY to generate the key pairs, or supply your own key pair.

This page refers to the directory specified by the P4SSLDIR environment variable as the P4SSSLDIR directory.

The p4d -Gf command accepts user-supplied credentials. If you are supplying your own key, your privatekey.txt and certificate.txt files in the P4SSSLDIR directory must be PEM-encoded, with the private key file stripped of passphrase protection.

Ensure that the P4SSSLDIR directory is a valid directory in a secure location. The P4SSSLDIR directory must be owned by the same userid as the userid:
- Running the P4 Server, proxy, or broker process. and
- Generating the key pair
Ensure that the P4SSSLDIR directory is not readable by any other user.
For example, on UNIX, use chmod to set the directory’s permissions to 0700 (drwx------) or 0500 (dr-x------).

(Optionally) Create a file named config.txt in this directory before running p4d -Gc, and format the file as follows:

Copy


# C: Country Name - 2 letter code (default: US)
C =

# ST: State or Province Name - full name (default: CA)
ST =

# L: Locality or City Name (default: Alameda)
L =

# O: Organization or Company Name (default: Perforce Autogen Cert)
O =

# OU = Organization Unit - division or unit
OU =

# CN: Common Name (usually the DNS name of the server)
# (default: the current server's DNS name)
CN =

# EX: number of days from today for certificate expiration
# (default: 730, that is, 2 years)
EX =

# UNITS: unit multiplier for expiration (defaults to "days")
# Valid values: "secs", "mins", "hours"
UNITS =

Generate the certificate and key pair with the following command:

p4d -Gc

If the P4SSSLDIR directory (and optional config.txt) has been correctly configured, and if no existing private key or certificate is found, two files, named privatekey.txt and certificate.txt, are created in the P4SSSLDIR directory.
These files correspond to the private key and certificate used for the SSL connection. These files are encoded according to the PEM format.

If a config.txt file is not present, the following default values are assumed, and a certificate is created that expires in 730 days (line 7), which is two years, excluding leap years.
Copy
```
1
2
3
4
5
6
7
8
C=US
ST=CA
L=Alameda
O=Perforce Autogen Cert
OU=
CN=the-DNS-name-of-your-server
EX=730
UNITS=days
```
Ensure that privatekey.txt and certificate.txt are owned by the userid that runs the P4 Server, proxy, and broker process.
Ensure that the privatekey.txt and certificate.txt have their permissions set to make them unreadable by other users.
On UNIX, for example, use chmod to set the permissions to 0600 (-rw-------) or 0400 (-r--------).
Generate a fingerprint for your server’s key and certificate pair.

p4d -Gf

This command displays the fingerprint of the server’s public key, and then exits. The fingerprint might be similar to this:
```
Fingerprint: CA:BE:5B:77:14:1B:2E:97:F0:5F:31:6E:33:6F:0E:1A:E9:DA:EF:E2
```
Record your server’s fingerprint for your own records.

Whether you supply your own key and certificate pair or generate one with p4d -Gc, ensure that these files are stored in a secure location that is readable only by the p4d binary.
Ensure that the P4SSSLDIR directory is configured with the correct file names and permissions and that the current date is valid for the certificate. To learn more, see "Unable to connect" message under Troubleshooting certificate validation errors.
Communicate the fingerprint to your users by using a secure method.so they can compare the fingerprint the server offers with the fingerprint you have provided. Inform your users that if the two fingerprints match, you users can use the p4 trust command to add the fingerprint to their P4TRUST files.

Instruct your users to inform you if a P4 Server application reports a different fingerprint because this might indicate message interception by a Man-in-the-middle attack. A different fingerprint is expected only if you have recently installed a new certificate and key pair.