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
- (US) East US
- (US) East US 2
- (US) South Central US
- (US) West US 2
- (US) West US 3
- (Asia Pacific) Australia East
- (Asia Pacific) Souteast Asia
- (Europe) North Europe
- (Europe) Sweden Central
- (Europe) UK South
- (Europe) West Europe
- (US) Central US
- (Africa) South Africa North
- (Asia Pacific) Central India
- (Asia Pacific) East Asia
- (Asia Pacific) Japan East
- (Asia Pacific) Korea Central
- (Canada) Canada Central
- (Europe) France Central
- (Europe) Germany West Central
- (Europe) Norway East
- (Europe) Switzerland North
- (Middle East) UAE North
- (South America) Brazil South
- (US) East US 2 EUAP
- (Middle East) Qatar Central
- (US) North Central US
- (US) West US
- (US) Central US EUAP
- (US) West Central US
- (Asia Pacific) Australia Central
- (Asia Pacific) Australia Central 2
- (Asia Pacific) Australia Southeast
- (Asia Pacific) Japan West
- (Asia Pacific) Korea South
- (Asia Pacific) South India
- (Asia Pacific) West India
- (Canada) Canada East
- (Europe) UK West
- (Middle East) UAE Central
- US East (N. Virginia)
- US East (Ohio)
- US West (N. California)
- US West (Oregon)
- Canada (Central)
- EU (Frankfurt)
- EU (Ireland)
- EU (London)
- EU (Paris)
- EU (Stockholm)
- EU (Milan)
- Asia Pacific (Hong Kong)
- Asia Pacific (Singapore)
- Asia Pacific (Sydney)
- Asia Pacific (Seoul)
- Asia Pacific (Tokyo)
- Asia Pacific (Osaka)
- Asia Pacific (Mumbai)
- South America (Sao Paulo)
- Middle East (Bahrain)
- Africa (Cape Town)
- AWS GovCloud (US-East)
- AWS GovCloud (US-West)
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 Managing certificates for secure communications.
- 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.
The network planning requirements for Secured IP partnership are same as the existing IP partnership requirements. For information about IBM Storage Virtualize for Public Cloud networking considerations, see Planning networking for Microsoft Azure.