CUCM - Expired CallManager-ECDSA Certificates

voip7372 · ‎02-11-2023

I have a CUCM cluster with 5 servers. 1 Pub and 4 Subs. 2 of the subscriber servers were added at a later date, so those 2 are not expired yet (ECDSA certs). I went through this process to regenerate and then delete any expired self-signed certificates, but I came across 2 certs I'm not sure about and want to get some advice about before I just go ahead and delete them.

The certs are CallManager-ECDSA and tomcat-ECDSA.

I don't see anything in the notes about those, so I was a little nervous about just deleting them, but they do have the option to delete. It's not a certificate with a regenerate option. So at this point after I did the regeneration of the certs using the process in the Cisco document I mentioned above, is it safe to delete these two and do nothing else?

For whatever reason, if I do a search for ANY certificate (expired or NOT expired), these are the only 2 certs I see with CallManager-ECDSA and tomcat-ECDSA in the name, so I'm thinking it's OK to remove them and do nothing else. Do you agree?

Roger Kallberg · ‎02-11-2023

What version of CM do you have?

voip7372 · ‎02-11-2023

Oops. Sorry. 11.5.1

yes, we’re behind and will upgrade this year but for now it’s 11.5.1

Roger Kallberg · ‎02-11-2023

In that version you’ll have both RSA and EC signed certificates for Tomcat and Call Manager. So you should not remove them without first having other in place.

voip7372 · ‎02-11-2023

I just searched for anything beginning with callmanager and tomcat in the certificate name. See attached screenshots. After going through the cert regen process, I have new certs with Key Type of RSA, but no new certs with the key type of EC. Since I have new callmanager and tomcat RSA certs (see screenshots) after regenerating the certs, in this case is it safe to go ahead and delete those old 'EC' certificates? There's only one old callamanager EC type cert but 3 old tomcat certs with the key type of EC.

To me it looks like the certificate regeneration process only recreates new RSA keys and leaves behind the old EC type keys (expired or unexpired).

Anyway, given what you know and what you've seen in the screenshots, is it OK to remove those callmanager and tomcat 'EC' key type certificates? (and thank you very much for your time)

Roger Kallberg · ‎02-11-2023

When you create the certificate you have the option to select elliptical curve as the signing key.

voip7372 · ‎02-11-2023

I did not do that. I simply followed the process described on this page (below).
https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/214231-certificate-regeneration-process-for-cis.html#anc23

Search for tomcat.pem cert and then open it, then click regenerate.

Like I said, all I did was follow the directions step-by-step on that webpage to regenerate the certificates for call manager, tomcat, etc. As soon as I clicked the regenerate button, it processes for a few seconds, and then gives you a success message, then you close that small window and continue with the next steps. The process did not include creating or regenerating any of those EC certs.

Roger Kallberg · ‎02-12-2023

Nevertheless in the version you have the elliptical curve certificates should be present as they are used by CM for internal communication between nodes. My guess is that someone has deleted the base certificate in both tomcat and call manager stores and all you’ve got left is the certificate in either of these trust stores, ie tomcat-trust and call manager-trust. The document doesn’t account for something that should not even be done, ie removing a certificate that is needed. That is why there is no mention of it. Advise you to look at a pure vanilla installed CM and compare what certificates you’re missing.

voip7372 · ‎02-12-2023

EDIT: Disregard this message. I went ahead and followed the process to update these ECDSA callamanager and tomcat certs and restarted everything it says to restart in the directions. That all worked out fine. All phones registered with no issues. I do have one more question I'll ask in a separate post here. Getting my notes together first...

Ah...OK. I see what's going on. On the publisher there is the original CallManager-ECDSA and tomcat-ECDSA certificates and those two are the ones that you cannot delete (the only option is to Regenerat, Generate CSR, Download .PEM File, Download .DER File)..they are still there.

I think what was confusing me when we started talking about this is that there was no mention in the directions of regenerating the ECDSA version of these certs AND for the tomcat certs for the 5 servers in the cluster there is the original tomcat-ECDSA.pem cert that can't be deleted, but some other tomcat certs for each server that CAN be deleted. I think what happened was some of those certs with the EC type that can be deleted did get deleted (yet a few remain).

I think all I need to do now is use the original ECDSA cert on the publisher and regenerate it and go from there. I'll have to add that to my notes for the future (unless it's not a step I have to do in version 14, because we'll be switching to 14...but for the time being, these had to be renewed in the version we have now).

Thanks for your help.

voip7372 · ‎02-12-2023

Edit: Removed this text because this part was no longer relevant.

voip7372 · ‎02-12-2023

See previous notes. I looked at what I had for certs and decided to follow the directions to update the ECDSA type certs (regenerate) and that all worked out well. No problems that I can see. Phones registered, etc, etc.

Now...I have a couple certs that have dates that don't line up with what I was expecting (and these are certs that are possible to delete, unlike the main few certs that only have the option to regenerate).

3 certs are callmanager trust and 1 is CAPF trust. Based on all the other new certs that appeared after doing the regeneration process, I was expecting to see an expiration date or 2028 or later, but I still have 3 callmanager trust certs that expire this year or 2026. Keep in mind that my original 3 servers in this cluster were installed in 2018 so I think the 2 that expire in Oct 2023 (CallManager-trust and CAPF-trust) are probably related to the original install.

I also assume the other 2 certs that expire in 2026 (2 CallManager-trust certs) are related to the 2 subscriber servers we added at some time after the original 3 subs were in service. The year 2026 matches the year all the other certs for those 2 subs had before I did the regen process.

SO...these leftover 4 certs don't match the new expiration dates of all the other certs that appeared after the regen process...therefore I'm thinking it's OK to just delete these? Do you agree? I'll attach a screenshot which is a complete list of the certs the publisher has now. I'll put a red box around the certs I'm suspicious of and would like to delete if they aren't needed. Again, they were not deleted by the regeneration process but with my limited knowledge of this topic, I can't say for sure that they were REPLACED with newer certs and these were simply left in place and need to be deleted, but I'm hoping and assuming that's the case.

These are the four I am curious about and suspect these can be deleted now:

CallManager-trust, CAP-RTP-002, Self-signed, RSA, CAP-RTP-002, CAP-RTP-002, 10/10/2023

CAPF-trust, CAP-RTP-002, Self-signed, RSA, CAP-RTP-002, CAP-RTP-002, 10/10/2023

CallManager-trust, CAPF-ac7577cb, Self-signed, RSA, CAPF-ac7577cb, CAPF-ac7577cb, 03/01/2026

CallManager-trust, CAPF-1db40864, Self-signed, RSA, CAPF-1db40864, CAPF-1db40864, 05/24/2026

Roger Kallberg · ‎02-12-2023

Any cert for CM services in the trust stores that have no match to a certificate in the base store can likely be removed. However I would recommend you to save a copy of the certificate as a pem file in some off system storage so that you have the option to restore it if needed.

voip7372 · ‎02-12-2023

OK. Thank you. Good idea.