Planning secured IP partnerships

A secured IP partnership uses certificate-based authentication to create a secure communication channel between the partnered systems. You must ensure that the following requirements are met so that replicated data is encrypted and communication between partnered systems is secure.

Before you begin

To enable a secured IP partnerships, install an encryption license on both of the partnered systems. See Licensing encryption for more information, or contact support for assistance.

You must plan what type of system certificate the partnered systems will use. The system certificate is used for all functions on the system that use certificate authentication. A system certificate can be an internally signed certificate or an externally signed certificate. An internally signed certificate is a certificate that has been issued by the system's root certificate authority. If the system is currently using a self-signed certificate, the self-signed certificate can be used until it expires. After it expires, you must use either an internally signed certificate or an externally signed certificate. Externally signed certificates are issued and signed by a third-party CA. A signing request must be generated on the system and presented to the third-party CA, which signs the request and returns a signed certificate that can be installed. For more information about managing system certificates, see Configuring system certificates.

Mutual authentication
A secured IP partnership between the partnered systems requires the systems to be mutually authenticated. Mutual authentication requires that the system certificate or certificate authority certificate for each local system is installed in a truststore on the partner system. The local system presents its certificate and chain of signing CA certificates over the network when the secured partnership is established. The partner system authenticates the certificate presented by the local system by using the certificates and authorities that are installed in its truststore.
Setting up mutual authentication

To set up mutual authentication, you must install certificates on the partnered systems based on the type of certificate you choose. The system supports both internally-signed certificates and externally signed certificates.

Internally signed certificates
  • Create an internally signed certificate with either the management GUI or use the svctask chsystemcert -mksystemsigned command. The certificate is installed on the system automatically. To configure an internally-signed certificate, see Updating an internally signed certificate.
  • Export the system's root certificate to the partnered system's truststore.
Externally signed certificates
    • Generate a certificate signing request (CSR) with the management GUI or use the svctask chsystemcert -mkrequest command.
    • Send the CSR that is generated to your external CA.
    • When the third-party CA returns the signed certificate, install the certificate and the intermediate CA certificates on the system.
    • Install the third-party CA's root certificate in the partnered system's truststore. To configure an externally-signed certificate, see Requesting and installing an externally signed certificate.
The certificates are added to a system-wide truststore on the partnered system and managed with a set of CLI commands. For more information, see Truststore management commands.
When using an externally signed certificate, the certificate can be signed by the third-party root CA or by an intermediate CA which itself is signed by the third-party root CA. If an intermediate CA is used then there is a certificate chain, and the complete chain of trust must be established in order for one system to authenticate the other. The complete chain of trust can be established in the following ways:
  • Only the signed system certificate is installed on the local system. The local system presents only the endpoint certificate over the network and the intermediate CA certificates and root CA certificate must be installed in the truststore on the partner system.
  • The signed system certificate along with the intermediate CA certificates (the root CA certificate can optionally be included but is not required) are installed on the local system. The local system presents the endpoint certificate and the intermediate CA certificates over the network, and only the root CA certificate must be installed in the truststore on the partner system.
It is recommended that the full certificate chain is installed on the local system. If the full chain is not installed then errors in other functions that use certificate authentication such as the management GUI can occur.
Best practices for secured IP partnerships:
  • In a secured IP partnership, the partnered systems mutually authenticate with each other using certificates. These certificates have a validity period for which they are valid, and expire after this time. The certificate for each system can be configured separately, and may have a different validity period to the partner system’s certificate. Therefore, it is possible for one system’s certificate to expire while the partner system’s certificate is still valid. In this scenario, the certificate authentication for the IP partnership will fail. It is the best practice to:
    • Ensure the certificates of each system in the partnership are configured with similar validity periods to avoid disruption in the IP partnership.
    • Synchronize the date and time of each system.
  • User gets better encryption efficiency and better replication throughput in secured IP partnerships with higher MTU size. However, larger MTU sizes might not be possible outside controlled IP networks. Users need to plan this carefully with network administrators.
  • If MTU sizes configured at endpoints of a secured or unsecured IP partnership do not match, the partnership may remain in not_present state. Hence it is recommended to configure same MTU size at all endpoints such as IBM® Storwize® devices and network devices that are involved for establishing an IP partnership.