Starting with CallManger 8, Cisco introduced their “Secure By Design” mantra to CallManager. As its name suggests, the idea is to make CallManager more secure out of the box. An important note is that this does NOT mean CallManager encrypts everything on the wire out of the box. That involves putting CallManager in what’s called mixed-mode and that’s a discussion for another day.
With this new Secure By Design philosophy, CallManager administrators have an extra task to worry about: Security Certificates in CallManager. This task is made more unpleasant by two small details. Firstly, you only worry about it when certificates expire – which is only every couple of years. Secondly, get it wrong, and you potentially lock out all your phones!
With Secure By Design (SBD), the TFTP process cryptographically signs all configuration files served to phones. The phones then check the signature against a list of certificates in their Trust List. If the phones don’t recognise it, they refuse to use the configuration.
So where does this Trust List come from? The TFTP service builds a new one every time it starts. Every time the phone boots, it checks to see if it has the current Trust List. If it doesn’t, it downloads the new one. This trust list is signed by the TFTP’s CallManager certificate. If this trust list signing certificate can’t be validated, then the phone rejects the new trust list.
This is where our conundrum begins: If the TFTP service changes its signing certificate, the phone won’t be able to trust its configuration file signed by the TFTP server, or the trust list produced and signed by the TFTP server.
To help alleviate this problem, Cisco added the Trust Verification Service (TVS). If the phone can’t validate a certificate from its trust list, it then goes and asks the TVS for validation of a certificate. The TVS runs on all cluster nodes running the CallManager process.
The connection to the TVS service is checked from the phone’s existing trust list. The TVS can then validate the new signing certificate and the phone can accept the new trust list.
However, this only works if there is more than one node in the CallManager cluster. e.g. a Publisher/TFTP server and a subscriber running CallManager. If you have just a single node, then you have, what is called, a challenge.
In CallManager 10, Cisco added another certificate to the mix: The ITL Recovery certificate.
This extra certificate is managed separately to the CallManager certificate. The idea is that this ITL Recovery certificate is always in the trust list. If you need to, you can tell CallManager to sign the trust list with this separate ITL Recovery certificate (which the phone already trusts) and the phone can then obtain the new CallManager certificates. Once all the phones have obtained the new trust list, you can re-sign the trust list with the normal CallManager certificate and carry on as normal.