CUCM Migration to UCS with security Etoken and self signed certs

[Allan Wells]

Hi

We have a situation wherby we need to migrate a client from exsiting MCS CUCM 8.0.3 latest version  to  new UCS B & C class same 8.0.3 version IP's and hostnames.

no IP addresses will change.

The client has requested a staged migration wherby we

1. Insert the new publisher and one subscriber into the existing cluster in week one.
2. Week 2-->  replace another subscriber
3. Week Three do step two again

Security component

My understadning is the the client self signed certificates from their CA that are there today for Tomcat and Phones etc  will be migrated with a DRS restore. Also the etoken will need to be run when with CTL client  every time we add the new UCS server  into the network.

Would like to hear from other who have completed a simmilar migration or have knowledge of any potential gotchas / any issues with security we need to be mindful of when doing DRS backup/restores - implications -

For restoring subscribers is it ths same as normal subscriber build -->. But then at the end run restore wizzard. Historiacally I have just built new sub and let it sync with pub.

The reason here for DRS on subs as well - I belive We need to do this as we want to reatin the security infromation from previous subscriber. this is correct.?

Would love a reposes on any parts of this.

thanks

[Jonathan Schulenberg · Accepted solution]

All the eToken does is digitally sign the CTL file once built. The CTL file is just a list of public keys from trusted servers for the phones. As long as all of the certificates are properly restored by DRS I fail to see why you would need to re-sign the CTL. Have you read documentation stating this step is needed?

For restoring subscribers is it ths same as normal subscriber build -->. But then at the end run restore wizzard. Historiacally I have just built new sub and let it sync with pub.
The reason here for DRS on subs as well - I belive We need to do this as we want to reatin the security infromation from previous subscriber. this is correct.?

Yes you need to DRS restore the subscribers. It's worth noting that you should always DRS restore the subscribers. If you don't the end result is adding new nodes to the cluster. The existing nodes are *never* deleted from the cluster database/configuration. You just end up creating a mess under the hood.

Please remember to rate helpful responses and identify helpful or correct answers.

[Allan Wells]

Thanks Jonathan,

I will rate the post 5 no issues there just wanted to clarify and get second thoughts here.

With regards to the subscribers - I dont understand what your saying.

During install --> If  I just say no this is not the first node and point to publisher, the new sub automatically pulls the information from pub -- Noting: the pub has the subscriners node in its DB the IP are setup in Publisher as per standard procedure.

Where as in this instance - we are doing the same thing during the install of the Sub - but now when its built we login to this sub (I assume it has synced all data with PUB as it normally would)  and we  do a DRS backup  on this Sub --. the reason we do this  only because there is certificate infromation stored there that DRS backed up for TFTP etc.

Otherwise I see no point in DRS backup for sub if publisher is accurate - just rebuild sub use same name or IP - data from pub is replicated yeah - why would we do DRS?

According to Cisco if we replace a server we have to run CTL again Your thoughts

Security         

Replacing a Single Server or Cluster for Cisco Unified Communications Manager Release 8.0(1)

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/install/8_0_1/cluster/clstr801.html

Caution You must create and distribute a new CTL file, or your secure phones will not work because they cannot register with the replaced Cisco Unified Communications Manager server(s).

[Jonathan Schulenberg · Accepted solution]

Ah I see the confusion. Simply installing the software, giving it the passphrase of the cluster, and the same IP/hostname does not redeem it as the same node. Until you do the DRS restore CUCM thinks you're adding a new node to the cluster. If you were to look in the database without doing a DRS restore you would see two CTI node IDs and a series of references to a new node in RIS and other services. So, DRS restore is always a good idea. Another hint that it is worth doing is that nowhere in the DRS guide does is suggest you can get by with just reusing the hostname/IP. The proceedure for replacing a subscriber explicitly says to do a DRS restore.

As far as that [interesting] document reference: That would imply that DRS does not restore the private key of the cucm-tftp certificate. This would make recovering from an actual disaster a real pain. I find this somewhat unlikely and it may be worth opening TAC case to get confirmation that is really true. I am suspicious of this because of defect CSCtn50405. It was identified in 8.5 which essentially failed to backup one of the certificates. This caused ITL to blow up and would be the same root cause for that Caution statement you found. It's possible this documentation was written based on observing the defect but not recognizing it as such. Worst case you can run the CTL client to upload the new cucm-tftp certs but I would be quite surprised if this is really the intended process.

PS- The line about rating is just an auto-added signature. It's a gental reminder for those not as courtious as you are.

Please remember to rate helpful responses and identify helpful or correct answers.

[Allan Wells]

Jonathan,

Excellent thanks !!!

Mate your going out of your way and providing excellent information that is very helpful!  5 ***** is the least I can do.

Your stopping my brain hurting so much lol

Got one more for you.

With regards to Certs Im trying to get my head around them. below is a fresh build of 8.0.3 has 17 certs

Out of all the below if client wanted to use 3rd party signed with thier own CA, which out of below certificates would we sign (considering they want all self signed where possible tomcat/ipsec ets). And then would we need to create the self signed  for all nodes and upload to each sub individually?

Also put couple questions is the screen capture.

[Jonathan Schulenberg · Accepted solution]

The key is the -trust. Those lines without it are actual certificates installed on that cluster node. Tomcat is the one used by the web interface for example. The lines that include -trust in the store name are what that server will trust when being presented with a certificate.

Example:

New phone boots, receives it's DHCP option 150, and says hello to the TFTP server. The config file says this phone should perform a CAPF enrollment. The phone will have a Manufacturer Installed Certificate (MIC) burned in from Cisco. When the phone requests a certificate from CAPF (i.e. enrollment) it presents its MIC. The capf-trust store lists the CAs for which the CAPF service should trust to create a secure channel for private key exchange. If the CA of the MIC is not present TLS negotiation will fail, thus preventing a man in the middle attack. Taking this one step further: let's say you follow the Security Guide recommendation and remove the MIC CAs from the CallManager-trust store. If you do this the phone cannot use it's MIC alone to register to CUCM. Since the certificate was in capf-trust it could get a LSC but since it isn't in CallManager-trust it can't register unless it successfully got it's LSC. The Security Guide explains all of this in more detail.

As for what to sign by your CA: Tomcat will get rid of the security warning in the browser. If you sign the CAPF certificate - note that it requires subordinate CA privs - then 802.1X gets easier since the LSC becomes signed by your root CA via CAPF subordinate. Whether you choose to sign other services is more of a policy discussion than anything. I suggest reading through the Security Guide if you're going to keep a mixed mode cluster; it's not something to take lightly.

PS- Don't forget that LSCs do not auto-renew or give you warning that they are about to expire. Your have to know and issue the renewal per-phone or through a BAT job. Mixed mode clusters are high maintenance.

Please remember to rate helpful responses and identify helpful or correct answers.

[Allan Wells]

Thanks Jonathan,

The cluster being migrated upgraded  is already a mixed mode "it's not something to take lightly" hence all the questions.

Working out best way to migrate it. You have provided good insight.

Thanks Again!