So you’ve got a spiffy Cisco Unified Communications Manager (CUCM), formerly Cisco Call Manager, install for your company’s phone service?  Maybe you have their Cisco Unified Contact Center Express (UCCX) installed too for your help desk?

Well, out of the box, they have the incredibly stupid expectation that you’ll download the self-signed SSL certs off of the thing and push them out to all of your users’ desktops in a way that will work.  So that means importing them into the certificate repository of Windows for the IE users, doing the Firefox “accept this SSL” trick for that browser, ignoring the error with Chrome each time and who knows how you deal with it on Safari or others.  Umm yeah, I just spent a minimum of tens of thousands of dollars on my CUCM install but I want to run cheap self signed SSL certs for my users to interact with the system.

Certs cost $8/year these days, there is simply no reason to not use trusted certs.  Save yourself all of the above hassle by spending $16 and ten minutes of your time.  Of course this assumes you installed your CUCM / UCCX servers with real fully qualified domain names; otherwise, the SSL providers won’t be able to sell you a cert anyway.

So lets begin the adventure of how to actually install third party trusted SSL certificates into a Call Manager / Cisco Unified Communications Manager (CUCM) and Contact Center (UCCX) installation.  This is specific to version 10.0.1; the steps range from different to dramatically different for older versions.  10.5 is nearly the same.

There are two prerequisites to this:

1. If you’re running high availability, only do the install when all nodes are online.
2. All of your CUCM / UCCX servers should already be configured to use real host and domain names, not ActiveDirectory-style stupid names like CUCM.corp.local or just one-word names like Chewbacca.

Okay, so we’ll start with the CUCM side of things.  CUCM is nice because if you visit https://<Your CUCM Server>/ it gives you a little menu with links to the /ccmadmin interface.  Don’t log in yet.  In the drop down box to the upper right, select Cisco Unified OS Administration and click Go:

That will take you to https://<Your CUCM Server>/cmplatform/.  Go ahead and log in using your admin credentials.

Click the Security menu and then Certificate Management:

The following screen should default to listing your certificates, but it doesn’t, because that would make sense.  So click Find on a search for nothing and then the screen will populate with certificates.  Click the one labeled simply “tomcat” in the Certificate Name column.  Do NOT click the ones labeled tomcat-trust.  There will only be one “tomcat”.

On the next screen, click “Generate CSR”.  Once you do that, it will give you a screen for generation and I recommend you choose a 2048-bit cert and SHA256 instead of SHA1.  Most likely your SSL certificate provider will stupidly still give you a SHA1 certificate even though your CSR will be SHA2, that’s what happened to me with GeoTrust RapidSSL, but maybe your certificate authority will be better.  The reason this is important is because some browsers will ultimately be stopping support for SHA1, such as Google Chrome in 2015.  Once you’ve generated your CSR, you’ll see a new link that will offer to let you “Download CSR”.  Go ahead and do that.

Take your CSR to the certificate authority of your choice and have them issue you a public trusted certificate.  When they do, 99% of the time they’re going to issue you your certificate but also provide you with between one and three intermediate certificates that have to accompany your SSL cert on the server.  Save all the files individually in plain text files with .cer extensions(!).  I have heard using an extension other than .cer, such as .pem, will cause you problems.  I haven’t tried it, I just saw the advice, took it, and it worked.  Anyway, if your provider gives you the intermediate CA certificate as two certs in one file, split them into two files.  In versions of Call Manager / CUCM prior to 10.0, my understanding is that was not possible to have more than one intermediate CA certificate, which is nearly impossible to find these days, so if you’re trying to do this on 9.5 or older, the steps will not work, but they’d be wrong regardless so probably not a big deal.

Go back to the Certificate Management interface and click on the “Upload Certificate / Certificate Chain”.  You’ll want to deal with the CA certs first.  A very huge and nice change in CUCM 10.0 is that you no longer have to get all fancy with the order you load intermediate certificates.  In the older versions you had to choose your file names carefully, load them in the right order, then manually type in the name of the cert that signed the one you were installing if it was an root to intermediate or intermediate to end user.  Huge pain in the ass that has been resolved.  In CUCM 10, just load your CA’s in whatever order you feel like and the name doesn’t matter.

To do this, in the window that pops up after you clicked Upload Certificate, first, choose “tomcat-trust” from the drop down.  This lets it know you’re loading certificate chains.  Select and find your file.  Give it a useful name, such as “GeoTrust RapidSSL CA 1” in my case:

Repeat that same step for CA cert #2.  Repeat that same step again for your actual trusted certificate issued to your site, but choose “tomcat” instead of “tomcat-trust”.

Once these certs are all loaded, your certificate manager cert list should look something like this where now your tomcat cert has a description of your certificate issuer and your intermediates are present (listing sanitized a bit):

Now with your certs updated, all you need to do on your CUCM server is restart the Apache Tomcat software.  You of course don’t want to do this during production hours.  To do this, log into your CUCM server via CLI/console, or SSH into it.  Issue the command “utils service restart Cisco Tomcat” and then wait about three to seven minutes while the following cycles:

 

Once that completes, your CUCM web interface should now be protected by a trusted SSL certificate and your days of clicking past the accept this certificate error will be in the past.

If you use Cisco contact center express (UCCX), the steps are nearly identical for the core administration piece but not the Cisco Finesse web interface for your call center / helpdesk agents.  To get the first part done, you’ll need to hit https://<Your UCCX Server>/cmplatform in your browser to get to the Unified OS Administration interface.  Log in, and go to certificate manager.  The UCCX server certificate is also called “tomcat” and just as before for CUCM, you need to generate a new CSR under it, download, have it signed, cert issued, upload your CA certificates using the “tomcat-trust” object, then upload your cert itself, and finally, restart the Cisco Tomcat service just like with CUCM.

Okay, so that’s done, but you use Cisco Finesse and when you hit https://<Your UCCX Server>:8445/desktop/ you still get the same old lame self-signed certificate.  Thanks Cisco, please just waste even more of my time on what should be a simple task.

Still have that CLI/console or SSH session open?  Well you’re going to need it back if you let it close.  Log back in, and run:  utils service restart Cisco Unified CCX Notification Service

Well that’s what Cisco tells you to do at least, only my Finesse install came right back up with the same self-signed certificate.  “utils service list” gives me some more things to try restarting, let’s go for “Cisco Finesse Tomcat” since that seems logical:

Success!  Maybe not….  Hitting my Finesse URL of https://<Your UCCX Server>:8445/ now gives the proper trusted SSL certificate, but it also gives me a blank page; that’s not good. :-(  Maybe all this messing around got things restarted out of order.  Let’s just restart that notification service once more:

Hey, we have it, everything is now working and we have a trusted cert so no more bullshit errors!  Well almost none.  If you’re running high availability with a second UCCX server, your second server is still called as part of the Finesse interface, so you’ll log in and the Finesse desktop will start, but you’ll still get two errors from that server:

You’re going to need to log into your second UCCX server at https://<Second UCCX Server>/cmplatform/ and go through the same steps with the tomcat-trust, tomcat certs, restart Cisco Finesse Tomcat, Cisco Tomcat and Cisco CCX Notification Service.

Now, even after all that, still two more errors remaining, in the Finesse interface:

 

I restarted several more services on the UCCX server and I simply could not find the one responsible for service on port 8444; it continued to serve the old self-signed certificate.  I ended up restarting the server, and the secondary server, and that resolved it.  If anyone happens to know which service is handling port 8444 requests, please let me know and I’ll update this article.

Good luck!  And Cisco, thanks for wasting four hours of my time to figure all this out just to upload an SSL certificate.