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

Fri Jan 6 11:37:48 EST 2012

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120106/93de0d9a/attachment.html>