By default (i.e., you didn't do extra work I'll describe in subsequent paragraphs), phones are not issued certificates by the CUCM cluster they are registered to. They come from the factory with a burned in, non-renewable, Manufacturer Installed Certificate (MIC) signed by Cisco that is valid for 10 years. Since the MIC is the only cert a phone has by default, that's what it offers when you access its web server. Without doing extra work, you would need to install the manufacturing CA(s) that the phones in your environment were issued certificates by as trusted root certificate authorities on your computer to avoid the warnings. The Security Guide has always advised customers to not trust the manufacturing CAs for TLS operations though, so this doesn't seem wise.
The sole intended use for a MIC is to serve as a trust anchor for enrolling in a Locally Significant Certificate (LSC) with CAPF on CUCM. Soft phones, which lack a MIC since Cisco didn't manufacture that hardware, instead use a numeric authorization string - that is supposed to be shared securely out of band - manually input by the user to get an LSC. CAPF is capable of being its own root certificate authority - although it's not great at that, hold that thought - or a proxy to another "real" certificate authority. Your computer would either trust the CAPF certificate on the publisher as a root CA or the external CA, depending on the approach you choose. The LSC is most commonly used for secure SIP/SCCP registration to CCM, 802.1x authentication to the NAC solution, and/or EAP-TLS WIFI network authentication for wireless IP Phone models. Phones will automatically use their LSC instead of the MIC for its web server as well. Note that SIP OAuth is a much better solution for secure registration than CAPF in CUCM 14+.
The MIC or authorization string trust anchor is how CUCM decides that the LSC enrollment request is from a legitimate endpoint instead of an attacker attempting to either maliciously register to CUCM or convince the NAC solution to permit access to the network. This is especially important because NAC must permit limited access to CUCM TFTP and CAPF pre-authentication in order for LSC enrollment to succeed. There are at least two icebergs hiding in the proverbial water here though:
- MICs cannot be renewed, giving phones an effective 10 year lifespan. The administrator must manually trigger the renewal of LSCs individually or via BAT jobs (e.g., by Device Pool every N years). LSC renewal requires the phone to be registered to CUCM when the renewal operation commences as well, so anything that's offline gets left behind.
- CAPF isn't a fully functional CA. For example, it has no certificate revocation mechanism for LSCs once they are issued. An organization with rigorous IT security operations team is likely to consider that unacceptable. This is where the online/offline external CA comes in. You can either download the CSR the phone gave to CAPF with RTMT, manually sign it, and then upload the CA-signed cert to CUCM for the phone to retrieve or configure a northbound CA to have CAPF automatically forward the CSR and get a signed certificate from. The latter is far more practical IMO.
TL;DR- You're stuck with browser security warnings unless you have an IT security mandate to avoid them at significant operational effort (i.e. the LSC renewals) or to implement 802.1x certificates-based authentication.
