Thanks for the reply, we tried what you described above.  The current certificate is still valid and signed by our local CA.  We want to replace it with a cert signed by a third party CA, like GoDaddy.  We did that, tried to upload the cert and just got Tomcat errors.  TAC described a couple different ways of replacing the cert (both of which you touched on).  One of the errors we saw suggested that the csr for the cert had to be present in the cert store.  In our case, the csr had been deleted inadvertently.  My theory is that we need to create a new csr, have the third party CA reissue the certs based on the new csr, then try again with the csr still in the cert store.  I guess why I haven't tried that is because TAC told me that we needed to present a 'self-signed' cert to GoDaddy instead.  That means we need to remove the current Tomcat cert (issued by our local CA), regenerate a self-signed cert, present to Godaddy and have them sign - all within a maintenance window so we don't create havoc for our call center users. 

Just trying to confirm what the correct and best practice way is to replace a current and valid Tomcat cert signed by your local CA with a new cert signed by a well known third part CA that every browser in the world trusts.

Sorry for delay. Yes, you're correct... you need to generate a new Certificate Signing Request (CSR). When you generate the CSR, you determine the type of cert (i.e. Tomcat, CUP-XMPP, CUP-XMPP-S2S, etc.). The other fields within the CSR should be auto-populated; Distribution, Common Name, SAN, etc. Ideally, you want to reference the server's FQDN as the Distribution and CN. If not, Cisco docs claim this would cause problems; meaning, the cert wouldn't be recognized by others simply because the server's hostname or FQDN, doesn't match the CN within the actual cert. If you want, you can always regenerate these certs and specify additional SANs (i.e. Alternate Names) for these certs.

Once you generate a new CSR, which is based on the certs self-signed public key... you would then download the CSR, and submit this CSR to GoDaddy. They would sign the CSR and send this back to you as a CA-signed cert. Just make sure the cert was "Issued By" the GoDaddy CA server. The "Issued To" should display the FQDN of your IM&P server.

Next, you would upload the CA-signed Tomcat cert to the IM&P server as a Tomcat-Trust cert. If you already have a self-signed Tomcat-Trust cert for this server, then uploading the CA-signed Tomcat-Trust cert would replace this cert. You need to restart Cisco Tomcat and wait 10-15 minutes. The CA-signed Tomcat cert should automatically replicate throughout the cluster.

If you configured Inter-cluster Peers, then verify the status of these peers. The "Certificate Status" under each Inter-cluster Peer should display a lock icon (Connection is Secure). If the lock icon is -unlocked- then you can click on the [Details] tab to determine which cert is invalid. Just keep in mind, once you replace the self-signed certs with the CA-signed certs... any existing self-signed certs used by the users, which is stored within the Certificate Manager (i.e. certmgr.msc) wouldn't be valid anymore.

If you do everything correct, users wouldn't need to accept the new CA-signed Tomcat cert because hopefully, you already have the GoDaddy CA cert uploaded to the certificate store (i.e. certmgr.msc) and uploaded to the UC servers.

Hopefully this helps.

Here you go.

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/im_presence/configAdminGuide/9_0/CUP0_BK_CFF5B189_00_config-admin-guide-imp-90/CUP0_BK_CFF5B189_00_config-admin-guide-imp-90_chapter_01010.html

Sorry, I meant to say CUCM and UCCX, not IM&P... but the same concept applies to all of the UC servers.

Thanks Mark.  What you described above is pretty much what we did except that the CSR we created was deleted BEFORE we tried to upload the Tomcat cert.  One of the errors we got referenced the fact that the CSR had to be present in the certificate store.  We got other errors as well though so I wanted to confirm that the CSR used to request the CA signed cert did still have to present in the cert store before trying this again. 

If you regenerated the self-signed certs AFTER you generated the CSR, then you need to regenerate the CSR. After you generate the CSR, the "Download CSR" icon should appear. From there, you can download the generated CSR for Tomcat and submit this CSR to the GoDaddy CA for approval. Once you obtained the CA-signed Tomcat cert, you should upload this cert back to UCCX as a Tomcat cert... not Tomcat-Trust as I previously mentioned. Please check out this Cisco doc for additional info;

http://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/118855-configure-uccx-00.html

However, you still need to consider the following;

Are agents/supervisors using a supported browser? Please check out this Cisco doc for additional info;

http://docwiki.cisco.com/wiki/Compatibility_Matrix_for_Unified_CCX

You can leave the CSR on the server but honestly, it doesn't matter if you deleted the CSR. You just need to make sure you regenerate the Tomcat certs or CSR if you modify the system. Any changes to the domain, hostname (FQDN), etc. causes the cert to become invalid.

In addition to this, make sure agents web into Cisco Finesse via FQDN, for example;

http://uccxserver.test.com:8445/desktop 

If they attempt to web into Cisco Finesse using the following url formats;

http://uccxserver:8445/desktop   or   http://192.168.x.x:8445/desktop

It won't work because the UCCX Hostname (uccxserver) or IP Address (192.168.x.x) isn't referenced within the Tomcat cert by default and thus, agents/supervisors would continue to receive certificate errors.

Hopefully this helps.