Skip to main content
E-Series Systems

Manage security and certificates in Web Services Proxy

Contributors netapp-jolieg NetAppZacharyWambold
PDFs

For security in the Web Services Proxy, you can specify an SSL port designation and you can manage certificates. Certificates identify website owners for secure connections between clients and servers.

Enable SSL

The Web Services Proxy uses Secure Sockets Layer (SSL) for security, which is enabled during installation. You can change the SSL port designation in the wsconfig.xml file.

Steps

  1. Open the wsconfig.xml file, located at:

    • (Windows) — C:\Program Files\NetApp\SANtricity Web Services Proxy

    • (Linux) — /opt/netapp/santricity_web_services_proxy

  2. Add or change the SSL port number, similar to the following example:

    <sslport clientauth="request">8443</sslport>
Result

When the server is started with SSL configured, the server looks for the keystore and truststore files.

  • If the server does not find a keystore, the server uses the IP address of the first detected non-loopback IPv4 address to generate a keystore and then add a self-signed certificate to the keystore.

  • If the server does not find a truststore, or the truststore is not specified, the server uses the keystore as the truststore.

Bypass certificate validation

To support secure connections, the Web Services Proxy validates the storage systems' certificates against its own trusted certificates. If needed, you can specify that the proxy bypass that validation before connecting to the storage systems.

Before you begin

  • All storage system connections must be secure.

Steps

  1. Open the wsconfig.xml file, located at:

    • (Windows) — C:\Program Files\NetApp\SANtricity Web Services Proxy

    • (Linux) — /opt/netapp/santricity_web_services_proxy

  2. Enter true in the trust.all.arrays entry, as shown in the example:

    <env key="trust.all.arrays">true</env>

  3. Save the file.

Generate and import a host management certificate

Certificates identify website owners for secure connections between clients and servers. To generate and import Certificate Authority (CA) certificates for the host system where the Web Services Proxy is installed, you can use API endpoints.

To manage certificates for the host system, you perform the following tasks using the API:

  • Create a certificate signing request (CSR) for the host system.

  • Send the CSR file to a CA, and then wait for them to send you the certificate files.

  • Import the signed certificates to the host system.

Note You can also manage certificates in the Unified Manager interface. For more information, see the online help available in Unified Manager.
Steps

  1. Log in to the interactive API documentation.

  2. Go to the drop-down menu in the upper right and then select v2.

  3. Expand the Administration link and scroll down to the /certificates endpoints.

  4. Generate the CSR file:

    1. Select POST:/certificates, and then select Try it out.

      The web server regenerates a self-signed certificate. You can then enter information in the fields to define the common name, organization, organization unit, alternate ID, and other information used to generate the CSR.

    2. Add the required information in the Example values pane to generate a valid CA certificate, and then execute the commands.

      Note Do not call POST:/certificates or POST:/certificates/reset again, or you must regenerate the CSR. When you call POST:/certificates or POST:/certificates/reset, you are generating a new self-signed certificate with a new private key. If you send a CSR that was generated before the last reset of the private key on the server, the new security certificate does not work. You must generate a new CSR and request a new CA certificate.

    3. Execute the GET:/certificates/server endpoint to confirm that the current certificate status is the self-signed certificate with the information added from the POST:/certificates command.

      The server certificate (denoted by the alias jetty) is still self-signed at this point.

    4. Expand the POST:/certificates/export endpoint, select Try it out, enter a file name for the CSR file, and then click Execute.

  5. Copy and paste the fileUrl into a new browser tab to download the CSR file, and then send the CSR file to a valid CA to request a new web server certificate chain.

  6. When the CA issues a new certificate chain, use a certificate manager tool to break out the root, intermediate, and web server certificates, and then import them to the Web Services Proxy server:

    1. Expand the POST:/sslconfig/server endpoint and select Try it out.

    2. Enter a name for the CA root certificate in the alias field.

    3. Select false in the replaceMainServerCertificate field.

    4. Browse to and select the new CA root certificate.

    5. Click Execute.

    6. Confirm that the certificate upload was successful.

    7. Repeat the CA certificate upload procedure for the CA intermediate certificate.

    8. Repeat the certificate upload procedure for the new web server security certificate file, except in this step, select true on the replaceMainServerCertificate drop-down.

    9. Confirm that the web server security certificate import was successful.

    10. To confirm that the new root, intermediate, and web server certificates are available in the keystore, run GET:/certificates/server.

  7. Select and expand the POST:/certificates/reload endpoint, and then select Try it out. When prompted, whether you want to restart both controllers or not, select false. ("True" applies only in the case of dual array controllers.) Click Execute.

    The /certificates/reload endpoint usually returns a successful http 202 response. However, the reload of the web server truststore and keystore certificates does create a race condition between the API process and the web server certificate reload process. In rare cases, the web server certificate reload can beat the API processing. In this case, the reload appears to fail even though it completed successfully. If this occurs, continue to the next step anyway. If the reload actually failed, the next step also fails.

  8. Close the current browser session to the Web Services Proxy, open a new browser session, and confirm that a new secure browser connection to the Web Services Proxy can be established.

    By using an incognito or in-private browsing session, you can open a connection to the server without using any saved data from previous browsing sessions.