Skip to main content
NetApp Knowledge Base

How does ONTAP send an AutoSupport using HTTPS?

  1. Last updated
  2. Save as PDF
Views:
4,191
Visibility:
Public
Votes:
3
Category:
ontap-9
Specialty:
CORE
Last Updated:

Applies to

  • ONTAP 9
  • Clustered Data ONTAP 8.3
  • Data ONTAP 8 7-mode
  • AutoSupport
  • Transport HTTPS

Answer

When ONTAP sends an AutoSupport via the HTTPS protocol it is acting as an HTTPS client.  

  • Here’s a diagram of the basic steps that occur when an HTTPS client attempts to establish encrypted communication with the server.

2017627__en_US__2017627ASUP_Cert_Process_v2.png

The major components are:

  • Client is the system that initiates the communication and desires an encrypted communication channel.  In this case, the autosupport subsystem on Data ONTAP storage controller is the client.
  • Server is the system that provides services that can be communicated over an encrypted communication channel.
AutoSupport Server URL Description
https://support.netapp.com/put/AsupPut   Support URL for HTTP/S PUT
https://support.netapp.com/asupprod/post/1.0/postAsup Support URL for HTTP/HTTPS

https://support.netapp.com/aods/asupmessage

 Used for AutoSupport OnDemand requests
  • Server Keystore, which resides on the server, contains a copy of the CA signed server public certificate file and private key file.  Only the server public certificate is shown .
    • The server public certificate contains the server’s public key as well as the Certificate Authority (CA) public key chain of the CA(s) that have signed the server certificate.
  • TrustStore, which resides on the client, contains a list the public keys of all of the CAs we trust.  
    • The cacert.pem file is where Data ONTAP store the public keys of all of the CAs that is trusted by the Autosupport https client and is used during certificate validation.

Here is how the encrypted channel is established

  1. The https client connects to the server and requests encrypted communication channel.
  2. The server responds back with the CA signed server certificate.  The signed certificate contains the server’s public key, and the public key chain of the CA(s) which signed the certificate.
  3. The client checks the CA chain in received server certificate and then verifies that CA can be trusted by checking the client’s TrustStore.  In Data ONTAP, there is a setting that can be set to bypass this step.
    a) If CA is trusted, certificate exchange continues in step #4.
    b) If CA is not trusted, then the client rejects the certificate and terminates the connection.
  4. Diffie-Hellman (DH) key exchange and encrypted handshake takes place to mutually determine the encrypted algorithm that is used for the session
  5. After encrypted handshake is complete, encrypted communication begins between client and server.

Additional Information

 

NetApp provides no representations or warranties regarding the accuracy or reliability or serviceability of any information or recommendations provided in this publication or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS and the use of this information or the implementation of any recommendations or techniques herein is a customer's responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.