CUCM Security- MIC certificates

[Pasha Teplitsky]

Hi guys,

I've read in several docs that default root certs (CAP-RTP-001, CAP-RTP-002, Cisco_Manufacturing_CA and Cisco_Root_CA_2048) should be deleted from the trust store in CUCM so that only LSC certs will be used (trusted) to initiate a TLS connection with CUCM.

Deleting these root certs will no allow the phone to initiate TLS connection using it's MIC certificate. 

In other words, CUCM will not trust MIC certs anymore.

What bothers me is that we actually use an existing cert (MIC) to install LSC certs on the phone for the first time.

Won't deleting the root certs that allow us to trust MIC brake this operation??

[Jonathan Schulenberg · Accepted solution]

Not if you’re careful which trust store you delete them from. You want to delete them from the CallManager-Trust but NOT the CAPF-Trust. The former is which client certifies to allow for phone registration and while the later defines which client certificates to permit for CAPF enrollment.

[Pasha Teplitsky]

Great answer Jonathan,

Thanks a lot!

[richard-ferguson]

The 'penny has just dropped' for me because there is both confusion and subtly in this issue: There are multiple CA's installed in a CUCM's trust store that Cisco have used to issue different phone MICs to different phones over a large number of years.
It's easy to think that all phones may be at risk when CAP-RTP-001 or 2 expires, which is not true.
ONLY those phones with MIC issued by CAP-RTP-001 are expiring on 7 Feb 2023 and may be affected.
Next, CAP-RTP-002 which expires 11 October 2023. Only phones with MIC issued by that CA cert may be affected when that cert expires.
Next, the other ACT... and Cisco_... CAPF CA certificates start expiring 15 May 2029, 13 Jan 2033 - years away.
It's agonisingly hard to find out which phones will be affected but here's how:
1/. Set phones to Troubleshooting
2/. reset the phones
3/. SFTP out the SEP*-M1.cer and/or SEP*-L1.cer files to your SFTP server of your choice file get activelog /cm/trace/capf/sdi/SEP*
4/. open each cert and compare the Issuer:  name to the CAPF-trust CA certs in your CUCM
5/. If the CA cert expires soon, install an LSC on the affected phones which signs the LSC with the current CAPF Identity cert and you're covered

Above does not encompass all the possible 802.1X issues but does fill in the missing info that you need to know to both identify  affected phones, then re-risk them. Only if you're very unlucky, will you have many many phones issued by CAP-RTP-001 or -002 and maybe have an issue in 2023

[richard-ferguson]

Every Identity cert has an 'Authority Key Identifier' that identifies the issuing Authority (a.k.a. CA).

When a phone's MIC 'Authority Key Identifier' = a CA's 'Subject Key Identifier', the 'Issuer' name will also match, and you will have 100% identified the CA, hence found the expiry date that the CUCM Cisco CA trust cert expires on.

Using this method is painful with lots of phones but is 100% verifiable