SSL in a mixed environment

In a mixed environment, each link between Helix Core Server, proxies, or brokers can be configured to be in either plaintext or SSL, independent of the encryption choice for any other link. Consider the following examples:

• During a migration from cleartext to SSL, a Helix Broker can be configured to accept plaintext connections from older Helix Core Server applications, and to forward those requests (encrypted by SSL) to a Helix Core Server that requires SSL connections.
• A Helix Broker can be configured to listen on tcp:old-server:1666, and redirect all requests to a target of ssl:new-server:1667. Users of new Helix Core Server applications can use SSL to connect directly to the upgraded Helix Core Server (by setting P4PORT to ssl:new-server:1667), while users of older Helix Core Server applications can continue to use plaintext when connecting to a Helix Broker (by setting P4PORT to old-server:1666). After migration is complete, the broker at old-server:1666 can be deactivated (or reconfigured to require SSL connections), and any remaining legacy processes or scripts still attempting to connect via plaintext can be upgraded manually.

The Helix Proxy and the Helix Broker support the -Gc and -Gf flags, and use the P4SSLDIR environment variable. You generate certificate and key pairs for these processes (and confirm fingerprints) as you do with a single Helix Core Server. To enable two servers to communicate over SSL, the administrator of the downstream server (typically a replica server, Proxy, or Broker process) must also use the p4 trust command to generate a P4TRUST file for the service user associated with the downstream server.

When migrating from a non-SSL environment to an SSL-based environment, it is your responsibility to securely communicate the new server’s fingerprint to your users.