Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 Server Administration Documentation | 2025.2

# Connecting services

Services working together in a multi-server environment must be able to authenticate and trust one another.

- When using SSL to securely link servers, brokers, and proxies together, each link in the chain must trust the upstream link.
- It is best practice to use ticket-based authentication instead of password-based authentication. This means that each service user for each server in the chain must also have a valid login ticket for the upstream link in the chain. Ticket-based authentication is mandatory at Server security levels 4 (and higher).

## Managing trust between services

The user that owns the server, broker, or proxy process is typically a service user (see p4 user in the P4 CLI Reference). As the administrator, you must create a `P4TRUST` file on behalf of the service user by using the ``p4 trust`` command. By default, a user’s `P4TRUST` file resides in that user's home directory with `.p4trust` as the file name.

See Tell P4 Server applications which port to connect to.

## Managing tickets between services

When linking servers, brokers, and proxies together, each service user must be a valid service user at the upstream link, and it must be able to authenticate with a valid login ticket.

To set up service authentication:

1. On the upstream server, use `p4 user` to create a user of type `service` with a name such as `serviceuser`.

2. Consider creating a group for your service users. See Group for service users (recommended).

3. The ticket for a service user defaults to unlimited in 2025.2 and later.
   For 2025.1 and earlier: To prevent the service user logins from timing out, you can use the p4 group command to add the service user to a group with the Timeout field set to `unlimited`. See Tickets and timeouts for service users.

4. Set the access level for the service user or service user’s group to `super` in your protections table. See Access level for service users.

5. Set the level of security to 4 or higher on the target server. See Server security levels.
   For example,
   $ p4 -u super configure set security=4

6. Use `p4 passwd` to assign the service user a strong password.

7. On the downstream server, use `p4 login` to log in to the upstream server Any server in the inward direction, that is, toward the central server. For example, in an edge-to-edge configuration with a commit, edge1, and edge2, both edge1 and the commit server are upstream servers for edge2. See also 'central server'. as the newly-created service user, and to create a login ticket for the service user that exists on the downstream server.

8. Ensure the `P4TICKETS` configurable for the downstream server is set correctly. This enables the downstream server to correctly read the ticket file to check whether the service user is logged in to the upstream service.

## Managing SSL/TLS key pairs

When configured to accept SSL/TLS connections, all server processes (`p4d`, `p4p`, `p4broker`), require a valid certificate and key pair on startup.

To create a key pair,

- Set the directory and permissions. See `P4SSLDIR` in the P4 CLI Reference.
- Generate pairs of `privatekey.txt` and `certificate.txt` files, and make a record of the key’s fingerprint:
  - On the server, use `p4d -Gc` to create the key/certificate pair and `p4d -Gf` to display its fingerprint.
  - On the broker, use `p4broker -Gc` to create the key/certificate pair and `p4broker -Gf` to display its fingerprint.
  - On the proxy, use `p4p -Gc` to create the key/certificate pair and `p4p -Gf` to display its fingerprint.

You can also supply your own private key and certificate. See SSL/TLS connections between client and server.

Your search for returned results