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

Sat Jan 7 01:37:16 EST 2012

I regen'd TVS and Tomcat and restarted TVS, TFTP, Tomcat and checked
out the detailed TVS logs and it is able to write the file, no error
about the file not able to be written. 'show itl' shows everything
good on all servers.

Only error in the TVS detailed trace is this, not sure if this is an
issue or just cosmetic.

debug ERROR:tvsGetSubjectAltNameFromX509 :: X509_get_ext_d2i : Subject
Alternative Name is not found in the cert

I need to wait until Monday to see if the corp directory works now,
not onsite with the phones.

The System -> Server is by IP address (not name) and service
provisioning is set to Both.

Secure Directories URL is:

https://1.2.3.4:8443/ccmcip/xmldirectory.jsp

Device Settings -> Phone Services (Corporate Directory):

URL:  Application:Cisco/CorporateDirectory
XML Services
Directories

The Enterprise URL and Phone Services setup match another 8,5.1 system
where corp dir works fine with secure URLs.

On Fri, Jan 6, 2012 at 2:28 PM, Wes Sisk <wsisk at cisco.com> wrote:
> This sounds like you're in the situation where the ITL file cannot be rewritten to due file system permissions:
>
> CSCtr42021    TVS unable to update ITL file after rollback from a refresh upgrade
> <B>Symptom:</B>
> The Initial Trust List (ITL) file will not update on Cisco Unified Communications Manager (CUCM) 8.5(1) after restarting the Trust Verification Service (TVS).  The detailed level TVS logs will indicate the following:
> 17:28:45.585 |   debug ERROR:writeFile () - Unable to open file /usr/local/cm/tftp/ITLFile.tlv for writing (errno - 13)
>
> when this happens:
> * the file in the file system is the old incorrect file
> * TFTP serves up the old file from the file system
> * 'show itl' decodes the old itl file and shows old values
> * comparing those values to the newly generated certificates hightlights differences and indicates the problem
>
> If the phone ITL matches the TFTP ITL that is good. If the certs in the TFTP ITL do not match the certs in the database and CUCM file system that is bad.  This happens when the ITL file is written to the filesystem with incorrect file permissions so it cannot be overwritten.  Regenerate until you're blue in the face but the contents never change.
>
>
> This is why these became critical:
> CSCtj47446    show ITL should print md5sum of ITLFile.tlv
> CSCto60209    Display the file checksum in the show itl and show ctl commands
>
> without this it is difficult to compare the ITL file on CUCM server to the ITL file on the phones.  The only way is to download the ITL file and compute the md5sum.  This should match the serial number displayed on the phone UI.
> https://supportforums.cisco.com/docs/DOC-17679#Manually_Verifying_Phone_ITL_matches_CM_ITL_or_Dont_delete_your_ITL
>
> /wes
>
>
> On Jan 6, 2012, at 10:22 AM, Erick B. 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
>
>