Download the PDF  

Building Site Specific Certificates

Introduction 

Purpose 

This document will define the steps and procedures to build a full certificate architecture with a root Certificate Authority (CA), subordinate CAs and create all the end device certificates. It will attempt to explain what is going on in the steps. This will create certificates that mimic the structure used by some of Tellabs biggest customers. 

Applies To 

This document applies to the OLAN product lines. 

Document Number

ENG-010704

Document Revisions

Definitions 

This section defines the terminology. 

Certificate – A file containing a public key, and information about how it can be used.  It sets limits on what the cert is used for. 

Device Certificate – This certificate asserts MY identity. I send it to others to validate MY identity to OTHER devices.  It is like showing the guard at a guard shack my ID. 

Anchor Certs – Anchor Certs or Trust anchors inform ME of whether I trust connections from OTHER devices.  If there is NOT a match in the trust anchors, I will typically refuse to connect.   This is like the list of allowed “groups” of people kept at the guard shack I should let in.  I trust you because the Certificate Authorities (CAs) I trust signed your certificate. 

Private Key – The protected secret key used for decrypting data.  It is also used for signing.  This key must be kept secret and protected from disclosure.

Public Key – The public key which is shared with others.  Used for encrypting data and validating signed artifacts.  This key can be widely shared and is needed by peers to enable encryption.

CSR – A Certificate Signing Request.  It requests a CA to sign a certificate allowing others that trust that CA to trust me.  The CSR contains only public information asserting my identity, but until signed, it is not trusted. 

Tools

Openssl tool 

Openssl is a requirement to be installed on your machine.  It is supported on both Linux and Windows operating systems. 

Openssl cnf 

The openssl.cnf is a configuration for the openssl tool that defines all the settings for the certs that will be generated. It is a requirement that you use the file linked below to make things work correctly or one that is equivalent. Put this file in the working directory where you are doing the cert creation. 

genrsa vs genpkey

There are two ways to create RSA keys, albeit in different formats. genrsa outputs an RSA key in PKCS#1 format while genpkey outputs a more generic container which can manage different kinds of RSA keys in PKCS#8 format (like ECC).  

Root CA Creation 

The Root CA is the root of all certificates generated in this exercise. Using the openssl tool the user will input the following commands to generate the required certificates. You will have the choice to generate a Root CA in one of two formats, genrsa or genpkey.

Create CA Private Key in genrsa Format

Step 1 is to create the private key. This example has creates a 2048-bit key. 

The command below uses the OpenSSL tool to generate a 2048-bit RSA private key with sha256 encryption and save it to a file named “rootCAT3.key.” 

C:\PrivateKeys\Site-issue\catest>Create the CA Private key

openssl genrsa -aes256 -out rootCAT3.key 2048

Command elements:

• openssl – This is the command-line tool for using the OpenSSL library, which provides cryptographic functions and utilities.
• -genrsa – This command is used to generate an RSA private key.
• -aes256 – This option specifies that the private key should be encrypted. AES-256 is a symmetric encryption algorithm, meaning it uses the same key for both encryption and decryption.
• -out – This part of the command specifies the output file name for the generated private key. In this case, the private key will be saved in a file named “rootCAT3.key.”
  • 2048 – This parameter specifies the key length, and in this case, it is set to 2048 bits. The key length determines the security level of the RSA key. A longer key is generally more secure but requires more computational resources and must be balanced against compatibility with older installations which may not support larger key sizes.

Create CA Certificate  

The openssl req command is used for managing X.509 Certificate Signing Requests (CSRs). It enables users to create new CSRs from scratch, which are essential when requesting digital certificates from a Certificate Authority (CA). During the CSR generation process, openssl req can also generate a new private key (e.g., RSA, EC) that will correspond to the public key embedded in the CSR. 

Step 2 is to create the public certificate to accompany that key: This example has a 10-year lifetime.

openssl req -x509 -new -nodes -key rootCAT3.key -sha256 -days 3650 -config openssl.cnf -out CAT3.pem

Command elements

• openssl – This is the command-line tool for using the OpenSSL library, which provides cryptographic functions and utilities.
• -req – manages X.509 Certificate Signing Requests (CSRs)
• -new – Creates a new Certificate Signing Request (CSR).
• -x509 – Outputs a self-signed certificate instead of a CSR. Requires the -days option.
• -nodes – Do not encrypt the private key. This is useful for automated server startup but reduces security if the key is compromised.
• -key – Specifies the input file to use for the private key. (e.g., rootCAT3.key)
• -sha256 – Specifies the message digest algorithm to be used for signing the request (e.g., SHA256).
• -days – Sets the validity period in days for a self-signed certificate when used with -x509. (e.g., 3650 10 Yrs))
• -config – Specifies an alternative OpenSSL configuration file instead of the default (openssl.cnf).
• -out – Specifies the output file for the CSR or self-signed certificate. (e.g., CAT3.pem)
• -extensions – Specifies the configuration file section containing X.509 extensions for the CSR or certificate (e.g., v3_req).
• -CAcreateserial – Assigns the serial number to the signed certificate, and if no serial number exists then creates a serial number file with the next serial number (01) in it.

This should result in:  

• Private Key – rootCAT3.key  
• Certificate – CAT3.pem 

If you are just trying to do local certs, this is the only CA you need. 

Create A Subordinate CA 

If you are trying to duplicate the common “tiered” CA paths, then you’d need to know how to create a Subordinate CA. This is common. The Root typically has a long lifetime, but subordinate CAs have shorter lifetimes to ensure if a compromise occurs, it is bounded in nature and will eventually expire and lose access. 

There are three steps to creating subordinate CAs:  

• Private Key – Create the subordinate CA private key 

• Create CSR – Create the subordinate CSR or certificate signing request. 

• Create Cert – Create the subordinate CA certificate using the CSR and root CA. 

A subordinate CA that has signing rights can be created as follows. 

Create Sub CA Private Key 

Create the private key and set the key password:  

C:\PrivateKeys\Site-issue\catest>

openssl genrsa -aes256 -out CAT60.key 2048

Enter PEM pass phrase: 

Verifying - Enter PEM pass phrase: <password>

Sub CA CSR Creation 

The CSR is given to the person who administers the CA or, in some cases, there is a web interface or an email interface for getting the certificates signed. 

C:\PrivateKeys\Site-issue\catest>Create the CSR or Certificate signing request. 

openssl req -new -key CAT60.key -out CAT60.csr -config openssl.cnf 

Signing of Sub CA Certificate (by the root CA) 

Certificate from the CSR using the root ca key and cert to create the cat60 cert.  Please note the cert below is given a 10-DAY LIFETIME.  Set it appropriately for your application.  This is a good test scenario. 

C:\PrivateKeys\Site-issue\catest>

openssl x509 -req -in CAT60.csr -CA CAT3.pem -CAkey rootCAT3.key -CAcreateserial -out CAT60.pem 
-days 10 -sha256 -extfile openssl.cnf -extensions v3_ca 
Certificate request self-signature ok 
subject=C=US, ST=Texas, L=Carrolton, O=Tellabs, CN=Tellabs Root CA 60 

Enter pass phrase for rootCAT3.key: 

C:\PrivateKeys\Site-issue\catest> You need the pass phrase for the CA key. 

Enter PEM pass phrase: 

Verifying - Enter PEM pass phrase: <password>

Please note that for testing purposes, this cert has a 10-day lifetime to allow for testing of expired and expiring certs. 

Creating the ONT or OLT Device Cert 

Create Private Key 

First generate the private key, this example is for an ONT729GP Voice certificate:  

openssl genrsa -out 729-PON2-ONT13.key 2048 

Create CSR 

All Certs used with Tellabs equipment MUST have one of the following:  

• CN=<ip address>          Common Name = IP, CN=192.168.1.44 OR

• CN=hostname                AND DNS has an entry that will resolve to ONT/OLT/EMS IP and
  the SAN Subject Alternate Name has the IP. 

IMPORTANT CHANGE THE IP IN THE CONFIG FILE openssl.cnf NOW!!! Otherwise, a cert will be refused. 

Then generate the CSR:  

openssl req -new -key 729-PON2 -ONT13.key -out 729 -PON2 -ONT13.csr 
-subj "/C=US/ST=Texas/L=Carrolton/O=Tellabs/OU=OLAN/CN=729GP-PON2-ONT13" 

Sign Device Certificate 

Next, sign the certificate using the intermediate CA:  

openssl x509 -req -in 729-PON2-ONT13.csr -CA CAT60.pem -CAkey CAT60.key -CAcreateserial 
-out 729-PON-ONT13.pem -days 730 -sha256 -extfile openssl.cnf -extensions v3_device

• openssl – Utilizes the openssl tool
• x509 – Use the x509 certificate tool
• -req – CSR
• -in – input filename containing the CSR
• -CA – The CA certificate to use to sign the cert.
• -CAkey – The CA private key that matches the CA public certificate used to sign this cert.
• -CAcreateserial – Assign a serial number using the serial number file.
• -out – Specifies the signed certificate output file name.
• -days – Number of days that the certificate is valid for, shorter lifetimes are better but have to be balanced against the operational difficulties of updating the certs.
• -sha256 – The hash used for signing.
• -extfile – The configuration file to use to guide the signing action.
• -extensions – The extensions section to use when performing the signing action.

Create P12 File (729GP Only) 

For the 729GP, since the files can sit on disk, UCR requires them to be in p12 format to protect them at rest. 

The EMS, and ESU require the file to be in unencrypted format for import. They are encrypted once they are accepted by the EMS/ESU. 

To create a p12 file from the artifacts above, use the following command:  

Openssl pkcs12 -export -out filename.p12 -inkey mykeyname.key -in mycertname.pem 

Security for Certs 

There are different levels of security required for different parts of PKI infrastructure. 

Certificates are public documents. They are offered on all TLS connections. In general, they should be protected, but they are expected to be public. Up until TLS1.2, they are sent cleartext on the wire. 

Private keys are used for decoding data and signing artifacts.  As such, they require more protection.  On disk, they should be root only access and password protected.  By default, the commands above will require passwords to be entered on Private Key creation.  Do not bypass or turn off this protection. This protects the keys at rest.  Obviously, protect the password as well.  If a private key is compromised, you can decrypt messages intended for the owner of the key, and you can forge signatures on files or messages whenever this is allowed by the signed certificate. CA private keys are especially important to protect as you can forge certificates and allow the creation of forged trust relationships.