cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3860
Views
0
Helpful
8
Replies

Registration rejected:Security Error

Robert Lake
Level 1
Level 1

I am currently running a single node Non-secure CUCM 8.6(2a)SU3 environment . This is my test system and when I switched my test phone to another vlan and did a factory reset (to make sure my DHCP settings worked correctly) the phone restored to the system defaults (term62.default) which in my case loads a SIP version of firmware. But then it doesn't pull down the configuration file and throws a TFTP error. When I moved the phone over to the production phone network and did another factory reset (after building the phone in the production CUCM) it upgraded to the device default SCCP firmware as desired. I then put it back on the test VLAN and deleted the CTL file and got the error "Registration rejected:Security Error". It appears that I have some sort of security issue but I am not sure how to resolve it or even verify that assumption..

8 Replies 8

Robert Lake
Level 1
Level 1

I think I  found where to confirm my assumption that the issue is security related. I pulled down the Console logs from the phones' web server and saw these three lines.

9281: NOT 19:14:59.501406 SECD: TVS service not available to validate

9282: ERR 19:14:59.502058 SECD: EROR:verifyFile: sgn verify file failed , errclass 8, errcode 19 (signer not in CTL)

9283: ERR 19:14:59.502989 SECD: EROR:verifyFile: verify FAILED,

Now what?? in the CTL file on the phone the Unified CM / TFTP Server isn't in the FQDN formatt.. Could that be an issue?

Yes your issue is security related. It looks like even after you deleted the CTL file, your phone still has the old CUCM as the TVS. I cant remember the process of erasing CTL off my hand right now, therefore I will suggest that you do another factory reset on the  phone. term62.defaults is not neccesary a sip firmware. There are SCCP version of this too. Is your phone configured in cucm as SCCP or SIP. If it is configured as SCCP, I see no reason why its loading SIP firmware

Please rate all useful posts

"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Please rate all useful posts

I have done a factory reset and it is still loading the term62.default (mine is set to SIP) even though it is built as an sccp phone. I have noticed that the phone is not pulling down an ITL file either.. I looked through the TVS logs and there is no mention of the phone in question and in the TFTP logs I do see the phone regesting and being given then term62.default files.. In the TFTP log I also see it asking for the ITL file, but I am not sure if it is getting it or not..

13:59:47.201 |   TID[a550fb90] HTTPEngine::getRequest(), [0xadb5e10~289~10.102.64.43~51700] socket(5), ReqTimeout[1], Request[GET /ITLSEP10BD18DD4EC2.tlv HTTP/1.1

Host:140.192.228.242:2125620]

13:59:47.201 |   TID[a550fb90] HTTPEngine::getRequest(), [0xadb5e10~289~10.102.64.43~51700] File Requested ITLSEP10BD18DD4EC2.tlv

13:59:47.201 |<--TID[a550fb90] HTTPEngine::getRequest(), [0xadb5e10~289~10.102.64.43~51700]

13:59:47.201 |-->CReqContext::tftp[0xadb5e10~289~10.102.64.43~51700]

13:59:47.201 |CReqContext::CheckAndSetIsStatic(itlsep10bd18dd4ec2.tlv) is (Not a Static) File

13:59:47.201 |CReqContext::isCTLCAPFRequest[ITLSEP10BD18DD4EC2.tlv] Not a CTLCAPF File

13:59:47.201 |   CReqContext::tftp[0xadb5e10~289~10.102.64.43~51700] HandleITL: [ITLSEP10BD18DD4EC2.tlv] is ITLSEPMac.tlv file, Searching[10BD18DD4EC2]

13:59:47.201 |TFTPCache::FindMatching(10BD18DD4EC2), Found[SEP10BD18DD4EC2.cnf.xml.sgn]

13:59:47.201 |   CReqContext::tftp[0xadb5e10~289~10.102.64.43~51700] HandleITL: Match[10BD18DD4EC2] Found, looking for [ITLFile.tlv] to serve

13:59:47.201 |CReqContext::FindAndServe SignFileFlag[0]

13:59:47.201 |CCtftpChangeNotifyServer::HasWaitingEvent(), Empty List or pkid

13:59:47.201 |CReqContext::FindAndServe(1)[0xadb5e10~289~10.102.64.43~51700],[(ITLFile.tlv),(4272),(0xab7f138)] found in config cache

13:59:47.201 |-->CReqContext::serve[0xadb5e10~289~10.102.64.43~51700]

13:59:47.201 |-->CSendBuffer::Init[0xadb5e10~289~10.102.64.43~51700]

13:59:47.201 |<--CSendBuffer::Init[0xadb5e10~289~10.102.64.43~51700]

13:59:47.201 |-->HTTPEngine::sendResponse[0xadb5e10~289~10.102.64.43~51700]

13:59:47.201 |   HTTPEngine::sendResponse[0xadb5e10~289~10.102.64.43~51700] FileName[ITLSEP10BD18DD4EC2.tlv], Version[HTTP/1.1], Size[4272]

13:59:47.201 |   HTTPEngine::sendResponse[0xadb5e10~289~10.102.64.43~51700] [85][HTTP/1.1 200 OK

Content-length: 4272

Cache-Control: no-store

Content-type: */*

Can you see in the trust list menu if you can delete the ITL file?

Gabriel.

When I navigate on the phone (7962) to Settings > Security Configuration > Trust List, the section for ITL File says "Not Installed". I have deleted the CTL many times during my troubleshooting and the ITL file is never reinstalled..

WHat is the firmwar version on the phone at the moment and what is the firmware on your lab's cucm

Please rate all useful posts

"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Please rate all useful posts

The term62.default files are:

jar42sip.9-3-1ES8.sbn

cnu42.9-3-1ES8.sbn

apps42.9-3-1ES8.sbn

dsp42.9-3-1ES8.sbn

cvm42sip.9-3-1ES8.sbn

The device default for the CUCM system is: SCCP42.9-3-1SR1-1S

I am pretty sure its not the bug concerning upgrading from anything before 8.5(1) to anything 8.5(1) or greater. Besides, when I started having this issue I moved the phone into the production system (exact same term62.default file and device default firmware) and the phone was able to upgrade fine. Only when I put it back on the test system do I have the "Registration Rejected: Security Error" message and once I do a Factory reset it reverts back to the SIP code from the term62.default file.

Robert Lake
Level 1
Level 1

Turns out that this was due to an upgrade I had done about 2 months ago from CUCM 8.5 to 8.6. Because this is a test system, the phone configs stay fairly stagnent so I was not aware of the issue. But, after an upgrade it is recommended that the CTL client is re-run and once I did that the problem was resolved..

I have done other upgrades with out this issue arising.. I wonder if it is because of the OS change of the appliance when going to 8.6 from 8.5??