Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

9630 SIP

Status
Not open for further replies.
wpetilli

wpetilli

Technical User
Joined
May 17, 2011
Messages
1,877
Location
US
I'm trying to get a 9630G phone flashed w/SIP and registered directly with SM. The phone pulls the FW and in the 46xx file I have the SET TRUSTCERTS to my network CA/SUBCA files. The phone boots up to a username/password and sits there acquiring service. While running a traceSM I see the phone offering a Cert to SM with the AVAYA SIP Procuct CA. Where can I remove reference to that as I think that's what my issue is?
 
Sort by date Sort by votes
it must be trying mutual tls based on some weird 46xxsettings option that applies to 96x0 but not 96x1 sets
 
Upvote 0 Downvote
I set TLSSRVRID to 0 which specifies whether a certificate will be trusted only if the identity of the device from which it is received matches the certificate. 0 does no matching. Not sure if that's what I really want though. Sounds like security will have an issue with that.
 
Upvote 0 Downvote
Na...that isn't it. That's making you trust certs offered to you if you can't validate them. Not why the phone is offering a cert in a handshake
 
Upvote 0 Downvote
That setting is odd.. I set it to 0 and I got the hard phone registered. I noticed in my iOS settings file it was also set to 0. When I changed that to '1' I started failing registrations again. Put it back to 0 and it's good again.
 
Upvote 0 Downvote
well, tlssrvrid 1 would just make the phone match subjectaltname of IP or FQDN of the SM100 the cert is signed for. Youd still need the trustcerts line to import the CA cert to the 9630 so it trusts the CA that issued the cert to SM. You can choose to verify or not verify the cert but you'd still need to trust the CA that issued the cert regardless.
 
Upvote 0 Downvote
Dealing with mobile iOS phones is pretty easy in that we deploy the CA certs via policy and are only allowing company managed devices to use the service. For the remote hardphones just providing them the CA isn't enough. If the user leaves the company, aside from changing the SIP password the endpoint is still useable to try another person's extension. We currently have a SCEP process for the VPN phones. Is that the recommended process for the SIP phones as well? Aside from the certificate being disabled/expired on the internal SCEP server, what is the mechanism to stop that endpoint at the SBC level? I see a section to upload a CRL on the SBC, but that sounds like a new CRL will be required every time a phone needs to be disabled. Is there another way.. macaddress table or something to input into the SBC?
 
Upvote 0 Downvote
And that CRL has to be in the form of a cert file and not via an http request of course.
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

hebegb41
  • Question Question
Converting 1 SIP carrier to another
Replies
1
Views
321
dialtonebone
dialtonebone
lexer
  • Locked
  • Question Question
Avaya phone set 4610SW SIP firmware
Replies
2
Views
436
lexer
lexer
letman2
  • Locked
  • Question Question
EZ500 with sip trunks
Replies
3
Views
633
ZeroZeroOne
ZeroZeroOne
wallot
  • Locked
  • Question Question
One way Audio - Incoming SIP call to 9408
Replies
1
Views
276
dialtonebone
dialtonebone
Alaskatelecom
  • Locked
  • Question Question
SIP J179 and Call Park - not working
Replies
3
Views
623
ZeroZeroOne
ZeroZeroOne

Part and Inventory Search

Sponsor

Back
Top