How to Install TLS/SSL Certificates in NetApp Clustered Data ONTAP

HTTPS has definitively become the default and expected method for internet and web app communications that transmit sensitive data, taking the place of the insecure HTTP. TLS, the successor protocol to SSL, is the backbone to HTTPS and encrypts connections so transmitted sensitive information can’t be intercepted or modified.

Besides obvious application in internet communications, HTTPS should be used with local web applications that transmit data like credentials, activity events, sensitive content, and more. This includes communication with NetApp servers, as external applications and users need to authenticate, authorize, and transfer data with NetApp’s ONTAP OS.

HTTPS & TLS for NetApp Clustered Data ONTAP

To enable ONTAP cluster or SVM authentication as an SSL server, a digital certificate of type “server” must be installed at the cluster or SVM level. This certificate can be self-signed or, preferably, signed by a Certificate Authority (CA).

When a NetApp cluster or SVM is created, a self-signed server certificate is automatically created and installed as well. This results in SSL server authentication being enabled for the target cluster or SVM. However, additional self-signed or CA-signed certificates can be installed and used for SSL server auth in place of this default certificate.

In this blog, we’ll assume a certificate has been obtained from a trusted Certificate Authority, as that’s the most secure workflow for HTTPS. If you need to obtain a certificate from a Certificate Authority, NetApp can help with generating a CSR (Certificate Signing Request) first.

It’s also possible to use self-signed certificates for internal HTTPS communications, however, this isn’t a best practice. For this route, both the ONTAP CLI and OpenSSL can be used to generate self-signed certificates.

Installing TLS Certificates on an ONTAP Cluster or SVM

These example commands are at the SVM level but can easily be applied at the cluster level as well. These examples are also for a server-type certificate but can also be used to install “client-ca” certificates for secure ONTAP communications with external application servers.

First, make sure you have the server certificate’s public and private keys on hand. It’s also important to keep all private keys secure, as compromised private keys are a large security risk and need to be revoked and replaced. To install the server certificate, SSH into the cluster’s CLI interface and run the following command:

security certificate install -vserver <svm_name> -type server

When prompted, paste the public key, press ENTER, paste the private key, and press ENTER again. Be sure to copy/paste all headers and footers in the key, for example, “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–”.

Next, display information about server certificates on the cluster or SVM and find the recently installed certificate:

security certificate show -vserver <svm_name> -type server

The output should look like the following. In this case, a self-signed certificate was used for example purposes.

Vserver    Serial Number   Certificate Name                       Type
---------- --------------- -------------------------------------- ------------
dpi_svm    <cert_serial_num>
                           dpi_svm_1625F0D07A496E63               server
    Certificate Authority: dpi_svm
          Expiration Date: Wed Jul 28 14:27:01 2021

You’ll need the serial number, common name, and certificate authority properties from the certificate. If you need to display more information for a specific certificate, run the following command:

security certificate show -serial <cert_serial_number> -instance

With this information, you can modify the cluster or SVM’s SSL auth parameter so it uses the recently installed certificate. To do so, run the following command:

security ssl modify -vserver <svm_name> -server-enabled true -serial <cert_serial_number> -commonname <cert_common_name> -ca <cert_certificate_authority>

When prompted, you can continue to install root/intermediate certificates if required by your certificate chain. If you’re unsure of this process, refer to your Certificate Authority for more information on your specific chain.

In most cases, input “n” to finish installing the certificate. If warned of a self-signed certificate, and using a self-signed certificate is planned, input “y” to continue.

You can then verify the certificate is associated with the cluster or SVM’s server auth parameter by running:

security ssl show -vserver <svm_name> -instance

The output’s “SSL Server Authentication Enabled” value should be “true”, and the expected certificate’s serial number should be displayed.

                                         Vserver: dpi_svm
                   Server Certificate Issuing CA: dpi_svm
                Server Certificate Serial Number: <cert_serial_num>
                  Server Certificate Common Name: dpi_svm
               SSL Server Authentication Enabled: true

Certificate installation and SSL server auth configuration are now complete, and the cluster or SVM now supports network communication, as a server, via HTTPS.

HTTPS, NetApp ONTAP, & Stealthbits

Stealthbits’ StealthAUDIT and Activity Monitor communicate with NetApp Clustered Data ONTAP servers via the ONTAP API (ONTAPI) as well as FPolicy. For each of these workflows, it’s important to utilize HTTPS communications, and this blog helps take care of things on the NetApp side.

StealthAUDIT, Stealthbits’ full-fledged data access governance solution, ships with a root certificate store that includes many well-known and trusted Certificate Authorities, which simplifies the communication process once a corresponding CA-signed server certificate has been installed on NetApp clusters and SVMs in the network.

IDENTIFY THREATS, SECURE DATA, REDUCE RISK. Learn more about how Stealthbits can protect your organization here.