Managing the SSL Certificate for the ESRS HTTPS Listener Service Technical Notes P/N Rev 01 July, 2012

Transcription

1 Managing the SSL Certificate for the ESRS HTTPS Listener Service Technical Notes P/N Rev 01 July, 2012 This document contains information on these topics: Introduction... 2 Terminology... 2 HTTPS Concepts... 3 Obtaining an Appropriate X.509 Certificate... 4 Configuring the ESRS HTTPS Listener Service to Use the Appropriate X.509 Certificate... 7 Configuring ConnectHome to Verify the Server Identity Troubleshooting

2 Introduction Introduction Terminology This technical note presents a method for securing the HTTPS connection between the ConnectHome feature on a Control Station and the EMC Secure Remote Support (ESRS) HTTPS Listener Service installed on a host system that is running Microsoft Windows. After you have installed and configured the two components and the connection is shown to be working (by using the default HTTPS configuration), you should provide the ESRS HTTPS Listener Service with an X.509 certificate that is specific to the system that is hosting the service. This action allows any ConnectHome client to verify the server identity. ESRS HTTPS Listener (EHL) Service HTTPS A component of the ESRS IP Client that accepts the HTTPS event notifications from a ConnectEMC client application that is running on an EMC device. HTTP Secure, also known as HTTP over SSL X.509 Certificate (also commonly referred to as an SSL Certificate ) PKI A form of identification in which a subject s name is bound to a public key. The signer of the certificate is asserting that the entity using the certificate is who (or what) they say they are. Public Key Infrastructure Certificate Authority The entity that verifies that the identifying information in an X.509 certificate is legitimate. 2

3 HTTPS concepts HTTPS concepts HTTPS protects the HTTP exchanges between two systems. Typically, this protection uses encryption to protect the traffic over the network and enables the client, which is the system initiating the exchange, to verify the identity of the server. You can use HTTPS without verifying the server s identity, but this leaves the exchange open to man-in-themiddle attacks. In order for a client system to verify the identity of the server, the server will present to a client an X.509 certificate that identifies the server and is associated with a private key to which only the server system should have access. This allows the HTTPS handshake process to use a challenge and response protocol in which the client system can verify that the server has the private key associated with the certificate and, to the extent that the certificate is trusted, be assured that it is communicating with the right server. Logically, three systems are involved in establishing a valid HTTPS connection. These are: The client system that initiates a connection. For the purposes of this technical note, this is the Control Station which is initiating a ConnectHome call. The server system that receives the connection and may be expected to verify its identity. The Certificate Authority (CA), which verifies that the information in the X.509 certificate used by the server is correct (that is, the server is what or who it says it is). The CA can be either an external signing authority or the server system itself. In the latter case, this results in a self-signed certificate. The server is essentially stating that it is what it says it is. Before any clients can verify the server s identity, the server must obtain a suitable X.509 certificate. This certificate is signed by some entity to verify the information is correct, even if that entity is the server itself. Once this certificate is in place and the client initiates a connection to the server, the server presents the client with this certificate. The client verifies that the information in the certificate agrees with what it expected (typically, that either the hostname or IP address match what it used to connect to the server) and then must decide how trustworthy the certificate is (who signed it and whether to believe that signing 3

4 Obtaining an appropriate X.509 certificate authority). The following sections describe how to obtain and install a suitable certificate on the EHL hosting system and how to configure the Control Station to accept it. Obtaining an appropriate X.509 certificate The following sections describe different methods for obtaining or generating an X.509 certificate. Environments with an internal Certificate Authority If you are installing the EHL service and the ConnectHome feature in an environment that has a Certificate Authority (CA) in place, then an established process should exist for generating a Certificate Signing Request (CSR) for the system hosting the EHL service. Follow this process to install the resulting signed certificate on the EHL hosting system using the site s documented process. The process for enabling the Control Station to recognize this authority is described in the section Configuring ConnectHome to verify the server identity. Where there is an appropriate certificate already installed To verify if an appropriate X.509 certificate is installed already on the system hosting the EHL service: 1. On the Windows system hosting the EHL service, start the Microsoft Management Console (MMC). From Start menu select Run. Enter mmc as the command to run. 2. Add the Certificates snap-in for the Local Computer (See the Windows system s online help for more detailed instructions). 4

5 Obtaining an appropriate X.509 certificate 3. In the list on the left-hand side of the screen, select: Certificates (Local Computer) Personal Certificates 4. In the right-hand pane, find the certificate that identifies the system by IP address or hostname. Be sure that the certificate has a corresponding private key. In the case where a suitable certificate is already in place, determine the signing authority (either a Certificate Authority or self-signed) and locate the corresponding public certificate so that the Control Station can verify the server s identity (discussed in section Configuring ConnectHome to verify the server identity). Using the Control Station to generate a self-signed X.509 certificate If the environment does not have a preferred method or mechanism for generating an X.509 certificate and a suitable certificate is not installed already, use the Control Station to generate a suitable certificate. Follow these steps: 1. Record either the IP address or the fully qualified hostname of the system hosting the EHL service. Record the form of the host ID that you will use for configuring ConnectHome. This example uses the following IP address: IP Address: Log in to the Control Station using SSH. Any valid user account is 5

6 Obtaining an appropriate X.509 certificate acceptable; you do not need to be the root user. 3. Generate a self-signed X.509 certificate with a corresponding private key with the command (all on one line): This command creates a self-signed certificate (the subject and issuer are the same) and a corresponding key (mycert.pem and mykey.pem, respectively). This certificate has a key length of 1024 bits and is valid for one year. To have a larger key size, change the -newkey argument to rsa:2048. To change the length of time for which the certificate is valid, change the argument to the -days option. NOTE: It is important to protect the private key (mykey.pem). If this is compromised, the security of the HTTPS connection is compromised. 4. Type the following command (all on one line) to bundle the resulting certificate (mycert.pem) and associated private key (mykey.pem) into a PKCS #12 bundle that can be imported on the Windows system that is hosting the EHL service: 5. Transfer the resulting PKCS #12 file (mypkg.p12) to the Windows system that is hosting the EHL service. When transferring this file, remember to indicate that it is a binary file. You can delete the private key file mykey.pem from the Control Station once the transfer is complete. Retain a copy of the public certificate, mycert.pem, for later use. 6

7 Configuring the ESRS HTTPS Listener Service to use the appropriate X.509 certificate Configuring the ESRS HTTPS Listener Service to use the appropriate X.509 certificate The two steps required to configure the ESRS HTTPS Listener Service to use the appropriate certificate are: 1. Importing the X.509 certificate into the certificate store (if it s not already there). 2. Configuring the EHL service to use the new certificate. Importing an X.509 certificate and corresponding private key Once you have transferred the PKCS #12 file to the system hosting the EHL service, use the following steps to import the X.509 certificate: 1. Start the Microsoft Management Console (MMC). 2. Add the Certificates snap-in for the local computer. (See the online help for more detailed instructions.) 3. In the list on the left-hand side of the screen, select: Certificates (Local Computer) Personal Certificates 4. Right-click the Certificates folder, select All Tasks Import, and follow the prompts to import the PKCS#12 certificate bundle from its location. 5. Once the import has completed, double click on the resulting certificate. A dialog box similar to the following should appear. 7

8 Configuring the ESRS HTTPS Listener Service to use the appropriate X.509 certificate Note that the Issued to: and Issued by: entries are the same value. This indicates the certificate is self-signed. Next note that the certificate store considers the certificate to be untrusted. You should make the certificate trusted for this system by importing the public certificate into the Trusted Root Certification Authorities store. Do this by importing the PKCS#12 bundle into the certificate store again but into a different folder. The process is the same as outlined above except that in step 3, select Certificates (Local Computer) Trusted Root Certification Authorities Certificates. Once you have done this, the original certificate similar to the following should appear: 8

9 Configuring the ESRS HTTPS Listener Service to use the appropriate X.509 certificate Configuring the EHL Service to use the installed certificate Once a suitable certificate is installed in the certificate store, you must configure the EHL to use it. The following steps describe how to configure the EHL service to use the appropriate X.509 certificate: 1. In the Certificates snap-in, double-click the certificate (see step 5 in the previous procedure). 2. Select the Details tab and find the Thumbprint value. This should be a SHA 1 hash of the certificate and should look similar to the following: 9

10 Configuring the ESRS HTTPS Listener Service to use the appropriate X.509 certificate 3. Make a note of the thumbprint value. 4. In a Windows shell, go to the location where the esrshttps.exe is installed; for example: 5. Run the command esrshttps.exe config. 6. In the dialog box that appears, make sure the following values are set as shown: Scheme = https IP Address = The IP address for the system hosting the EHL service. This value should be the same in the X.509 certificate. Port = 443 Root Dir: As appropriate for the ESRS IP Client installation location. In the example above, it would be: C:\Program Files\EMC\ESRS IP Client 10

11 Configuring ConnectHome to verify the server identity SSLHASH = The SHA 1 thumbprint value recorded in step 3 above. Enter this value without spaces and with the letters (if any) in UPPERCASE o DACEB A3C8A EF1E8AFF67A3 o NOT da ce b a3 c8 a ef 1e 8a ff 67 a3 Your dialog box will look similar to the following (with some values specific to the site): 7. Click Save. 8. Verify that the esrshttps.exe.config file includes the correct values. If any values differ from what is expected, you can edit the config file directly. 9. Start (or restart) the EHL service. 10. Verify in the log file that the service started correctly using the supplied certificate. The log file lists the supplied SSLHash value that is being used and verifies that it was found in the certificate store. Configuring ConnectHome to verify the server identity The ConnectHome feature can verify the server identity of the EHL service host if the public certificate of the signing authority has been copied to the Control Station. If the EHL host is using a self-signed certificate, this would be the public certificate that is presented. If an internal CA signed the, then this would be the public certificate of the CA. In either case, make sure that the certificate is in PEM form. To point the ConnectHome feature to the right certificate, use the command: nas_connecthome modify https_ca_file 11

12 Troubleshooting Troubleshooting /path/to/cert/mycert.pem To enable verification of the EHL system address, use the command: nas_connecthome https_verify_server yes Once you have completed these two commands, verify the connection with the command: nas_connecthome test https If the HTTPS connection from the ConnectHome client to the EHL service is not working, consider the following: Verify that the connection was working before any certificate changes were made. In some environments, you may need to change internal firewall settings. Verify the information in the X.509 certificate that the EHL service is using. o o Is the IP address correct? Does the system hosting the EHL service have a static IP address? Is the value that the certificate has for the host the same as the one that the ConnectHome client is using? They should both have either the IP address or the hostname. Do not mix and match and do not supply both values in the X.509 certificate. Verify that the esrshttps.exe.config file has the information you expect. Be sure to verify the thumbprint. Look at the esrshttps.log file in the EHL log directory. It may indicate the system cannot locate the certificate or that the HTTPS port (443) is already in use by another service. If it is the latter, use a different port or stop the competing service. For instructions on changing the port, go to the EMC Online Support website (at and locate the EMC Secure Remote Support IP Solutions Guide. Verify that the appropriate Certificate Authority public X.509 certificate is on the Control Station and configured correctly for the ConnectHome client. 12

13 Troubleshooting Copyright 2012 EMC Corporation. All Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS IS." EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. All other trademarks used herein are the property of their respective owners. 13