Tech ONTAP Blogs

E-Series: Using a custom certificate for ASUP when deploying an HTTPS Interceptor

MitchBlackburn
NetApp
1,382 Views

Overview

Some customers have asked about using custom certificates for ASUP over HTTPS. This is not required for direct HTTPS ASUP access since support.netapp.com uses a certificate signed by a trusted CA that is pre-installed on NetApp ASUP clients (for example the host-based PM in SANtricity Storage Manager, embedded ASUP, web services proxy / SANtricity Unified Manager), and pretty much all web browsers. So, when would a custom certificate be needed for ASUP? This is needed when the customer is using an HTTPS Interceptor.

 

The E-Series engineer Sean Olson documented a standard way for a customer to inspect the HTTPS traffic for ASUP. This is done with the use of an HTTPS/SSL Interceptor as explained in the rest of this blog post.

 

What is an HTTPS Interceptor?

An HTTPS Interceptor (also called SSL Inspection, SSL Interception) is a form of an HTTPS proxy. It takes an HTTPS connection from a client and instead of simply forwarding the connection to the remote server, the interceptor performs a TLS/SSL handshake with the client using a certificate (or generated certificates) for which the interceptor has the private key. The interceptor then opens a separate HTTPS connection to the remote server. This allows the interceptor to be able to decrypt, inspect, and modify all traffic between the original client and the remote server. If this sounds like a Man-In-The-Middle (MITM) attack to you, then you are correct. The client will detect this condition and error out when the certificate(s) the HTTPS interceptor is exposing to the client are not trusted. Generally, this means the CA certificate for the HTTPS Interceptor needs to be installed on the client for it to be trusted.

 

Why use an HTTPS Interceptor?

If an HTTPS Interceptor is a MITM, then why would a customer knowingly use one? Security vendors tout HTTPS Interception to audit and/or prevent encrypted connections from carrying malicious payloads, company IPs, or other sensitive data. Some examples are as follows:

Does the E-Series ASUP implementation support the use of an HTTPS Interceptor?

This question could be reworded to "Does the E-Series ASUP implementation support trusting user installed certificates?" The answer is yes, but the ease of use and supportability varies by platform and controller firmware (CFW) level.

 

E2800 and E5700 running CFW 11.40.5 or later and all EF300 and EF600

Using SANtricity System Manager

  1. Go to Settings → Certificates → Trusted → Import
  2. Click Browse and select the certificate to trust (must be on filesystem accessible by web browser)
  3. If not using a transparent HTTPS Interceptor, then a proxy must be configured for ASUP:

          Support → Support Center → AutoSupport → Configure AutoSupport Delivery Method

           Ensure Delivery Method is set to HTTPS

           Set the Connect to support team… radial button to “via Proxy server” and fill in the proxy details

 

Using REST API

  1. From System Manager main page choose Help > API Documentation, this opens online documentation at /devmgr/docs
  2. Use command Administration → POST /certificates/remote-server, two parameters required – provide alias and select the certificate to trust

       For more information about the REST API see:

 

Using Secure CLI

  1. Command: download storageArray trustedCertificate alias="MITM_CACERT_ALIAS" file="PATH_TO_MITM_CACERT_FILE";

        For more information about the SANtricity CLI see: SANtricity System Manager commands

 

E2800 and E5700 running earlier than 11.40.5

The recommendation for CFW earlier than 11.40.5 is to have the user upgrade to 11.40.5 or later and follow the above instructions.

 

Now, you just need to configure your HTTPS Interceptor and you can inspect the ASUPs your storage array sends out.

Public