As several have noted in this thread returning the cluster to non-secure mode doesn't actually delete the CTL file from the Publisher or TFTP server. You must manually delete this file with the command file delete tftp CTLFile.tlv before TFTP will stop handing this file out to endpoints that request it.    This was not covered very well in older versions of the Security Guide.  This document is a good summary of the process.   The reason you saw this particular error with 7925 phones is because that phone model, similar to the 7940/60, validate that the TFTP server the phone is using is actually in the CTL file. This is a security mechanism that was removed from the other phone models because it was too onerous for customers that move phones between clusters. If you were to check your other phones they would also show a CTL file installed, though it will not be used for anything in a non-secure cluster.   If you are seeing this error on a 7925 (or an older 7940/60) do the following: Check that the phone is using the correct TFTP server Check to see if your TFTP server is handing out a CTL file when it should not be (file list tftp CTLFile.tlv from the UCM CLI or curl http://tftp.server:6970/CTLFile.tlv from a linux shell).  Delete any CTL file that shouldn't be there on the publisher and all TFTP servers via file delete tftp CTLFile.tlv. Delete the CTL file on all phones. As others have observed if you delete the CTL file on the phone without confirming it's not on the server it's just going to come back. All Cisco phones are hard-coded to ask for the CTL file as the first step registration. ... View more

After generating a CSR for tomcat and getting it signed by your CA the resulting certificate should be uploaded as a tomcat certificate, not tomcat-trust. This is how you replace the self-signed certificate generated by the system with the one that corresponds to the CSR you generated. The system will validate the certificate you are uploading against the last CSR that was generated so you cannot inadvertently replace the service certificate. ... View more

You need to manually regenerate the CTL file any time a certificate contained in the CTL changes.  The CTL does not contain the TVS cert so in your case that would not require a CTL update. The CallManager.pem certificate would require a CTL update. Make sure you reset all of your phones between uploading the new CallManager and TVS certificates. If you do both at the same time you risk breaking the trust chain for your ITL files. ... View more

In the text you quoted the term application certificate is the same thing as an identity certificate.  Yes this procedure does apply for CUC, UCCX, and IMP as they all share the same platform. I can't guarantee that UCCX or CUC will share trust certs among multiple servers though. You will want to validate that for yourself. ... View more

You've got it Amit.  That is exactly how the process is supposed to work. Things mostly go bad when the phone doesn't trust the updated ITL so it can't pick up the new TVS certificate.  When you have multiple nodes and your TFTP server isn't running CCM this gets more reliable because you tend to update certificates on one node at a time, so the TVS servers don't change at the same time the TFTP server's CallManager.pem cert does. ... View more

Suppose all of my certs expire on the same day, what should be the approach to regenerate the certs? The key to regenerating certs and not screwing up your ITL is to do one of your CallManager.pem or TVS.pem certs at a time and make sure that the phones get the updated ITL after each cert is changed.  Which cert you do first shouldn't matter as long as you are starting with the phones having a current ITL, and as long as the phone has a current TVS cert in its ITL it'll update any ITL signed by a cert that TVS can validate. Note that uploading or regenerating either cert will reset all your phones automatically in an attempt to let them to get an updated ITL. You don't have a choice in this so don't go doing cert operations in the middle of the day or you risk angering your users. Say you don't know the state of the ITLs on all of your phones. How can you test this? A quick way to do it is to change your CM group around to move all your phones from a primary sub to a backup and reset all your phones (leave the primary in the CM group though). Since the list of servers to register to is contained in the config file, which is always signed and validated by the ITL, any phone that registers back to the former primary didn't get an updated config file and should be investigated.  ... View more

Those certs are used by TVS to validate files and TLS connections from phones that encounter them and don't have the cert in an ITL or CTL. They are used in EMCC but also could be used just by a phone failing over to a backup TFTP server before 11.0. I'm not surprised at all the phones reset because you changed a cert that is involved in the Security By Default feature. I still can't get phones to reset on my 10.5 cluster even by deleting the local server's phone-SAST-trust cert. It's likely this is behavior that's changed since 9.1.2. The ccm process should not have cored, and you could open a TAC case to get a defect for it.  ... View more

Were those old certs you were deleting or the current ones? The phone-sast-trust certs are there for TVS to validate ITL files signed by those certs, so you shouldn't really be deleting them.  If you did happen to delete one of the active certs from a subscriber (the cert will have the same serial number as an active CallManager-trust) then yes it very well could cause phones to reset. Those certs aren't in the ITL until UCM 11.0  I'd recommend you download all your CallManager-Trust certs for subs and re-upload them as phone-SAST-trust and figure out a plan going forward. ... View more

To quickly define the terms an identity cert is the cert used by the local CUCM/CUC/UCCX service for TLS connections. CallManager.pem, Tomcat.pem, etc are all identity certs. Intermediate and Root certs the certs that "issue" (sign) other certs. In your workflow they come from your CA and you have to upload them as trust certs BEFORE the CA-signed cert from your CSR can be uploaded.  If you are having the same CA sign a CallManager cert on a 4-node cluster you would upload (in this order): Pub: CallManager-Trust (root), CallManager-Trust (intermediate), CallManager.pem (for pub) Sub1-3: CallManager.pem (for the local server). For a multi-server cert you upload everything only on the pub.  I hope this clarifies things for you. ... View more

Anything that is in an ITL should trigger phone resets. I just tested in  10.5.2.12901-1 and when I deleted a remote cluster's phone-sast-trust cert it did not trigger any phone resets. If your ccm service cored then yes your phones (registered to that node) would have been reset. ... View more

The identity certs you upload for the publisher will be propagated to the subs as trust certs. The intermediate and root certs you upload (as trust certs) to the pub will also be distributed to the subs as well. You will know if this isn't the case when you try to upload the sub's signed cert and it fails because the root cert isn't present. For LSCs as the document indicates you set the CAPF service parameter to external then tell all your phones to install/update an LSC. You use the CLI on the publisher to get a list and download the CSRs, they will not appear anywhere in Certificate Management. With regards to SHA2 if that's a requirement you must upgrade or you will just have to generate your certs again.  One thing to consider with 10.5 is the multi-server certificates, particularly for Tomcat. This will make your life much easier since all the nodes in the cluster share the same certificate. When going to 10.5 make sure you are on the latest SU available before doing anything with multi-server certificates.  Finally, be prepared for several things to happen when uploading new certs. For starters your phones will reset on each cert change. This is done so the phones will get an updated ITL. Next in later versions you will have to wait 5 mins between uploading different certs. This is so the phones that got reset with the last cert you uploaded have a chance to all get their new ITL.  If you are going to CA-sign all of your UCM certs then make sure you do them one server at a time, and verify all the phones come back and have updated ITLs before you move to the next server. ... View more

The button to download a CSR is there in 10.5 just as it is shown in the screenshots above. If you are using a CA to sign endpoint LSC certificates then you have to get the CSRs from the CLI. Follow the steps in the UCM Security Guide.  For your second question Trust certs are propagated to the entire cluster by the  Cisco Certificate Change Notification service. Multi-server certificates are only uploaded to the publisher. Single-server identity certs must be uploaded to the server that generated the CSR. ... View more

Endpoints that run the TC software do not support FAC or CMC. ... View more

If the iPhone is seeing the desktop phone then it should be good to go.  I think in your screenshot I can see the "Now Discoverable" message.   Is your 8861 using wifi or a wired network connection?  If it's not showing any bluetooth devices at all (headset, phone, PC, etc) then you can try toggling bluetooth on/off on the 8861.  At this point you can also just open a TAC SR.  Collect phone debugs from the web page of the phone so you can provide them to TAC.   ... View more

This is what it looks like on my 8851.  The process should be pretty simple. Here is the bluetooth settings.  BT is on, and I then hit 3 to add a device.   After hitting 3 I get this screen. There is an interim display where it says to make sure the other device is discoverable.  After I go into the Bluetooth settings on my iPhone it appears in the list.   After I select "rratliff's iPhone" and hit Pair I get this prompt.   At this point on my iPhone I get the same prompt you show above, with the same security code shown.  After I hit Yes on the 8851 and Pair on the iPhone the connection proceeds and I'm asked about contact syncing on the 8851. ... View more