[cisco-voip] ITL/CTL - CUCM 11

[Gr ccie]

Thanks Ryan - this is one of the  complex area in the CUCM. 

1) If we let the hardware token expire, do you mean we will not be able to use CTL update from the CLI and use software tokens? And we will need to have TAC perform the CTL recovery procedure from the root similar to the ITL recovery procedure in case we need security in future? Apart from the bug you have mentioned there is no other complications as ITL will have the certs with TVS as fallback - right?

2) The only reason I am looking at updating the CTL is as sometimes the third party tools don’t work on all the phones. I have Phonview but it will show CTL/ITL status for some phones unknown or unreachable even though I can see ITL/CTL from the web page. I am thinking of updating CTL to software token may stand better chances of pushing CTL to a larger number of phones than the number of phones I may be able to clear out remotely. 

Thanks

> On 27 Feb 2019, at 7:33 am, Ryan Ratliff (rratliff) <rratliff at cisco.com> wrote:
> 
> Inline.
> 
>  - Ryan Ratliff
> 
>> On Feb 26, 2019, at 7:39 AM, Gr ccie <grccie at gmail.com> wrote:
>> 
>> Hi Team,
>> 
>> Cucm cluster 11 was in secure mode once (using hw tokens) - then changed back to non-secure mode. The servers and phones both have the CTL files. 
>> 
>> 1) What issues can we run into if the hardware tokens expire? (Server has itl and ctl both)
>> Will the phones keep trusting files when it has both ITL AND CTL, based on ITL even if the CTL is corrupt or expired. 
> 
> If they expire your chance to update them with anything besides CTLRecovery is gone.
> 
>> 2) Any real benefit of updating the CTLs using the software CTL tokens by changing to secure mode and then again turn off secure mode?
> 
> Only to avoid the case where your eTokens expire. It shifts this risk to when the cert that signed the CTL (publisher CallManager.pem) expires instead.
> 
>> 3) Would it be a good idea to delete the CTL files from the server and phones if we don’t want mixed mode? How can we do it, we can delete the CTL from cli but how abt the phones - can we remove ctl by another method apart from the third party tools like phone view?
> 
> Yes, if you really want to make it look like mixed-mode never happened then you have to delete the CTL file everywhere, including at the phones. You are looking at automation via some 3rd party tool to do this.
> 
>> I believe LSC (being used for dot1x) would continue to operate by getting CAPF info from ITL. 
> 
> Correct, the CAPF cert is in both ITL and CTL so as long as the ITL remains current you won’t have an issue obtaining LSCs.
> 
>> 3) I need to regenerate the certificates as well on this cluster (capf/callmanager/tvs) - will it matter to have an updated CTL or expired?
> 
> This depends on the phones. There was a bug at one point with 78xx/88xx where they would invalidate their good ITL at boot because the cert that signed it wasn’t in the CTL. If your firmware version is up to date you won’t be exposed to that but.
> 
>> 4) Another unrelated question if we push a blank ITL file (enabling cluster rollback feature) and then update CTL in a secure CUCM (not something I would do but asking for sake of clarity) will it still trust the updated CTL file based on blank ITL? 
> 
> Empty ITL is still signed, it just doesn’t have a TFTP or CCM+TFTP role in it, so the phone doesn’t look for signed files from TFTP. Accepting that ITL is still subject to validation of the cert that signed it against the certs in the current trust store (CTL + ITL).
> 
>> 
>> Thanks,
>> GR
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20190227/147a4adf/attachment.html>