With the drive of unified communications to cloud based connectivity, a Session Border Controller (SBC) can play an important part in supporting a migration from premise equipment.  Some gateway manufactures provide a convenient Graphical User Interface (GUI), others still focus on leveraging a command line interface (CLI).  This overview will step through the generation and signing of the certificates that would be used for Tranport Layer Security (TLS) for both signaling and media within a Cisco Unified Border Element (CUBE).

Edited note from original post: this document was restored without images. The code displayed at the end of the post covers the discussed items.

Generation of Certificates

With the SBC configured and accessible on the network, the certificates are ready to be generated.

First step is generate a key. This is used to sign the certificate request and validate the signed certificate.  In the example, the tag “exportable” is added to the end so the keys can be moved to other devices.  This can be beneficial is a certificate with Subject Alternate Names (SAN) is used.

Key Generation (Exportable)

The next step is to identify the device to as a trustpoint.

Device Trustpoint

Next is to generate the Certificate Signing Request (CSR) that will be sent to the Certificate Authority (CA).

With the text copied/saved into a CSR file, it is ready to be uploaded to the CA (or pasted in a webpage).

Submitting to GoDaddy for signing.  For this example, sbc1.destephen is being rekeyed with sbc3.destephen.com as a SAN.  If this is a first-time certificate generation, the steps within the CA would be slightly different, however the concept remains: the CA needs few pieces of information.

GoDaddy Re-Keying to SBC3 CSR

With the certificate generated and downloaded from the CA, we are able to verify sbc3.destephen.com is a SAN.

Certificate Overview

The full script used for the generation of the certificates is below.

crypto key generate rsa modulus 4096 label SBC3.destephen.com exportable

crypto pki trustpoint SBC3.destephen.com
 enrollment terminal pem
 serial-number none
 fqdn none
 ip-address none
 subject-name cn=SBC3,dc=destephen.com,ou=Lab,O=DeStephen Systems,l=Hilliard,st=OHIO,c=US
 revocation-check none
 rsakeypair SBC3.destephen.com
 enrollment terminal pem

crypto pki enroll SBC3.destephen.com

Uploading of Certificates

In this phase, the SBC will need to first have the certificates of the CA.  The observed best success of creating chains has to been to link individual certificates within the router, avoiding the upload of the bundle certificate.

First will be the GoDaddy Root Certificate upload.

GoDaddy Root CA Import

Next will be the intermediate certificate. The difference in the trust point is the linking of the root and intermediate certificate. This is required to have a valid hierarchy.  Upon acceptance of the certificate, it is also noted that that the intermediate was signed by the existing trustpoint.

GoDaddy Intermediate CA Import

Now the two GoDaddy trustpoints are installed and linked, the router is ready to have the signed certificate uploaded.  The first step is to authenticate the CA that signed the certificate against a valid trust point.  In this step, the intermediate certificate is used.

Validating the CA used for Signing

The SBC is now ready for the signed certificate to be imported.

Signed Certificate

As an optional step, if there are internal CA’s that the SBC should trust, they can be added in the same manner that the GoDaddy CA’s were added.  In this environments case, there is a single CA that needs loaded as it has signed the certificates within the premise based CUCM servers.  Installing this certificate will enable the traffic to be decrypted from CUCM and the internal CA signed certificate and then encrypted with the GoDaddy certificate.  Also keep in mind the addition of the public CA certificates into the internal connection (CUCM in this case) to be able to decrypt the SBC traffic.

Creating and importing the destephen.local trustpoint.

Internal CA Trustpoint

The full script used for the upload of the certificates is below.

crypto pki trustpoint Godaddy_Root_G2_CA
 enrollment terminal
 revocation-check none

crypto pki authenticate Godaddy_Root_G2_CA

crypto pki trustpoint Godaddy_Secure_G2_CA
 enrollment terminal
 chain-validation continue Godaddy_Root_G2_CA
 revocation-check none

crypto pki authenticate Godaddy_Secure_G2_CA

crypto pki authenticate SBC3.destephen.com 

crypto pki import SBC3.destephen.com certificate

crypto pki trustpoint dc0.destephen.local_CA
 enrollment terminal
 revocation-check none

crypto pki authenticate dc0.destephen.local_CA