9630 SIP

[wpetilli]

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?

 

[kyle555]

it must be trying mutual tls based on some weird 46xxsettings option that applies to 96x0 but not 96x1 sets

 

[wpetilli]

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.

 

[kyle555]

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

 

[wpetilli]

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.

 

[kyle555]

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.

 

[wpetilli]

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?

 

[kyle555]

crl only i think. complain!

 

[wpetilli]

And that CRL has to be in the form of a cert file and not via an http request of course.