PowerStore: How to replace the self-signed cluster management certificate with a certificate issued by an external certificate authority
Summary: This article provides step-by-step instructions on how to replace PowerStore's self-signed certificate used for management with a certificate issued by an external Certificate Authority (CA). ...
Instructions
Note: In general PowerStore does not support 3rd Party CAs signing the GUI certificate. The browser forum prohibits CAs from signing certs with restricted IPs in the certificate, since private IPs are included in the restricted list and also required in the certificate by PowerStore the CA will decline the request. The only possibility to get a certificate signed by a 3rd Party CA would be to use public IPs provided by an ISP or IANA for the management network.
This article refers to a certificate signed by a private enterprise CA (for example, using OpenSSL, Microsoft CA, or something similar)
This article covers PowerStoreOS 2.1. For newer versions of PowerStore OS see PowerStore: Creating and Importing a Signed HTTPS Management Certificate
The initial support for replacing PowerStore Management self-signed certificates with external CA issued ones, comes in a limited form in PowerStoreOS version 2.1.
Besides securing the user interface (UI) access using HTTPS, the cluster management certificate has other uses, such as various internal communications, and so on.
The following restrictions apply during the initial introduction of the feature which was delivered with PowerStoreOS version 2.1.
These restrictions and limitations apply to PowerStoreOS version 2.1.x for a private CA signed server certificate import. These restrictions and limitations do not apply to PowerStoreOS versions 3.0 or later.
- Third-party certificate import is not supported on
- A multi-appliance cluster
- A cluster that is in replication relationship with another cluster
- Cluster that has SDNAS configured
- A Unified system (File + Block)
- Reverting back to original PowerStore CA signed certificate is not supported once third-party certificate is imported for a cluster.
- There are no alerts generated for certificate expiration.
- The certificate to be imported should be valid for at least 30 days or greater.
- Third-party certificate import is not supported using PowerStore Manager UI.
- Third-party certificate import is only supported for Management traffic ( Management_HTTP ) and not for any other services (such as VASA, Replication, and so on).
Important: Review and understand these restrictions fully if running PowerStoreOS 2.1. Do NOT proceed, if your system falls into one of the categories listed above.
How to import a certificate issued by an external Certificate Authority using the PowerStore Manager user interface
The manual cli procedure should only be required for systems running PowerStoreOS version 2.1.
For systems running PowerStoreOS v3 and above, use the PowerStore Manager user interface to import the certificate.
For more details, see the PowerStore Security Configuration Guide.
PowerStore Manager Web UI Signed Cluster Certificate Window:
How to import a certificate issued by an external Certificate Authority using the CLI
Step 1 - Retrieve cluster IPv4/IPv6 address
The first step is to retrieve cluster IPv4/IPv6 (Management) address. This IP is embedded in the current self-signed Management certificate. This is also the same IP address that you would type in your browser to connect to the PowerStore Manager user interface.
Step 1a
Retrieve the list of all certificates.
$ pstcli -u admin -p <password> -d <cluster_ip> x509_certificate show
# | id | type | service | is_current | is_valid
----+--------------------------------------+--------+------------------+------------+----------
1 | 00907634-b4eb-446a-a381-aae685bae066 | Server | Management_HTTP | yes | yes
2 | 9d0ec275-3688-4ae2-922b-639e1cfb0b88 | Server | VASA_HTTP | yes | yes
3 | c5f03cf7-fe1d-40bd-b6fb-7abba0c6026a | Client | Replication_HTTP | yes | yes
<trimmed for brevity>
Make a note of the id field of the certificate with the service Management_HTTP and the type Server.
Step 1b
Get the full details of the current self-signed Management certificate.
Run the command below, replacing id with the value that you retrieved in Step 1a.
$ pstcli -u admin -p <password> -d <cluster_ip> x509_certificate -id 00907634-b4eb-446a-a381-aae685bae066 show
id = 00907634-b4eb-446a-a381-aae685bae066
type = Server
type_l10n = Server
service = Management_HTTP
service_l10n = Management_HTTP
is_current = yes
is_valid = yes
members:
subject = CN=Dell EMC PowerStore CA E79NFK8T,O=Dell EMC,ST=MA,C=US
serial_number = 14daac34e1db4711
signature_algorithm = SHA384withRSA
issuer = CN=Dell EMC PowerStore CA E79NFK8T,O=Dell EMC,ST=MA,C=US
valid_from = 11/16/21 23:16:33
valid_to = 10/30/89 23:16:33
public_key_algorithm = RSA
key_length = 4096
thumbprint_algorithm = SHA-256
thumbprint_algorithm_l10n = SHA-256
thumbprint = 279ea39ad7b8d2e0f3695a850a7d302e8318e080e1092fccb314c8f4f19e50a4
certificate = MIIFdDCCA1ygAwIBAgIIFNqsNOHbRxEwDQYJKoZIhvcNAQEMBQAwVzELMAkGA1UEBhMCVVMxCzAJBg
<trimmed for brevity>
Ar4eTY0aBe7R8fnSbg97EFqF+1gGhKlxrOU9AICgZJDh0PDQJRcYLFJBi36Ktt++mtRgpSig8VvypZ
depth = 2
subject_alternative_names =
subject = C=US+O=Dell+L=Hopkinton+OU=PowerStore+ST=Massachusetts+CN=ManagementHTTP.xxxxxxxxxxxx
serial_number = xxxxxxxxxxxxx
signature_algorithm = SHA256withRSA
issuer = CN=Dell EMC PowerStore CA E79NFK8T,O=Dell EMC,ST=MA,C=US
valid_from = 11/16/21 23:56:23
valid_to = 11/15/26 23:56:23
public_key_algorithm = RSA
key_length = 4096
thumbprint_algorithm = SHA-256
thumbprint_algorithm_l10n = SHA-256
thumbprint = eedf2f9c1d0f70f018857110e87cd122f4fa31140e694c30b5ea10398629dbf1
certificate = MIIFejCCA2KgAwIBAgIJANlUDR+8+78qMA0GCSqGSIb3DQEBCwUAMFcxCzAJBgNVBAYTAlVTMQswCQ
<trimmed for brevity>
ZTShTW0BFh3IeAgt23Tlhz+npsJNqbvxXB+8hXqvNWcpzeSluiUalqB3qU9MwCzwHpEkXqagzk8EZM
depth = 1
subject_alternative_names = aaa.bbb.ccc.ddd, 1111:2222:3333:4444:5555:6666:7777:8888
You get two certificates in the output: the PowerStore Internal CA and the Management certificate signed by that Internal CA.
The management certificate has depth = 1 field, and the subject_alternative_names field is populated with the IPv4 and IPv6 IP addresses.
If you are using IPv4 to manage your cluster, you should see the IPv4 Cluster Management IP as the first one in the subject_alternative_names field (as in the example above - aaa.bbb.ccc.ddd). If you are using IPv6 to manage your cluster, write down the first IPv6 address.
Step 2 - Generating Certificate Signing Request (CSR)
How to generate a CSR which is later taken to a Certificate Authority for signing.
Step 2a
Run the following command to produce the help on generating CSR and familiarize yourself with its syntax:
$ pstcli -u admin -p <password> -d <cluster_ip> help x509_certificate csr
x509_certificate csr -type { Server | Client | CA_Client_Validation | CA_Server_Validation } -service { Management_HTTP | Replication_HTTP | VASA_HTTP | Import_HTTP | LDAP_HTTP | Encrypt_HTTP | Syslog_HTTP } -dns_name <value>,...
-ip_addresses <value>,... -key_length <2048..4096> [ -scope <value> ] [ -common_name <value> ] [ -organizational_unit <value> ] [ -organization <value> ] [ -locality <value> ] [ -state <value> ] [ -country <value> ] [ { -passphrase
<value> | -passphraseSecure } ] [ -async ]
<trimmed for brevity>
The bolded options above are mandatory, all others are optional. Consult with your CA or PKI Administrator if your company certificate policy requires the use of any of these optional fields.
Step 2b
Generate a CSR using the guidelines above.
$ pstcli -u admin -p <password> -d <cluster_ip> x509_certificate csr -type Server -service Management_HTTP -dns_name "powerstoreXY.mycompany.com" -ip_addresses aaa.bbb.ccc.ddd -key_length 2048 -scope "External" -common_name "powerstoreXY.mycompany.com"
The output of the command returns an id and the CSR in BASE64 encoding. For example:
1 | 81ea4b51-4b80-4a88-87f1-f0a0ddd1c1fd | Server | Management_HTTP | Management_HTTP | no | no | -----BEGIN CERTIFICATE REQUEST----- MIIDJTCCAg0CAQAwezF5MAkGA1UEBhMCVVMwCwYDVQQKEwREZWxsMBAGA1UEBxMJ <trimmed for brevity> h4t6QVXny+nF25XASq49kuZ8aWA0aTwU8VN5lC0qbSA2Zy6uX8jPmf/ecGNSQzIc 6iDIm76HbL7UKlDecSmr7WiR5hZ9bP/zKxmkNlTN1viqtInGl+zZa6U= -----END CERTIFICATE REQUEST-----
Copy the id that you received in the output (bolded above), as it is needed for later steps.
You must also format the CSR (using VIM, or any text editor such as Notepad). The first line must be -----BEGIN CERTIFICATE REQUEST----- while the last line must end with -----END CERTIFICATE REQUEST-----. There must be no leading or ending spaces anywhere.
An example of a formatted CSR:
-----BEGIN CERTIFICATE REQUEST----- MIIDJTCCAg0CAQAwezF5MAkGA1UEBhMCVVMwCwYDVQQKEwREZWxsMBAGA1UEBxMJ SG9wa2ludG9uMBEGA1UECxMKUG93ZXJTdG9yZTAUBgNVBAgTDU1hc3NhY2h1c2V0 <trimmed for brevity> h4t6QVXny+nF25XASq49kuZ8aWA0aTwU8VN5lC0qbSA2Zy6uX8jPmf/ecGNSQzIc 6iDIm76HbL7UKlDecSmr7WiR5hZ9bP/zKxmkNlTN1viqtInGl+zZa6U= -----END CERTIFICATE REQUEST-----
Save your CSR in a file with a meaningful name. For example: powerstoreXY.csr
Step 2c (Optional)
If you are confident that your CSR is properly formatted, you can skip this step.
If you would like to verify the validity of it, you can use OpenSSL suite of tools to confirm that it can be read and that the data within the fields of the CSR looks correct. For example, using the values provided in Step 2b, the bolded fields in the CSR should reflect that:
$ openssl req -in powerstoreXY.csr -noout -text
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=US, O=Dell, L=Hopkinton, OU=PowerStore, ST=Massachusetts, CN=powerstoreXY.mycompany.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:af:cd:73:7a:d7:71:03:67:d6:f9:46:9f:aa:68:
<trimmed for brevity>
90:c4:68:44:71:bd:d7:64:65:81:36:90:2e:c2:15:
b8:f5
Exponent: 65537 (0x10001)
Attributes:
Requested Extensions:
X509v3 Subject Alternative Name:
DNS:powerstoreXY.mycompany.com, IP Address:aaa.bbb.ccc.ddd, IP Address:1111:2222:3333:4444:5555:6666:7777:8888
Signature Algorithm: sha256WithRSAEncryption
15:f6:08:8e:ab:f6:07:91:82:ed:45:f0:d9:4d:8c:f5:c6:e3:
<trimmed for brevity
16:7d:6c:ff:f3:2b:19:a4:36:54:cd:d6:f8:aa:b4:89:c6:97:
ec:d9:6b:a5
If all looks correct, go to the next step.
Step 3 - Submitting CSR to a private CA for signing
This step varies from vendor to vendor. The goal here is to submit your CSR to the issuing Certificate Authority using the vendor's recommended procedures to receive a signed certificate encoded as BASE64.
Step 3a
Verify that the newly issued certificate is BASE64 encoded. Ensure that the file starts with -----BEGIN CERTIFICATE----- and ends with -----END CERTIFICATE----- and contains encoded data in between.
$ cat powerstoreXY.cer -----BEGIN CERTIFICATE----- MIIGFjCCA/6gAwIBAgITdAAAAA4SiEpOgIXLggABAAAADjANBgkqhkiG9w0BAQsF <trimmed for brevity> 7NcBrSr0Ach8rC443vrqLSChaTZFt1TtYiSJJT+ZEL2F0/TG9BTXBbHKFTVFXgf9 l9dWpDkH6mq/fhgaMNT/vuMCUtD40fj81DE= -----END CERTIFICATE-----
Step 3b
Confirm that the certificate you received contains the values for the attributes that you have requested when you generated CSR, specifically DNS, and IP addresses in the Subject Alternative Name. Depending on the procedures involved in producing and signing the certificate by the Certificate Authority, the certificate may or may not contain them.
$ openssl x509 -in powerstoreXY.cer -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
74:00:00:00:0e:12:88:4a:4e:80:85:cb:82:00:01:00:00:00:0e
Signature Algorithm: sha256WithRSAEncryption
Issuer: DC=com, DC=mycompany, CN=Issuing CA
Validity
Not Before: Nov 26 16:51:16 2021 GMT
Not After : Nov 26 16:51:16 2023 GMT
Subject: C=US, ST=Massachusetts, L=Hopkinton, O=Dell, OU=PowerStore, CN=powerstoreXY.mycompany.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:af:cd:73:7a:d7:71:03:67:d6:f9:46:9f:aa:68:
<trimmed for brevity>
90:c4:68:44:71:bd:d7:64:65:81:36:90:2e:c2:15:
b8:f5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:powerstoreXY.mycompany.com, IP Address:aaa.bbb.ccc.ddd, IP Address:1111:2222:3333:4444:5555:6666:7777:8888
X509v3 Subject Key Identifier:
1C:19:5D:DF:B4:F0:9F:B7:7B:2B:4A:0E:09:B3:C6:43:3E:CF:4D:4C
X509v3 Authority Key Identifier:
keyid:25:D0:D5:01:27:75:BD:08:FF:E7:FF:02:6C:CE:17:46:86:50:DD:71
X509v3 CRL Distribution Points:
Full Name:
URI:http://pki.mycompany.com/pki/Issuing%20CA.crl
Authority Information Access:
CA Issuers - URI:http://pki.mycompany.com/pki/ca-iss.mycompany.com_Issuing%20CA.crt
1.3.6.1.4.1.311.20.2:
...W.e.b.S.e.r.v.e.r
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
Signature Algorithm: sha256WithRSAEncryption
99:d9:99:a7:7a:b9:4a:e8:e3:66:ed:56:1f:6f:bc:71:b8:07:
<trimmed for brevity>
97:d7:56:a4:39:07:ea:6a:bf:7e:18:1a:30:d4:ff:be:e3:02:
52:d0:f8:d1:f8:fc:d4:31
If you do not see DNS and IP attributes that you have requested in CSR in your certificate's X509v3 Subject Alternative Name (example bolded above), consult with your CA Administrator to address this.
Do NOT proceed further until you confirmed that the required attributes are present in the certificate.
Step 3c
This step involves building complete certificate chain in a single BASE64 encoded file, which must contain your PowerStore certificate plus certificates for each and every CA within the hierarchy involved in signing your certificate.
Using a hypothetical Public Key Infrastructure (PKI) consisting of the following entities:
Root CA > Issuing CA > Leaf
Where
- Root CA - is the top of the hierarchy and it only signs and issues certificates for the Issuing CAs. It is typically never involved into signing certificates for the endpoints.
- Issuing CA - this is what would typically issue certificates to various endpoints.
- Leaf - the endpoints, such as workstations, servers, and so on. Your PowerStore system falls into this category.
Depending on how your PowerStore certificate was issued, the file you received back may only contain a single certificate for your PowerStore endpoint (leaf) or it may contain the entire chain (leaf + issuingCA + rootCA). You cannot import a file containing just a single leaf certificate into PowerStore in the next steps. You must create a complete chain (leaf + issuingCA + rootCA) as one single BASE64 encoded PEM file containing all three (or more, if you have more CAs in the chain) certificates.
If you do not already have, you must obtain BASE64 encoded certificates for your Issuing CA and Root CA and combine them with the PowerStore's leaf certificate into one single PEM file:
$ cat powerstoreXY.cer issuingca.cer rootca.cer > combined.pem
Open the combined.pem file with a text editor and remove any ending or leading spaces and blank lines. Also, the body of the certificates (data between the BEGIN/END CERTIFICATE tags) must be a single line string.
The resulting combined.pem file should look similar to the example below:
$ cat combined.pem -----BEGIN CERTIFICATE----- MIIGFjCCA/6gAwIBAgITdAAAAkiG9w0BAQs<trimmed for brevity><PowerStore leaf cert>7NcBrSr0Ach8rC443vrqLSChaTZF0fj81DE= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIGXjCCBEagAwIBDANBgkqhkiG9w0BAQ0F<trimmed for brevity><Issuing CA cert>HU+TePFvwmGruno8fGI4iLyh5kWjnWW2SZVI4wWQ= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIFCzCCAvOgAwIyoqhkiG9w0BAQ0FAuDAX<trimmed for brevity><Root CA cert>wRh/EXhVd32yvTxupm288LcH3UU3iGHx0tHieAGEkT0= -----END CERTIFICATE-----
Step 4 - Importing signed certificate chain
In this final step, you replace the PowerStore self-signed certificate by importing the complete chain, consisting of your new signed certificate and all CAs. You need the certificate id that you produced in Step 2b.
If you did not write it down, run the following command to get that id again:
$ pstcli -u admin -p <password> -d <cluster_ip> x509_certificate show # | id | type | service | is_current | is_valid ----+--------------------------------------+--------+------------------+------------+---------- 1 | 81ea4b51-4b80-4a88-87f1-f0a0ddd1c1fd | Server | Management_HTTP | no | no 2 | 00907634-b4eb-446a-a381-aae685bae066 | Server | Management_HTTP | yes | yes 3 | c5f03cf7-fe1d-40bd-b6fb-7abba0c6026a | Client | Replication_HTTP | yes | yes 4 | 9d0ec275-3688-4ae2-922b-639e1cfb0b88 | Server | VASA_HTTP | yes | yes
Note the certificate of service Management_HTTP that is NOT valid and is NOT current. In the example above, id 81ea4b51-4b80-4a88-87f1-f0a0ddd1c1fd is the one you need.
Run the following command to import the chain:
$ pstcli -u admin -p <password> -d <cluster_id> x509_certificate -id <cert_id> set -is_current true -certificate '<contents_of_the_combined.pem_file>'
For example:
pstcli -u admin -d self x509_certificate -id 81ea4b51-4b80-4a88-87f1-f0a0ddd1c1fd set -is_current true -certificate $'-----BEGIN CERTIFICATE-----\n[...Single line PowerStore certificate content...]\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\n[...Single line CA Certificate certificate content...] \n-----END CERTIFICATE-----'
Alternatively, when using a linux station with PSTCLI (such as SSH on the PowerStore), you can tell the BASH interpreter to use anything in between the $' ' exactly as is, including the formatting. In this instance, it is not required to append the "new line \n":
pstcli -u admin -d self x509_certificate -id 81ea4b51-4b80-4a88-87f1-f0a0ddd1c1fd set -is_current true -certificate $'-----BEGIN CERTIFICATE-----
MIIGFjCCA/6gAwIBAgITdAAAAA4SiEpOgIXLggABAAAADjANBgkqhkiG9w0BAQsF<trimmed for brevity><PowerStore leaf cert>7NcBrSr0Ach8rC443vrqLSChaTZFt1TtYiSJJT+ZEL2F0/TG9BTXBbHKFTVFXgf9l9dWpDkH6mq/fhgaMNT/vuMCUtD40fj81DE=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIGXjCCBEagAwIBAgITQgAAAARkLTTf7tqFAQAAAAAABDANBgkqhkiG9w0BAQ0F<trimmed for brevity><Issuing CA cert>HU+TePFvwmGruno8o65kK+qWvvYG10PbMbIYxxm/zyofGI4iLyh5kWjnWW2SZVI4wWQ=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFCzCCAvOgAwIBAgIQad6TNg7Pqa5HsuYzLFAK5jANBgkqhkiG9w0BAQ0FADAX<trimmed for brevity><Root CA cert>wRh/EXhVd32yvTxOdBGBBENLQnD6U6HkA4FO/jVbXR2B793giBmi9w85+B7obgWPSTypIgA+LKG3nE0jf5AW5LnOV+gQDCOsSJlGpm288LcH3UU3iGHx0tHieAGEkT0=
-----END CERTIFICATE-----'
At this point, you should have the new certificate installed and operational. You must close and restart your browser to see new certificate. Reconnecting with PSTCLI also gives you a warning that the certificate thumbprint has changed, which is an indicator that the new certificate was installed successfully.