Replacing certificates signed by an internal CA on CUCM 11.5

[James Hawkins]

Hello,

Last year I deployed a CUCM 11.5 cluster for a customer and used certificates signed by their internal certificate authority (Microsoft) for Tomcat and CallManager. These certificates will expire in approximately one month and so need to be replaced. I need to understand the process to do this safely without causing ITL issues for IP phones.

I have found a Cisco document that covers this process for self-signed certificates but it seems to have some gaps for my requirement.

https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/200199-CUCM-Certificate-Regeneration-Renewal-Pr.html#anc8

The document has a section which discusses how to avoid these issues 

Regenerate Certificates in Specific Order

This procedure provides a TFTP server with a valid/updated ITL file from a trusted TFTP server that is available.

1. Stop TFTP service on the Primary TFTP server.
2. Make changes on the Primary TFTP server's certificates (as needed).
3. Reset the phones (in order to get a new ITL file from the Secondary TFTP server) - dependent upon which certificates are regenerated, this might happen automatically.
4. Once phones have returned, start the Primary TFTP server's TFTP service.
5. Make certificate changes on the Secondary TFTP server.
6. Reset the phones (in order to get a new ITL file from the Primary TFTP server).

Caution: Do NOT edit certificates on both TFTP servers at the same time. This gives the phones no TFTP server to trust and requires the local administrator to manually remove the ITL from all phones.

 I guess this process should work for certs signed by a CA but for this cluster I have used a multi-SAN certificate rather than one per server. I am therefore not sure that this process would work as the multi-SAN cert would be copied to the secondary TFTP as soon as it is loaded on the primary server.

Has anyone done this successfully for this type of environment? - there are 3000+ phones connected to this custer so avoiding ITL issues is critical

[hellohova]

---

i have not @Ayodeji Okanlawon wrote:

NB: This is a process to add a new node to a leaf cluster not migrate phones...

 I think I understand your point now. Because the certs are CA signed except for the ITL recovery, you manually uploaded the root CA cert as tomcat-trust, callmanager-trust, phone-sass- trust and in addition you uploaded the self signed ITL recovery as a PhoneSast-trust and CallManager-trust?

---

Exactly what my original intention and theory was in trying this scenario out. If the CA signs the TFTP Call manager certs and we upload the CA as the trust, in theory it would work without having to do the bulk consolidation process. The bulk consolidation process is good for smaller setup but we run a Proxy TFTP setup via the SME and the leaf are the alternate tftp. The original intention is to not have to keep bulk consolidating new clusters added onto the SME proxy tftp setup. 

This is was for migration purposes from old cluster to new cluster via a SME Proxy TFTP setup.

But it also serves as a needed thing to do for UDS for Jabber. In a ILS full mesh network, all the servers needs to trust each other to avoid certficate prompts via UDS.

[Roger Kallberg]

The process to move a phone from one cluster (source) to another (destination)  should not need to have any certificates uploaded on the destination cluster. The phone is intended to ask it’s source, aka old cluster, if it can trust the new cluster it is connected to. It makes no difference if you have CA signed certificates. Also for the migration of phones it is only TFTP certificate that needs to be exchanged with the bulk certificate process and uploaded to the source cluster. On the source you will see this as Phone-Sast-trust, aka the destination TFTP (CallManager) certificate is uploaded by the bulk certificate process as this.

[hellohova]

Well aware of the tftp certificate process. But you are wrong in your first statement. Try it out in the lab as I have tested it already and came to the conclusion that I ended up posting.

[Roger Kallberg]

Well we have done it in a lab environment and also consolidated five clusters down to three that included about 15000 phones and I assures it didn’t include us uploading a single certificate on either of the destination clusters. All we did was to follow the process as outlined in the referenced document. So sorry but I’m not wrong about this @hellohova 

[Ayodeji Okanlawon]

Looks like things are mixed up here. Are we talking about migrating phones to a new cluster which requires certificate consolidation or adding a new leaf node to a SME cluster? Looks like you are referring to the latter. In that case, and according to the documentation you shared, yes you need to upload CA certs and ITL recovery as documented.

NB: This is different from what this thread was originally about hence the confusion...

@Roger Kallberg last post helped clarify this. 

[Roger Kallberg]

Hmm, we run a multi leaf cluster setup with SME and we don't have any need to do any certificate exchange when we add new nodes to any of the leaf clusters. Not that we do that very often, but it's has happened a couple of times.

@Ayodeji Okanlawon I will read through the document shared to see what @hellohova referenced.

[Roger Kallberg]

@hellohova 
The document shared is for AFAIKT when clusters need to trust each other for services like EMCC. From own experience if you don't run these kind of service you'd do not need to exchange certificates, but if you do then yes you'd need to exchange them as outlined in the referenced document.

It's not all easy to answer questions that has a sliding window, I mean starting with one topic and then move seamlessly over to something all together different.

[Ayodeji Okanlawon]

You got it @Roger Kallberg When using services that require https ( like EMCC as you mentioned) you would need to exchange certs. And yes this was a big sliding window.

@hellohova What services do you use that require https negotiations?