In the initial article in this series, we took a look at the OneFS SSL architecture, plus the first two steps in the basic certificate renewal or creation flow:
The procedure below includes options to complete a self-signed certificate replacement or renewal, or to request an SSL replacement or renewal from a Certificate Authority (CA).
Signing the SSL Certificate
At this point, depending on the security requirements of the environment, the certificate can either be self-signed or signed by a Certificate Authority.
a. Self-Sign the SSL Certificate.
The following CLI syntax can be used to self-sign the certificate with the key, which creates a new signed certificate which, in this instance, is valid for 1 year (365 days):
# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
To verify that the key matches the certificate, ensure that the output of the following CLI commands return the same md5 checksum value:
# openssl x509 -noout -modulus -in server.crt | openssl md5 # openssl rsa -noout -modulus -in server.key | openssl md5
Next, proceed to the ‘Add certificate to cluster’ section of this article once this step is complete.
b. Use a CA to Sign the Certificate.
If a CA is signing the certificate, ensure that the new SSL certificate is in x509 format, and includes the entire certificate trust chain.
Note that the CA may return the new SSL certificate, the intermediate cert, and the root cert in different files. If this is the case, the PEM formatted certificate will need to be created manually.
Also, the correct ordering is important when creating the PEM-formatted certificate. The SSL cert must be the top of the file, followed by the intermediate certificate, and with the root certificate at the bottom. For example:
-----BEGIN CERTIFICATE----- <Contents of new SSL certificate> -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- <Contents of intermediate certificate> <Repeat as necessary for every intermediate certificate provided by your CA> -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- <Contents of root certificate file> -----END CERTIFICATE-----
A simple method for creating the PEM formatted file from the CLI is to ‘cat’ the in the correct order as follows:
# cat CA_signed.crt intermediate.crt root.crt > onefs_pem_formatted.crt
Copy the onefs_pem_formatted.crt file to /ifs/tmp and rename it to server.crt.
Note that if any of the above files are generated with a ‘.cer’ extension, it should be renamed with a .crt extension instead.
The attributes and integrity of the certificate can be sanity checked with the following CLI syntax:
# openssl x509 -text -noout -in server.crt
Adding the certificate to the cluster.
The first step in adding the certificate involves importing the new certificate and key into the cluster:
# isi certificate server import /ifs/tmp/server.crt /ifs/tmp/server.key
Next, verify that the certificate imported successfully:
# isi certificate server list -v
Note that the following CLI command can be used to show just the names and corresponding IDs of the certificates:
# isi certificate server list -v | grep -A1 "ID:"
Set the freshly imported certificate to be the default:
# isi certificate settings modify --default-https-certificate=<id_of_cert_to_set_as_default>
Confirm that the imported certificate is being used as default by verifying status of ‘Default HTTPS Certificate’:
# isi certificate settings view
If there is an unused or outdated certificate, it can be deleted with the following CLI syntax:
# isi certificate server delete --id=<id_of_cert_to_delete>
Next, the new imported certificate can be viewed and verified with the following CLI command:
# isi certificate server view --id=<id_of_cert>
Note that ports 8081 and 8083 still use the certificate from the local directory for SSL. Follow the below steps if you want to use the new certificates for port 8081/8083.
# isi services -a isi_webui disable# chmod 640 server.key# chmod 640 server.crt# isi_for_array -s 'cp /ifs/tmp/server.key /usr/local/apache2/conf/ssl.key/server.key'# isi_for_array -s 'cp /ifs/tmp/server.crt /usr/local/apache2/conf/ssl.crt/server.crt'isi services -a isi_webui enable
Verifying the SSL certificate.
There are two simple ways of verifying the updated SSL certificate: Either via the CLI, using the ‘openssl’ command as follows:
# echo QUIT | openssl s_client -connect localhost:8080
Or via a web browser, using the following URL:
https://<cluster_name>:8080
Note that where <cluster_name> is the FQDN or IP address that’s typically used to access the cluster’s WebUI interface. The security details for the web page will contain the location and contact info, as above.
In both cases, the output includes location and contact info. For example:
Subject: C=US, ST=<yourstate>, L=<yourcity>, O=<yourcompany>, CN=isilon.example.com/emailAddress=tme@isilon.com
Additionally, OneFS provides warning of an impending certificate expiry by sending a CELOG event alert along the lines of the following:
SW_CERTIFICATE_EXPIRING: X.509 certificate default is nearing expiration: Event: 400170001 Certificate 'default' in '**' store is nearing expiration:
Note that OneFS does not attempt to automatically renew a certificate. Instead an expiring cert has to be renewed manually, per the procedure described above.
When adding an additional certificate, any time you connect to that SmartConnect name via HTTPS, the matching cert is used. If no matching certificate is found, OneFS will automatically revert to using the default self-signed certificate.