EMS Secure Client

Introduction

Purpose

The purpose of this document is to explain the EMS Secure Connection feature and how to configure and maintain the Secure Connection interface.

Applies To

This feature applies to the EMS Secure Connection Feature which is present in the SR31.3 and above releases.

EMS Secure Connection Description

Prior to the SR31.3 release the EMS supported a limited form of encryption on the EMS client to EMS server interface.  This encryption interface only encrypted specific information within the EMS Client to EMS Server flow.  It would encrypt authentication credentials and certain other critical fields.  The Secure Connection feature encrypts the entire flow so that all data going between the client and server is encrypted in a TLS 1.2 encrypted flow.  This provides for much better security between the EMS client and server.

Tellabs vs Local Certificates

Once the Secure Connection feature is installed on the EMS, it will by default use the Tellabs self signed certificates.  This allows the server and client to authenticate that the software being used is genuine Tellabs software.  It does not authenticate the identity of the client session.

If you add local certificates to the EMS and client software installations of the Tellabs software with a locally generated certificate, then it will verify this certificate.  This will prevent anyone without a locally generated certificate from even attempting to connect to the server.  Their session will be refused in the initial TLS handshake and will never be able to connect.

Installing Secure Connection

During the EMS client or server install, you can install the Secure Connection by choosing the Custom Installation and selecting "Secure Connection".  This will enable Secure Connection and will ensure that all connections utilize Encryption when connecting a client session.  This must be selected when installing the server and, on each client, install.  If a Secure Connection is installed on the server, but not on the client, the client will not be allowed to connect with an unsecure connection.

Select Custom on the Install Menu at the Installation Options Section: 

Then on the next menu, Enable Secure Connection Between EMS Client and Server.  Select the Secured Connection option and it will be enabled during the install: 

Enabling Secured Connection on Existing Installs

The Secure Connection Feature is always installed but is only enabled if selected on the Custom Install screens.  If you did not select Secure Connection on install and later want to start utilizing this feature, you can turn on Secure Connection via a batch file.

The batch file is found on the server in the location: 

c:TellabsPanoramaPONbbmgrserver

To enable the secure connection for all clients, from an Admin Command Prompt (cmd.exe run as Administrator) execute the batch file: 

 enableSecureConnection.bat

To disable the secure connection for all clients, from an Admin Command Prompt (cmd.exe run as Administrator) execute the batch file:  

disableSecureConnection.bat

Using Default Tellabs Certificates

The client and server when Secured Connection is selected will automatically install and use default Tellabs certificates.

If you are using the default certificates, no further action needs to be taken and the connection is secured.  Using default certificates does not authenticate the server or client, but just ensures that the communications is securely encrypted and use genuine Tellabs software.  

Using Locally Created Certificates

One if the key purposes of Certificates is the ability to authenticate or validate the identity of the client and server to each other upon establishing a secure TLS connection.  

Certificates will authenticate when several conditions exist: 

• The Certificate Date Range is Valid.
• The receiver of the certificate has a trust anchor for that certificate.  A trust anchor is the CA certificate of the Certificate Authority which created the certificate being presented.  The trust anchor essentially always says trust any certificate created by this CA.  The issuer of the CA certificate and the issuer of the certificate being received must agree.
• The IP / hostname is validated and the IP in the message matches the DNS lookup for that IP/Hostname.
• The certificate is validated using the CA public certificate. This is a mathematical calculation that ensures the CA did create the certificate.

Installing Local Certificates

The certificates are installed on the server using the CertificateMgr.bat file.  The instructions for performing the certificate install can be found in the AppNote Securing OLAN with Certificates.  

The same procedure and batch file is used to install the certificates on the client and the server.

The Anchor certificate (Public CA Certificate for the site) must be installed on the client and the server.

The client and server must each have a device certificate which is unique to that machine.  The device certificate must have either the hostname as the CN of the certificate (or windows machine name) or have the CN set to the IP address.  In addition, they should have a Subject Alternative Name that includes the IP address if possible.  This will prevent the system from doing a DNS lookup on each certificate authentication to figure out the IP address.  This implies that you must either have this association in the certificate or setup in the DNS server.

As an example, if the incoming certificate had a CN=PanoramaEMS then the system would look to see if there was a Subject Alternative Name with an IP address and if it did not exist, it would do a lookup of PanoramaEMS in the current domain and resolve the IP address.   The IP address is then compared with the IP in the incoming message to ensure it's IP agrees and that it isn't being spoofed.

If DNS is not available and Subject Alternative Name is not present in the certificate, you can update the local hosts file on the windows PC which is found in c:WindowsSystem32driversetchosts on most machines and put in a host entry.  For example a line like this: 

PanoramaEMS     192.168.1.100

This prevents the lookup and speeds up the certificate handshakes or solve the lack of a DNS entry.