Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
1828
Views
0
Helpful
12
Replies

Upgrading from CUCM 6.1.3 to 8.5.1 and ITL Security Files

cadams
Level 1
Level 1

‎09-20-2011 12:44 PM - last edited on ‎03-25-2019 08:09 PM by Community Manager

Hello,

Has anyone had any experience with upgrading from 6x to 8.5.x?  We just completed a cluster upgrade from 6 to 8 and had a horrible time with the ITL files.  We eended up having to delete these files on over 600 phones before they would register correctly.  Now that we are moving to the next cluster for some odd reason the ITL files are not showing up on the phones at all.  I am fine with this but why?  We have not made any changes in the Enterprise Parameters such as modify the rollback pre 8.0.  From what we can tell, there is not reason as to why the ITL files shoud not be on the phone.  As it stands now I can register any phone type between this 8.5.1 cluster to 6.1.3 back to 8.5.1 without any issues.  This is because there isnt any ITL file.

Thanks,

Chad

Labels:
0 Helpful
12 Replies 12

Joseph Martini
Cisco Employee
Cisco Employee

‎09-20-2011 01:24 PM

If the phone firmware didn't upgrade, so if it is still pre-9.x the phone will not request an ITL file.  If the phone is upgraded to 9.x it will request and should get an ITL file with CUCM 8.x.

0 Helpful

cadams
Level 1
Level 1
In response to Joseph Martini

‎09-20-2011 01:33 PM

Joe,

We are running firmware version 9.1.1 on the phones and they are registered to 8.5.1 without any sort of ITL file.  This is what's puzzling.

Any ideas?

Thanks,

Chad

0 Helpful

cadams
Level 1
Level 1
In response to cadams

‎09-21-2011 01:18 PM

From the pub when doing show itl, the following error pops up:

        ITL Record #:7

                  ----

BYTEPOS TAG             LENGTH  VALUE

------- ---             ------  -----

1       RECORDLENGTH    2       719

2       DNSNAME         2

3       SUBJECTNAME     64      CN=jp01-cucm-01;OU=Synopsys;O=Synopsys;L=Synopsy                                s;ST=Japan;C=JP

4       FUNCTION        2       TVS

5       ISSUERNAME      64      CN=jp01-cucm-01;OU=Synopsys;O=Synopsys;L=Synopsy                                s;ST=Japan;C=JP

6       SERIALNUMBER    8       5B:6D:0C:1E:09:23:E8:95

7       PUBLICKEY       270

8       SIGNATURE       256

11      CERTHASH        20      5D 21 EC EE 21 07 4A 0C DB 4E 0C E9 80 2E 01 D3                                 88 22 19 F9

12      HASH ALGORITHM  1       SHA-1

Verification of the ITL file failed.

Error parsing the ITL File !!!

admin:

0 Helpful

Joseph Martini
Cisco Employee
Cisco Employee
In response to cadams

‎09-21-2011 01:33 PM

Thanks for sharing that.  It looks like the ITL file is corrupt, I haven't seen that before.  Do you have a TAC case open for this by chance?

0 Helpful

Gordon Ross
Level 9
Level 9
In response to Joseph Martini

‎09-21-2011 02:37 PM

By sheer coincidence, I'm having a very similar problem. The ITL file on my primary TFTP server is permantly corrupt. (My backup TFTP server on my publisher is fine)

TAC's initial suggestion was to stop the TFTP process, delete the ITL file, then restart the TFTP process. This worked once, and the ITL file stayed valid for about a week. After that, the ITL file became corrupt and won't get valid again.

TAC are going to WebEx onto my system tomorrow. I'll let you know if they fix it.

BTW - I'm on CUCM 8.6

GTG

Please rate all helpful posts.
0 Helpful

cadams
Level 1
Level 1
In response to Gordon Ross

‎09-21-2011 02:40 PM

Here is the fix:

Regenerate the following under OS and Security:

Call Manager pem/der

TVS pem/der

Tomcat pem/der

Perform a BACKUP!!!!

Restart TVS then TFTP services. Then, you are all set.

Chad

0 Helpful

Gordon Ross
Level 9
Level 9
In response to cadams

‎09-21-2011 02:44 PM

Hmm. With those certificates being regenerated, I'm surprised you don't have to bounce the box !

I'll have a play with that on my test cluster.

Thanks for the suggestion.

GTG

Please rate all helpful posts.
0 Helpful

cadams
Level 1
Level 1
In response to Gordon Ross

‎09-21-2011 02:46 PM

No need to bounce the server. Just restart the Trust Services and TFTP server on the node in which you regenerate the licenses.

Chad

0 Helpful

Gordon Ross
Level 9
Level 9
In response to cadams

‎09-21-2011 02:49 PM

I'd have thought the Tomcat cert would require Tomcat restarting, at least. I haven't clue what relies on the CallManager cert (Such an innocent sounding name for a certificate on a CallManager system...)

GTG

Please rate all helpful posts.
0 Helpful

Joseph Martini
Cisco Employee
Cisco Employee
In response to Gordon Ross

‎09-21-2011 03:18 PM

Be careful if these are production systems with regenerating the callmanager certificate.  Doing this changes the TFTP private key used for the ITL, meaning if you regenerate the callmanager certificate, you will have to manually delete the ITL from your phones because they will not trust the new one.  If you have multiple servers (some without corrupt ITL files) you can follow this guide to not have to delete each phone's ITL manually (

https://supportforums.cisco.com/docs/DOC-17679#Regenerating_Certificates__Rebuilding_a_Cluster__Certificate_Expiry).

0 Helpful

Gordon Ross
Level 9
Level 9
In response to Joseph Martini

‎09-21-2011 03:29 PM

Deleting the ITL file from every phone is not an option for me.

Thanks for the heads-up.

GTG

Please rate all helpful posts.
0 Helpful

cadams
Level 1
Level 1
In response to Joseph Martini

‎09-21-2011 03:44 PM

In my case this is not applicable as I don’t have any ITl’s… mine are corrupt.

Chad

0 Helpful
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Customers Also Viewed These Support Documents