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