Download the PDF 

Securing OLAN with Certificates

Introduction 

Document Number

ENG-010593

Purpose

This document will describe the usage of certificates within the Tellabs OLAN OLT and Tellabs Panorama PON EMS.  

Applies To

• Panorama PON
• All Tellabs OLTs  

A Primer on Certificates 

PKI Certificates are used to secure nodes and limit access to resources to only trusted machines or individuals.   Certificates work via a policy of implicit trust.  It works based on the philosophy that if I trust a particular CA (Certificate Authority) then I trust all users/devices that present a certificate created by that Certificate Authority.  There are several key concepts that need to be defined.

PKI - Public Key Infrastructure.  PKI is a method where public keys and private keys can be created using software that implements PKI.  

Certificates - Certificates are created for a given public/private key pair.  Certificates give the identity of the party, the allowed operations the certificate is good for, and define a period of validity.  The certificate can be tested using the anchor certificate and mathematically verify that the certificate was created by the CA listed as it’s issuer.

Device Certificates - A certificate that is placed on a device and acts as its primary certificate and offers it to peers to validate its identity.  It also informs peers of what the certificate can be used for, who issued it and how long it is valid.  The public key contained in a device certificate can be used to encrypt messages that can only be decrypted by the private key that corresponds to the public key.

Trust Anchor Certificates - A public certificate given out by CAs (Certificate Authority) which states its identity.  It can be used to verify that a Device Certificate really was created by the CA whose name is contained in the Anchor Certificate.    I will "trust" any certificate that validates using a Trust Anchor in my list.

Public Keys - When a public/private key pair is created, the public key is given to peers freely as it contains no information that needs to be kept hidden.  The public key is used to encrypt data.  That data can only be decrypted by the paired private key.

Private Keys - These keys, which are part of a public/private key pair, can be used to decrypt messages encrypted with the public key.  

OLT and EMS Certificates

The OLT and EMS are secured by certificates that are placed on the device at create time.  Each OLT and EMS Instance has its own unique certificate. In the default state, the system will only allow management of equipment with a Tellabs stock certificate.    

The OLT and EMS can load new locally created certificates.  Once the certificates are loaded, the OLT can only be managed by an EMS with a validated certificate and vice versa.  It is recommended that any secure site always load certificates from the local certificate authority to ensure security of the management link.  Once the certificates are loaded, the OLT/EMS connection will only work if the peer certificate can be validated. 

Adding Device Certificates and Trust Anchor Certificates to the EMS

Tellabs provides a tool for managing EMS certificates.  This tool can be invoked from the server directory of the EMS (C:TellabsPanoramaPonbbmgrservercertificateMgr.bat).  This tool allows for importing and exporting certificates into the EMS.

Two types of EMS certificates can be managed: 

Trust Anchor Certificates - These are public certificates of the CA (certificate authority).  The system will trust any certificates that it receives that were created by certificate authorities in its trust anchor list.

Device Certificates - These are certificates that are presented by the ONT to the softswitches whenever they perform SIP registration.   

The certificateMgr application allows the user to:

• Load an EMS device certificate 
• Load trust anchors for the Peers (typically OLT, ONTs).   

There is a batch file in Windows and a script in Solaris named certificateMgr in the server directory that performs this function.

Figure 1 Windows Certificate Manager Location 

Figure 2 Solaris Certificate Manager  

The user will be required to log in as a user with the certificate administrator role prior to making changes.  The user must be created via the EMS User menus and have the certificate administrator role associated with it.

The user MUST perform a backup prior to modifying any certificates.  This is to ensure that you can return the system to a known state prior to the addition of certificates.  The Panorama PON Administration manual gives details on how to do this function.  You can initiate the backup using the backupems.bat file in the server directory.  You will be prevented from modifying certificates until this backup exists.

Adding EMS Trust Anchor(s)

The Trust Anchors for the EMS should first be updated using menu option 3 PON EMS device/anchor certificate menu from the main menu of certificateMgr.

Anchor certificates can be either appended to the existing trust anchor list or can replace the existing list.  A pem file is used to import the certificate(s).

Updating the EMS certificate will require shutting down the EMS server.  This is non-service affecting, but will prevent management of the OLTs via the EMS GUI for the duration of the certificate management activities.

After the certificate has been added, you will be prompted to restart the server. 

Adding EMS Device Certificate

The EMS should also be loaded with a device certificate that is created by one of the CAs in the trust anchor list.  Please note the OLTs will lose communication with the EMS until they are loaded with corresponding certificates created by a CA in the trust anchor list of the EMS.  This is non-service affecting but the OLTs will not be manageable by the EMS until the OLT certificates have been loaded.

The user will be prompted to restart the EMS Server. 

Adding OLT Certificates

This process only addresses certificates on the main controller card (ESU) of the OLT.  For ONT 729GP certificate management, since there are typically large numbers of them, this is managed in a different way and is documented in the following document: 

Configuring Softswitch Voice

You must log into the OLT with a user account that has the Security Admin role.  Certificates can only be managed by users with this role assigned.  

 When using the CLI to import the device certificate into the OLT, it must be in PEM format to be able to paste into the CLI terminal.  If your certificate file is in a p12 form, it can be converted using standard openSSL as follows (substituting your file names): 

The following command is used to add the device certificate to the OLT: 

      ne security key edit pem terminal

The device certificate import function requires that the pem file be password protected and will prompt for the file password.  The password can also be added to the command line using the passphrase keyword.  ONLY the PEM format can be used on the command line as PKCS12 is binary and cannot be pasted into the terminal screen.

Highlight the certificate and then paste it into the terminal then press <Ctrl-D> to tell the CLI that the import is complete.

The certificate, if valid, will be imported by the OLT and the result of the import is shown: 

The accompanying trust anchor(s) can be loaded in a similar fashion using the command: 

      ne security pki-ca-trustpoint edit certificate pem terminal

The trust anchors are all public certificates and do not need to be protected with a password.  They must be loaded to the terminal in pem format. The trust anchors are used to validate the certificates of devices attempting to attach to the OLT.  Specifically, this is the EMS CORBA interface used to configure the OLT and retrieve status.

The EMS and OLT should be now communicating using the newly installed certificates. 

Displaying OLT Certificates

With the software versions SR31.4_604076 and above, the OLT can display the certificates in several formats from the CLI.

The format of the command to display the OLT device certificate is as follows: 

The three formats are defined as follows: 

• raw: Shows the exact contents of the device certificate file in raw format.  This is sometimes useful for getting access to the public certificate of the OLT in its native format.
• summary: Will just display the subject line and issuer lines.  This gives the most important information in the certificate about who I am and who signed my certificate.
• verbose: Shows the entire certificate printed out in x509 format.

Show Raw example: 

An example of the summary format: 

To show the entire details of the certificate in x509: 

The OLT trust anchors can be displayed using the following command.  The options are similar to the device certificate commands in that it support raw, summary, and verbose options.

Mutual Authentication

Description of Mutual Authentication

The default behavior of most SSL (Secure Sockets Layer) implementation is to do Server certificate authentication.  The purpose of server certificate authentication is to verify the identity of the server and validate that the server has a certificate signed by someone that we trust.

With this default behavior, the client is not obligated to offer its certificate back to the server.  The server is validated by the client, but the server does not validate the identity of the client.

When Mutual authentication is enabled, the server will also authenticate the identity of the client.

The server sets a bit in the SSL handshake messages that tells the client that it wants to perform mutual authentication and that the client should send back it's certificate.  The client will send back its certificate and the server will validate the client's identity.  If either end detects that the certificate is invalid, it will close the connection.  

There are two EMS to OLT connections on which certificate exchange can occur.  

• EMS to OLT CORBA connection - Used for all configuration of the OLT and for retrieving all status.
• EMS Event Service connection - Used for autonomous reporting of any off-normal conditions via the event channel.

For the EMS to OLT Corba connection, the EMS will connect out to the OLT which makes the EMS the client (for SSL) and the OLT will be the server.  

Turning on mutual authentication will cause the OLT to also check the EMS certificate to ensure it is a valid EMS connection.  For this connection, mutual authentication is enabled on the OLT as it is the server role in this connection.

In the case of the Event Service, the OLT is the client and the EMS is the server.

For this connection, Mutual Authentication is enabled on the EMS as it performs the server role for the SSL connection.  

Configuring OLT Mutual Authentication

To configure the OLT to check the EMS certificate for the EMS server connection used for all configuration and status, Mutual Authentication needs to be enabled on the OLT.  For proper operation the OLT must be running OLT load SR31.4_78, or higher.  The minimum release for the EMS is SR31.4.0.Y or higher.  You must be logged into the CLI with a user that has the security admin role to be able to see or modify this attribute.

The current status of Mutual Authentication at the OLT can be determined using the show command.

Ensure before enabling Mutual Authentication that all certificates and trust anchors are installed on both the OLT and EMS.  Failure to do so will cause the OLT and EMS to lose all connectivity.  Mutual Authentication can be enabled with the following command.

Configuring EMS Mutual Authentication for the OLT Event Channel

Mutual Authentication is always on by default on the OLT Event Channel and no changes are necessary for this connection.

Configuring EMS Mutual Authentication of EMS Client Sessions

The EMS Server Application has the role of server in SSL connections with the Client GUI.  Mutual Authentication can be enabled on client sessions by making the following change to the file: 

C:TellabsPanoramaPONbbmgrserverdataAuthenticationControllerAuthenticationController.properties

The file should be edited to change the setting of ClientAuthentication=1

Turning on Secure Client during the installation of the server software will set this attribute to enable Mutual Authentication on the EMS server. When installing the Server software, select Custom Installation: 


 

Summary

Several points should be noted: 

• Ensure the user has all the needed certificates ready prior to adding the certificates to the EMS or OLT.  This minimizes the time when the OLT and EMS are out of communication.  This does NOT affect traffic running through the OLT, only management of the OLT during that period.
• Ensure the user destroys or secures the certificate files after loading them on the EMS and / or OLT.  The certificates are persistently stored on the OLT and EMS and are typically not needed after installation.  Certificates will cross-copy between ESUs and are stored persistently in the flash of both ESUs in a secure key store.  The EMS certificate is stored in the EMS backup.  
• Keep an eye on certificate validity dates as when the certificates expire, communications will fail.  Both the EMS and OLT will warn prior to certificate expiration and will alarm expired certificates.
• If the user does not have a certificate authority, EJBCA (Enterprise Java Beans Certificate Authority) is a good freeware opensource tool for generating certificates.