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

Erick B. erickbee at gmail.com
Fri Jan 6 12:04:37 EST 2012 

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
>>
>

More information about the cisco-voip mailing list