Using SSL in a mixed environment

In a mixed environment, each link between Helix Server, proxies, or brokers may 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 may be configured to accept plaintext connections from older Helix Server applications, and to forward those requests (encrypted by SSL) to a Helix Server that requires SSL connections.
• A Helix Broker could 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 Server applications could use SSL to connect directly to the upgraded Helix Server (by setting P4PORT to ssl:new-server:1667), while users of older Helix Server applications could 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 could be deactivated (or reconfigured to require SSL connections), and any remaining legacy processes or scripts still attempting to connect via plaintext could 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 would with a single Helix Server. In order for 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.