[cisco-voip] ITL and TVS question - CUCM 8.5.1.14048-1 and Secure URLs not working (corp dir, etc)

Erick ewellnitzvoip at gmail.com
Fri Jan 6 13:15:56 EST 2012 

Have you restarted tomcat?  I've had to do that before for similar issues.

On Jan 6, 2012, at 11:04 AM, "Erick B." <erickbee at gmail.com> wrote:

> Yea, Tomcat is running on all servers.
> 
> Ted, I will try regen those others but have ITLs on the phones now.
> Checking some other things out and working with TAC also.
> 
> On Fri, Jan 6, 2012 at 10:37 AM, Justin Steinberg <jsteinberg at gmail.com> wrote:
>> erick B. are you sure that the Tomcat service is running on the server that
>> your phones are registered with ?   IIRC the corp directory goes to the
>> registered CM rather than following the directory URL.   I've seen before
>> where tomcat was down on a sub and caused this problem.
>> 
>> Regarding the bigger SBD/TVS issue, does anyone know if it would be ok to
>> just set the 'Prepare Cluster for Rollback to pre-8.0' parameter to True and
>> leave it that way?  The downside of a ITL issue just outweighs any benefits
>> that I see from using the SBD feature.   I like the idea of TVS/ITL giving
>> the phone the ability to interact with HTTPS servers but the signed TFTP
>> part is just killing us.
>> 
>> 
>> On Fri, Jan 6, 2012 at 10:34 AM, Ted Nugent <tednugent73 at gmail.com> wrote:
>>> 
>>> FYI... TACs recommendations were to regen the cert for, tomcat, tvs and
>>> callmanager on both pub and sub.
>>> also the directory worked fine on IP Communicator obviously but that
>>> reassured me that we still had a TVS issue.
>>> 
>>> 
>>> On Fri, Jan 6, 2012 at 10:22 AM, Erick B. <erickbee at gmail.com> wrote:
>>>> 
>>>> Well, still getting host not found for corporate directory and the secure
>>>> URLs.
>>>> 
>>>> Regen'd the certificate and restarted, phones reset and have valid ITL
>>>> now and signed config files. The phone config file shows the IP
>>>> address in TVS section so the System -> Server has IP addresses and
>>>> Directories URL uses IP addresses but still host not found.
>>>> 
>>>> 
>>>> 
>>>> On Thu, Jan 5, 2012 at 11:55 PM, Erick B. <erickbee at gmail.com> wrote:
>>>>> Yep. And DNS is a license hash changer to so got to go spend time with
>>>>> licensing at cisco.com depending on your install type.
>>>>> 
>>>>> It's been awhile, but back in 4.x when security stuff first was coming
>>>>> to light I had a client who used it on each phone with manual keys and
>>>>> setting up new phones took awhile to get the key on there and working
>>>>> in 4.x. So I still have that memory and don't want to mess something
>>>>> up and have to go onsite to manually delete security keys (ITLs, etc)
>>>>> from phones to download new ones unless I have to. Maybe they should
>>>>> have phone firmware delete all the keys on like a 3rd reboot if the
>>>>> phone is just cycling.
>>>>> 
>>>>> I'm going to look into the tool for it also.
>>>>> 
>>>>> On Thu, Jan 5, 2012 at 11:30 PM, Ted Nugent <tednugent73 at gmail.com>
>>>>> wrote:
>>>>>> Wow... this is the 3rd time I've seen this issue in less than a
>>>>>> week.... A
>>>>>> buddy of mine just hit this yesterday and I hit something similar last
>>>>>> week
>>>>>> after a client enabled DNS on their cluster. They worked directly with
>>>>>> TAC
>>>>>> and did not find a resolution in a "timely manner" so they called me.
>>>>>> We
>>>>>> walked through everything in the link below as well as what TAC
>>>>>> recommended
>>>>>> and the only thing that fixed the problem was blowing away the ITL on
>>>>>> the
>>>>>> phone. That of course was not an acceptable answer so I sent them back
>>>>>> to
>>>>>> TAC to see if they could find more info.... long story short they had
>>>>>> to
>>>>>> delete the ITL on all their phones to get resolution.... Needless to
>>>>>> the say
>>>>>> the client was furious and understandably so... I understand the why
>>>>>> and the
>>>>>> how but can't see how crushing the ITL on EVERY phone is an
>>>>>> acceptable workaround for such a minor "whoops"...
>>>>>> Sadly with the changes in the TVS I see a ton of this in our future
>>>>>> because
>>>>>> clients do shit without understanding the consequences and this is a
>>>>>> serious
>>>>>> consequence for such a MINOR change....
>>>>>>  Yes i know we can go BUY a utility to assist with deleting the ITL
>>>>>> but if
>>>>>> that is the answer then you've missed the point.
>>>>>> 
>>>>>> https://supportforums.cisco.com/message/3240766#3240766
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Thu, Jan 5, 2012 at 5:35 PM, Erick B. <erickbee at gmail.com> wrote:
>>>>>>> 
>>>>>>> Jason,
>>>>>>> 
>>>>>>> Thanks. That is it to the T.  The serial number on the SQL query
>>>>>>> doesn't match the serial number on the OS admin page for  that role
>>>>>>> and the 'show itl' output does have all 3 of the errors (This etoken
>>>>>>> was not used to sign the ITL file, Verification of the ITL file
>>>>>>> failed., Error parsing the ITL File !!! ).
>>>>>>> 
>>>>>>> I'm going to proceed with these steps on the primary server noted in
>>>>>>> the bug and what you have below tonight.
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Jan 5, 2012 at 11:57 AM, Jason Burns <burns.jason at gmail.com>
>>>>>>> wrote:
>>>>>>>> Erick,
>>>>>>>> 
>>>>>>>> Did you also migrate to new hardware and use the backup and restore
>>>>>>>> (DRS)
>>>>>>>> process during the upgrade?
>>>>>>>> 
>>>>>>>> If so, you might be running into the following condition / defect.
>>>>>>>> Give
>>>>>>>> this
>>>>>>>> a read and check it out.
>>>>>>>> 
>>>>>>>> https://supportforums.cisco.com/docs/DOC-17679#Backup_And_Restore
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtn50405
>>>>>>>> 
>>>>>>>> If you're sure that none of the phones have ITL files installed
>>>>>>>> then it
>>>>>>>> is
>>>>>>>> safe to regenerate the CallManager.pem certificate and restart TVS,
>>>>>>>> TFTP,
>>>>>>>> and CallManager (in that order) to resolve this problem if you can
>>>>>>>> confirm
>>>>>>>> you're running into it.
>>>>>>>> 
>>>>>>>> -Jason
>>>>>>>> 
>>>>>>>> On Thu, Jan 5, 2012 at 10:26 AM, Erick B. <erickbee at gmail.com>
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> Question on regenerating TVS certificate, client upgraded from 6.x
>>>>>>>>> to
>>>>>>>>> 8.5.1.14048-1 and ever since the corp directory is not working on
>>>>>>>>> phones that use secure URLs (7911, 7975, etc). I set it to a
>>>>>>>>> non-secure URL and restarted TVS service like in a cisco article I
>>>>>>>>> found and the corporate directory still saids host not found when
>>>>>>>>> they
>>>>>>>>> try to use it. Same problem for services url.
>>>>>>>>> 
>>>>>>>>> The phones have no ITL file installed on them and no trust list
>>>>>>>>> right
>>>>>>>>> now either. I set up a IP communicator and the corp directory
>>>>>>>>> worked
>>>>>>>>> on that, it was using the non-secure URL even though I had secure
>>>>>>>>> directories URL configured.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I found another cisco document on this with another step that
>>>>>>>>> states
>>>>>>>>> to do a 'show itl' on the server and if the verification fails to
>>>>>>>>> regenerate the TVS certificate. The 'show itl' shows verification
>>>>>>>>> failed, and I've read over the Security By Default document on the
>>>>>>>>> support site and I think I am safe by just regenerating the TVS
>>>>>>>>> certificate and resetting the phones but I wanted to ask here as I
>>>>>>>>> haven't dealt with this yet really and my past run ins with
>>>>>>>>> security
>>>>>>>>> and certificates on the phones were not all that pleasant. I do
>>>>>>>>> have a
>>>>>>>>> TAC case on this also but the person doesn't seem to know what to
>>>>>>>>> do
>>>>>>>>> with this ITL not verifying issue and currently wants me to
>>>>>>>>> downgrade
>>>>>>>>> from 9.2 firmware to 8.5.4 to fix the corp directory issue.
>>>>>>>>> 
>>>>>>>>>  Any other things I can try? I'm going to try to find a better TAC
>>>>>>>>> resource in meantime.
>>>>>>>>> 
>>>>>>>>> Erick
>>>>>>>>> _______________________________________________
>>>>>>>>> cisco-voip mailing list
>>>>>>>>> cisco-voip at puck.nether.net
>>>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> cisco-voip mailing list
>>>>>>> cisco-voip at puck.nether.net
>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>> 
>>>>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>> 
>> 
> 
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

More information about the cisco-voip mailing list