Managing the SSL Certificate for the ESRS HTTPS Listener Service

Managing the SSL Certificate for the 

ESRS HTTPS Listener Service 

This document contains information on these topics: 

Technical Notes 

P/N 300-013-818 Rev 01 

July, 2012 

� 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 .................. 11 

� Troubleshooting ....................................................................................... 12 

1

Introduction 

2 

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. 

Managing the SSL Certificate for the ESRS Listener Service Technical Notes

HTTPS concepts 

Managing the SSL Certificate for the ESRS Listener Service Technical Notes 

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

Obtaining an appropriate X.509 certificate 

4 

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. 


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). 



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: 10.245.52.25 

2. Log in to the Control Station using SSH. Any valid user account is 


5


6 

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. 


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 

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: 



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 

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 


7. Click Save. 

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 DACEB92817329422A3C8A7421874EF1E8AFF67A3 

o NOT da ce b9 28 17 32 94 22 a3 c8 a7 42 18 74 ef 1e 8a ff 67 

a3 

� Your dialog box will look similar to the following (with 

some values specific to the site): 

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

Troubleshooting 

12 


/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 Is the IP address correct? Does the system hosting the 

EHL service have a static IP address? 

o 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 http://Support.EMC.com) 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. 


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

Managing the SSL Certificate for the ESRS HTTPS Listener Service

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?