Create 3rd party Certificate for IP Office

First let me say that I am in no ways, a certificate or security guy.  Everything stated below is to the best of my abilities, and some info from some other very smart people.  If there is an error or wording/terminology is incorrect, please use the “Contact Us” and let us know your input.

For IP Office, with all the new applications and need for security, certificates are becoming more of a common place for IP Office programmers.  Every certificate provider will do things a bit differently, but the basics and flows are the same.

For a signing authority, you need:

• Certificate Signing Request (CSR) and Private Key used to create the CSR
• Verification of Domain Ownership

IP Office Linux servers and IP500 V2 do not support the manual generation of a Certificate Signing Request (CSR) where the private key is retained within the server. Either a web form based request or a third party tool to create a CSR can be used.

A note about Wildcard Certificates:

• A wildcard name field contains an asterisk in the name (e.g. ‘*.example.com’) and covers all sub-domains
• IP Office can support such fields in both Subject Name and SAN wildcard name fields, but carry additional security risks and are not recommended
• See IP Office Security Guidelines document for more details
• http://marketingtools.avaya.com/knowledgebase/businesspartner/ipoffice/mergedProjects/security/certificate_name_content.htm

With the default Certificate from the IP Office Self Generated, and not installing it in the Trusted Certificate Store we see this warning:

Here we see that the Certificate is valid but the CA is not trusted (Self Signed by the IP office)

Viewing the certificate from security manager shows the same:

So, to request the 3rd Party Certificate you need to create a CSR, most providers will have a list of instructions based on the tools you have available.

For this guide I will be using openssl on a Linux PC.  Have used this same process using Terminal on a MAC.

Information that will be needed when creating the CSR:

• Country: The two-letter International Organization for Standardization (ISO) format country code for where your organization is legally registered.
• State or Province: Name of the state or province where your organization is located. Do not abbreviate.
• City or Locality: Name of the city where your organization is registered/located. Do not abbreviate
• Organization Name: The legally-registered name for your business. If you are enrolling as an individual, enter the certificate requestor’s name.
• Organization Unit Name: If applicable, enter the DBA (doing business as) name.
• Common Name: The fully-qualified domain name, or URL.
• Also will need the WAN IP for the SAN (Subject Alternative Name)
  • A note about this.  What i found is that when setting TLS, occasionally the phones would not accept the certificate, and hence, not connect.  When you would change “SET TLSSRVRID” from 1 (default) to 0, then the phones would connect.  After talking around, there was an assumption that because you use the WAN IP for the phones, and the certificate is built for the FQDN the certificate would be invalid.  So, i have update the below to build a certificate where you can have the FQDN as well as the WAN IP.  when you build the san.cnf below, you can add in Subject Alternative name, for other hostnames as well as IP address.

Creating the CSR with 2048 bit RSA Private Key:

Use NANO or VIM to create a san.cnf file (help here)

Add the following to the san.cnf: (just add the WAN IP info for your IP, the rest can stay the same)

[ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
req_extensions     = req_ext
[ req_distinguished_name ]
countryName                 = Country Name (2 letter code)
stateOrProvinceName         = State or Province Name (full name)
localityName               = Locality Name (eg, city)
organizationName           = Organization Name (eg, company)
commonName                 = Common Name (e.g. server FQDN or YOUR name)
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
IP.1   = WAN IP HERE
IP.2   = WAN IP HERE
DNS.1   = bestflare.com
DNS.2   = usefulread.com

Save the file and execute the following command to create the CSR and KEY file:

• openssl req -out sslcert.csr -newkey rsa:2048 -nodes -keyout private.key -config san.cnf

You will be prompted to enter the:

• Country (US)
• State (Spelled out)
• City
• Organization Name (Company name or “support”)
• Common name (fqdn, ipo.avayaonex.com)

To see the contents of the CSR type : 

• cat sslcert.csr

Copy the contents of the CSR and either attach or paste it for the Certificate Provider.  When Pasting include everything from the Begin to the End Certificate Request line (as pictured below).

Now you would go to the company you plan on getting the certificate from..Comodo etc…

The Provider will require Domain Validation. The Provider I used for this setup used an email sent to the listed Admin contact under the Domain Registration information.

The provider will send you an email with the validation code.

Click on the link and confirm the validation code:

Log back into the providers site and download the new Certificate:

The Download contains the new Identity Certificate (crt),  and a ca-bundle which contains the Intermediate and the Root CA Certificates:

To create the P12 file type used by the IP Office, copy these two files into the folder where the CSR and the Private Key were created:

From that folder run the following Command.  You will be required to enter a password for this package, which you will need when setting the certificate in the IP Office.

• openssl pkcs12 -export -out ipo_avayaonex_com.p12 -inkey ipo.avayaonex.com.key -in ipo_avayaonex_com.crt -certfile ipo_avayaonex_com.ca-bundle
  • ipo_avayaonex_com.p12 is the File Package being created
  • ipo.avayaonex.com.key is the Private Key that was created with the CSR
  • ipo_avayaonex_com.crt is the Identity Certificate created by the 3rd Party Provider
  • ipo_avayaonex_com.ca-bundle is the Intermediate Certificates with the Root CA Certificate

Now we need to load that new p12 Certificate Package into the IP Office Certificate Manager and set it as the Active Certificate.  After applying this new Certificate, all web services on the IP Office will be restarted to start using the new Certificate.

Now all devices that connect will trust this Identity Certificate, since it’s chain can be traced all the way up to a Trusted 3rd Party Root Certificate Authority.

CHROME:

Internet Explorer:

Firefox:

To Check and see the dates on the active Certificates you can use the following search string from the CLI logged in as root user.

• find / -type f -name server.pem -exec ls -Ggl {} \;

The two VMware ones are defaults and you can ignore, but notice the date and time on all the rest are the same:

vmpro folder = Voicemail Pro Certificate, webcontrol folder = Platform View (port 7071), WebLM folder = WebLM (port 52233), oneXportal Folder = One X Portal (Port 9443), and the Avaya certs Folder = Web Manager (Port 7070)

The Certificates for Web Manager are created and stored in the /opt/Avaya/certs folder.  When these are created a hidden file call “.auto” is created and that tells the system to distribute the Certificates to all the Web Services on the IP Office.  From there you will see “.distrib_inprogress”

***If you see that the Certificates are not showing up on all the Web Services, (7070 / 7071 / 8443 / 8444 / 9443 etc…) then check to see that this file is there, and if not you can create it by logging into CLI on the IP Office with root user, navigate to that folder and type “touch .auto”  (SOLN287937)

For testing purposes you can load any Certificate Package (p12) file on an IP Office. 

The Certificate will be invalid as the name and URL do not match

• But this will allow you to validate the following:
  • The P12 file
  • The Password
  • The details of the Certificate by viewing the details panel when connecting with a Web Browser

If you are having issues, and you need to open a Service Request to Avaya, the inof you will need to submit are:

• Screenshots of the Certificate details from the browser you are using
• Screenshots and details of the errors you are seeing when setting this up
• And the System_logs*.tar.gz archive from the System