<p>I think the parameter you mention is explained here. There are some caveats to it.<br>
<a href="https://supportforums.cisco.com/docs/DOC-15799#Rollback_Enterprise_Parameter">https://supportforums.cisco.com/docs/DOC-15799#Rollback_Enterprise_Parameter</a></p>
<div class="gmail_quote">On Aug 16, 2011 5:32 AM, "Ahmed Elnagar" <<a href="mailto:ahmed_elnagar@hotmail.com">ahmed_elnagar@hotmail.com</a>> wrote:<br type="attribution">> There is a service parameter that allows you to revert back to an older<br>
> version.<br>> <br>> <br>> <br>> Regards,<br>> <br>> Ahmed Elnagar | Unified Communication Team Leader | CCIE #24697, Voice<br>> <br>> Description: Description: MS Green<br>> <br>> <br>
> <br>> From: <a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a><br>> [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a>] On Behalf Of Casper, Steven<br>
> Sent: Monday, August 15, 2011 5:09 PM<br>> To: 'Jason Burns'; Wes Sisk<br>> Cc: <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>> Subject: Re: [cisco-voip] Security By Default and ITL (was Phones Not<br>
> Getting Auth, Idle, Services URLS, etc)<br>> <br>> <br>> <br>> First of all this is an excellent thread with a lot of valuable details. I<br>> have started to review upgrading from 7.1.5 to 8.5 or 8.6. Far as I can tell<br>
> all the Security by Default configuration should be automatically done by<br>> the upgrade process and once complete the TFTP servers should be reset and<br>> the phones reset again to ensure the phones retrieve the ITL file. Seem<br>
> simple enough but the thought that something could go wrong and it could be<br>> necessary to have users delete the ITL config from 12,000 phones is one that<br>> could keep me up at night though.<br>> <br>> <br>
> <br>> How has it been going out there with Security by Default and upgrades to<br>> 8.x... any gotcha's or caveats? I am leaning towards the latest version of<br>> 8.5 over 8.6 since 8.6 does not seem to have many new features I need but is<br>
> one release preferred over the other based on the upgrade process? I am<br>> running a multi-node cluster on 7.1.5.11900-6 in the non-secure mode<br>> <br>> <br>> <br>> Steve<br>> <br>> <br>> <br>
> From: <a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a><br>> [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a>] On Behalf Of Jason Burns<br>
> Sent: Saturday, August 13, 2011 8:11 AM<br>> To: Wes Sisk<br>> Cc: <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>> Subject: Re: [cisco-voip] Security By Default and ITL (was Phones Not<br>
> Getting Auth, Idle, Services URLS, etc)<br>> <br>> <br>> <br>> I wanted to follow up on this thread. The "show itl" command was a key piece<br>> of the troubleshooting process that let us track this down. After this<br>
> incident though I wanted to take some time to explain how ITL and Security<br>> By Default worked, and also document the common troubleshooting steps I<br>> used.<br>> <br>> <br>> <br>> Hopefully this document will help you out in the future!<br>
> <br>> <br>> <br>> <a href="https://supportforums.cisco.com/docs/DOC-17679">https://supportforums.cisco.com/docs/DOC-17679</a><br>> <br>> <br>> <br>> Support Forums mangles pictures in the thumbnail view, but you should be<br>
> able to click on each diagram to full size it and get a better understanding<br>> of what goes on in the background.<br>> <br>> <br>> <br>> -Jason Burns<br>> <br>> On Thu, Jun 30, 2011 at 5:31 PM, Wes Sisk <<a href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>> wrote:<br>
> <br>> Summary for the innocent bystanders:<br>> <br>> * Phone previously registered to 7.1.5 cluster with no CTL. Phone got ITL<br>> file from new cluster successfully.<br>> * Phone console logs show:<br>
> 2155: ERR 12:08:23.841097 SECD: EROR:verifyFile: sgn verify file<br>> failed</usr/ram/SEP00260BD749E9.cnf.xml>, errclass 8, errcode 19 (signer not<br>> in CTL)<br>> 2156: ERR 12:08:23.841825 SECD: EROR:verifyFile: verify<br>
> FAILED,</usr/ram/SEP00260BD749E9.cnf.xml><br>> 2157: NOT 12:08:23.844821 SECD: sendRespToClient: Sent the response to the<br>> TVS client, len : 2056<br>> 2158: NOT 12:08:23.860569 tftpClient: authorize file = 13, isEncr = 0<br>
> <br>> * phones show ITL downloading successfully. suspect problem with ITL file.<br>> Get TVS logs.<br>> <br>> * This is where things got sketchy. CLI command 'show ITL' shows the TFTP<br>> entry for the publisher with a serial number. We checked all certificates<br>
> in ccmadmin under system->security->certificates. No serial numbers match<br>> the current ITL file. We tried regenerating CallManager.pem as that should<br>> be the cert TFTP uses. After regenerating, restarting TVS, and restarting<br>
> TFTP the cli command 'show itl' still shows incorrect serial number for TFTP<br>> certificate. This means ITL file is not being updated properly.<br>> <br>> * Checked TVS logs. Many red herrings there but one substantial error:<br>
> 11:45:18.827 | debug ERROR:writeFile () - Unable to open file<br>> /usr/local/cm/tftp/ITLFile.tlv for writing (errno - 13)<br>> 11:45:18.827 | debug In function : tvsGetPublicKeyFromX509<br>> 11:45:19.100 |ITLFileRegenerated - New ITL File has been generated. <br>
> <br>> TVS could not write new ITL file.<br>> <br>> Checked filesystem permissions on Matthew's box:<br>> [root@server ~]# ls -la /usr/local/cm/tftp/ITLFile.tlv<br>> -rw-r--r-- 1 ctftp ccmbase 3664 May 25 13:18 /usr/local/cm/tftp/ITLFile.tlv<br>
> <br>> On lab box:<br>> [root@CUCM85Pub sdi]# ls -la /usr/local/cm/tftp/ITLFile.tlv<br>> -rw-r--r-- 1 certbase ccmbase 4930 Jun 30 15:38<br>> /usr/local/cm/tftp/ITLFile.tlv<br>> <br>> Permissions issue. On Matthew's box:<br>
> [root@server ~]# ps -eaf | grep -iE "TFTP|TVS"<br>> certbase 31007 17132 0 15:35 ? 00:00:00 /usr/local/cm/bin/tvs<br>> ctftp 31574 17132 0 15:36 ? 00:00:02 /usr/local/cm/bin/ctftp<br>
> <br>> Looks like ctftp service most likely wrote or created ITL file on May 25.<br>> The owner of ITLFile.tlv should be certbase not ctftp. We did:<br>> 1. chown certbase ITLFile.tlv - this set the correct owner<br>
> 2. restarted TVS service - TVS regenerated ITL file and successfully wrote<br>> it to the file system<br>> 3. restart TFTP service so it could pickup the new ITL file from the file<br>> system.<br>> <br>> After this phones successfully registered. So far there is at least one new<br>
> bug out of this:<br>> CSCtr27100 TVS inaccurately reports New ITL File has been generated<br>> <br>> In CUCM 8.6 ctftp does indeed generate the ITL file. In 8.5.1.11900-21 (aka<br>> 8.5.1su1) that Matthew is running ITL file should be generated by TVS.<br>
> <br>> Regards,<br>> Wes<br>> <br>> <br>> <br>> On 6/30/2011 4:17 PM, Matthew Loraditch wrote: <br>> <br>> Well I just finished what amounted to 5 hours on the phone and 6 hours for<br>> Cisco. Most of that with Wes and apparently Ryan Ratliff and Jason Burns<br>
> stopped by for a while as well!<br>> <br>> Anyway we got it fixed. Wes said he is going to do a write up but the gist<br>> was the ITL cert was written by the wrong service and thus not matching up<br>> and they had to go in with root and do something so that right service could<br>
> properly create it.<br>> <br>> <br>> <br>> Major Kudos to Wes and if we are ever within 50 miles or less of each other<br>> drinks are in order!<br>> <br>> <br>> <br>> <br>> <br>> Matthew Loraditch, CCVP, CCNA, CCDA<br>
> 1965 Greenspring Drive<br>> <br>> Timonium, MD 21093 <br>> <mailto:<a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a>> <a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a><br>
> (p) <tel:%28410%29%20252-8830> (410) 252-8830<br>> (F) <tel:%28443%29%20541-1593> (443) 541-1593<br>> <br>> Visit us at <<a href="http://www.heliontechnologies.com/">http://www.heliontechnologies.com/</a>> <a href="http://www.heliontechnologies.com">www.heliontechnologies.com</a><br>
> <br>> Support Issue? Email <mailto:<a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a>><br>> <a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a> for fast assistance!<br>
> <br>> <br>> <br>> From: <mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a>><br>> <a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a> [<br>
> <mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a>><br>> mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a>] On Behalf Of Matthew Loraditch<br>
> Sent: Thursday, June 30, 2011 11:24 AM<br>> To: Lelio Fulgenzi<br>> Cc: <mailto:<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
> Subject: Re: [cisco-voip] Phones Not Getting Auth, Idle, Services URLS, etc<br>> <br>> <br>> <br>> Wes is helping out and watching my case so far we have just verified normal<br>> settings, regenerated the tomcat certs to no avail and then totally factory<br>
> defaulted the phone (the 123456789*0#) and now the phone comes up<br>> unprovisioned and won't connect at all!<br>> <br>> Engineers seem pretty stumped<br>> <br>> <br>> <br>> <br>> <br>> Matthew Loraditch, CCVP, CCNA, CCDA<br>
> 1965 Greenspring Drive<br>> <br>> Timonium, MD 21093 <br>> <mailto:<a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a>> <a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a><br>
> (p) <tel:%28410%29%20252-8830> (410) 252-8830<br>> (F) <tel:%28443%29%20541-1593> (443) 541-1593<br>> <br>> Visit us at <<a href="http://www.heliontechnologies.com/">http://www.heliontechnologies.com/</a>> <a href="http://www.heliontechnologies.com">www.heliontechnologies.com</a><br>
> <br>> Support Issue? Email <mailto:<a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a>><br>> <a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a> for fast assistance!<br>
> <br>> <br>> <br>> From: Lelio Fulgenzi [ <mailto:<a href="mailto:lelio@uoguelph.ca">lelio@uoguelph.ca</a>> mailto:<a href="mailto:lelio@uoguelph.ca">lelio@uoguelph.ca</a>] <br>> Sent: Thursday, June 30, 2011 11:21 AM<br>
> To: Matthew Loraditch<br>> Cc: Matthew Loraditch; <mailto:<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>><br>> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
> Subject: Re: [cisco-voip] Phones Not Getting Auth, Idle, Services URLS, etc<br>> <br>> <br>> <br>> Let us know how that goes...<br>> <br>> Sent from my iPhone<br>> <br>> <br>> On Jun 30, 2011, at 9:09 AM, Matthew Loraditch<br>
> <<a href="mailto:MLoraditch@heliontechnologies.com">MLoraditch@heliontechnologies.com</a>> wrote:<br>> <br>> Well I have done what Lelio suggested, I have rebooted the cluster. I<br>> noticed from the phone logs and in security settings that the certs they are<br>
> getting say the hostname so I changed the CCMs from IP back to hostname.<br>> Still no dice.<br>> <br>> Time to open a TAC case!<br>> <br>> <br>> <br>> <br>> <br>> Matthew Loraditch, CCVP, CCNA, CCDA<br>
> 1965 Greenspring Drive<br>> <br>> Timonium, MD 21093 <br>> <mailto:<a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a>> <a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a><br>
> (p) <tel:%28410%29%20252-8830> (410) 252-8830<br>> (F) <tel:%28443%29%20541-1593> (443) 541-1593<br>> <br>> Visit us at <<a href="http://www.heliontechnologies.com/">http://www.heliontechnologies.com/</a>> <a href="http://www.heliontechnologies.com">www.heliontechnologies.com</a><br>
> <br>> Support Issue? Email <mailto:<a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a>><br>> <a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a> for fast assistance!<br>
> <br>> <br>> <br>> From: <mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a>><br>> <a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a> [<br>
> <mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a>><br>> mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a>] On Behalf Of Matthew Loraditch<br>
> Sent: Wednesday, June 29, 2011 9:57 PM<br>> To: Lelio Fulgenzi<br>> Cc: <mailto:<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
> Subject: Re: [cisco-voip] Phones Not Getting Auth, Idle, Services URLS, etc<br>> <br>> <br>> <br>> Will give it a whirl in the am<br>> <br>> <br>> <br>> Matthew Loraditch, CCVP, CCNA, CCDA<br>
> 1965 Greenspring Drive<br>> <br>> Timonium, MD 21093 <br>> <mailto:<a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a>> <a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a><br>
> (p) <tel:%28410%29%20252-8830> (410) 252-8830<br>> (F) <tel:%28443%29%20541-1593> (443) 541-1593<br>> <br>> Visit us at <<a href="http://www.heliontechnologies.com/">http://www.heliontechnologies.com/</a>> <a href="http://www.heliontechnologies.com">www.heliontechnologies.com</a><br>
> <br>> Support Issue? Email <mailto:<a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a>><br>> <a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a> for fast assistance!<br>
> <br>> <br>> <br>> From: Lelio Fulgenzi [ <mailto:<a href="mailto:lelio@uoguelph.ca">lelio@uoguelph.ca</a>> mailto:<a href="mailto:lelio@uoguelph.ca">lelio@uoguelph.ca</a>] <br>> Sent: Wednesday, June 29, 2011 9:43 PM<br>
> To: Matthew Loraditch<br>> Cc: <mailto:<a href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>> <a href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>;<br>> <mailto:<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
> Subject: Re: [cisco-voip] Phones Not Getting Auth, Idle, Services URLS, etc<br>> <br>> <br>> <br>> Try the service parameter I mentioned. <br>> <br>> <br>> <br>> If you do a search on the archives, Wes posted a link to the doc bug. <br>
> <br>> Sent from my iPhone<br>> <br>> <br>> On Jun 29, 2011, at 9:31 PM, Matthew Loraditch<br>> <<a href="mailto:MLoraditch@heliontechnologies.com">MLoraditch@heliontechnologies.com</a>> wrote:<br>
> <br>> 7942s and 7945s so far, in re someone else's email have restarted tftp etc<br>> already.<br>> <br>> <br>> <br>> <br>> <br>> Matthew Loraditch, CCVP, CCNA, CCDA<br>> 1965 Greenspring Drive<br>
> <br>> Timonium, MD 21093 <br>> <mailto:<a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a>> <a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a><br>
> (p) <tel:%28410%29%20252-8830> (410) 252-8830<br>> (F) <tel:%28443%29%20541-1593> (443) 541-1593<br>> <br>> Visit us at <<a href="http://www.heliontechnologies.com/">http://www.heliontechnologies.com/</a>> <a href="http://www.heliontechnologies.com">www.heliontechnologies.com</a><br>
> <br>> Support Issue? Email <mailto:<a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a>><br>> <a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a> for fast assistance!<br>
> <br>> <br>> <br>> From: Lelio Fulgenzi <mailto:[mailto:<a href="mailto:lelio@uoguelph.ca">lelio@uoguelph.ca</a>]><br>> [mailto:<a href="mailto:lelio@uoguelph.ca">lelio@uoguelph.ca</a>] <br>> Sent: Wednesday, June 29, 2011 7:50 PM<br>
> To: Matthew Loraditch<br>> Cc: <mailto:<a href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>> <a href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>;<br>> <mailto:<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
> Subject: Re: [cisco-voip] Phones Not Getting Auth, Idle, Services URLS, etc<br>> <br>> <br>> <br>> Are these 7941/61? I had a problem where I had to change the service<br>> provisioning service parameter to external to make this work. <br>
> <br>> Sent from my iPhone<br>> <br>> <br>> On Jun 29, 2011, at 6:23 PM, Matthew Loraditch<br>> <<a href="mailto:MLoraditch@heliontechnologies.com">MLoraditch@heliontechnologies.com</a>> wrote:<br>
> <br>> Googled and found that and it's not working..<br>> <br>> <br>> <br>> <br>> <br>> <br>> Matthew Loraditch, CCVP, CCNA, CCDA<br>> 1965 Greenspring Drive<br>> <br>> Timonium, MD 21093<br>
> <br>> <a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a><br>> (p) (410) 252-8830 <tel:%28410%29%20252-8830> <br>> (F) (443) 541-1593 <tel:%28443%29%20541-1593> <br>
> <br>> Visit us at <a href="http://www.heliontechnologies.com">www.heliontechnologies.com</a><br>> <br>> Support Issue? Email <a href="mailto:support@heliontechnologies.com">support@heliontechnologies.com</a><br>
> for fast assistance!<br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> <br>> From: Wes Sisk<br>> [mailto:<a href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>] <br>> Sent: Wednesday, June 29, 2011 5:24 PM<br>
> To: Matthew Loraditch<br>> Cc: <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>> Subject: Re: [cisco-voip] Phones Not Getting Auth, Idle, Services URLS, etc<br>> <br>> <br>> <br>
> <br>> <br>> These lines pretty much say it all. verification of the downloaded file<br>> failed. Delete the CTL/ITL from the phone and try again.<br>> <a href="https://supportforums.cisco.com/docs/DOC-15799#Manual_ITL_Delete">https://supportforums.cisco.com/docs/DOC-15799#Manual_ITL_Delete</a><br>
> <br>> Regards,<br>> Wes<br>> <br>> On 6/29/2011 5:03 PM, Matthew Loraditch wrote: <br>> <br>> 1715: ERR 16:59:35.170584 SECD: EROR:verifyFile: sgn verify file failed<br>> </usr/ram/SEP00260BD749E9.cnf.xml>, errclass 8, errcode 19 (signer<br>
> not in CTL)<br>> <br>> 1716: ERR 16:59:35.171327 SECD: EROR:verifyFile: verify FAILED,<br>> </usr/ram/SEP00260BD749E9.cnf.xml><br>> <br>> Sent from my Android phone using TouchDown (<a href="http://www.nitrodesk.com">www.nitrodesk.com</a>) <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">https://puck.nether.net/mailman/listinfo/cisco-voip</a><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">https://puck.nether.net/mailman/listinfo/cisco-voip</a><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">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
> <br>> <br>> <br>> ************************************<br>> This email may contain privileged and/or confidential information that is<br>> intended solely for the use of the addressee. If you are not the intended<br>
> recipient or entity, you are strictly prohibited from disclosing, copying,<br>> distributing or using any of the information contained in the transmission.<br>> If you received this communication in error, please contact the sender<br>
> immediately and destroy the material in its entirety, whether electronic or<br>> hard copy. This communication may contain nonpublic personal information<br>> about consumers subject to the restrictions of the Gramm-Leach-Bliley Act<br>
> and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or<br>> disclose such information for any purpose other than to provide the services<br>> for which you are receiving the information.<br>> There are risks associated with the use of electronic transmission. The<br>
> sender of this information does not control the method of transmittal or<br>> service providers and assumes no duty or obligation for the security,<br>> receipt, or third party interception of this transmission.<br>
> ************************************<br>> <br></div>