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!

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

TLS TLS TLS Remote Worker

Status
Not open for further replies.
Nov 22, 2013
600
US
Hi All.

Implementing IX Workplace / Remote Worker.

I have Remote Worker configured using IX Workplace over a SBC.
On Network I have Jseries SIP phones using TCP for their configuration and connection. No certs installed on the phones.

To utilize remote worker, I need to have TLS enabled for Listen ports in session manager. The problem is, now I will have both TCP and TLS set as listen ports, and I think the Jeries phones will see TLS now enabled and prefer to use TLS instead of TCP. Which would mean I need the certs on all the Jseries phones and certificate maintenance of some sort for this customer.

Does anyone have any documentation on Jseries and what happens when TLS listen ports are enabled in SM? I read something a while back but cannot find it again. Or any information in general would be good too.




 
Whatever CA signed the SM cert - presumably the SMGR CA - put that in your 46xxsettings file under SET TRUSTCERTS
 
The issue I am running into is, when enabling TLS listen port on Session Manager SIP entity for that particular Session Manager, the Jseries phones now prefer TLS over TCP and try to connect TLS, I have customers with 2k+ SIP endpoints over J-series phones using TCP with no Cert installed. When this happens the phones will lose registration and not be able to get back on the network to register since they do not have a cert installed via 46xxsettings.txt. The fix was to turn TLS listen port off and reboot from the PoE level on the switches.

Adding certs to the phones for some customers adds the now needed certificate maintenance as well as a slight re-design, since using IX on the outside requires TLS this forces the need for TLS on the inside as well as media-encryption license, TLS signaling groups, etc...

What I was really looking for was documentation on what enabling "TLS Listen Ports Enabled" on session manager does to sip phones in particular J-series. I did find some documentation for 96xx series phones.

When communicating with a controller delivered by PPM, the phone uses the most secure/reliable transport supported by that controller. The controllers delivered by PPM are ignored if the
ENABLE_PPM_SOURCED_SIPPROXYSRVR parameter value is 0

So from what I found, This basically means that if TLS is enabled the phone will prefer to use it, even if the certs are not installed. But if I set this settings to 0, the phones will ignore that rule and continue using TCP as intended. I think. I have not tested this yet.






 
derfloh, I think you are missing the problem. Or I am not understanding what you mean.

From IX worker (outside) to SBC is TLS currently, from the SBC to Session Manager is TCP. From Session Manager to SIP endpoints is TCP, having the SIP endpoints as TCP is the problem. When I enable Listen to TLS on session manager the SIP endpoints (in this case Jseries sip phones) try to use the highest most secure available protocol which would then be TLS since it is now enabled as well as TCP on the listen ports. Since the phones do not have the certs installed on them, I would need to install the cert on all the phones via the 46xxsettings / aads server. The customer may not want TCP on the phones since it requires certs to be installed and maintenance to all the phones after that for cert maintenance. I think the way around it is to use the setting I stated earlier to force the phones to use TCP even though TLS is listening on the SM interface. I have not tested this yet nor can I find any documentation explaining this.







 
add the trustcert line and use TLS everywhere.
 
I would love to just use TLS everywhere, it is just getting to that point. I need to verify if I NEED to add certs to phones (which is a maintenance window and reboot of phones to get the new cert that the customer was not ready for) or if I can avoid it in someway, then present the options to my customers. I am fairly certain I need to have certs on the phones to reduce any unforeseen issues of using both TCP and TLS at the same time, but that adds certificate maintenance that some customers are not ready for, which would mean the vendor would be responsible for.

 
Well, if you're using SMGR certs, it's CA cert is good for like a decade. If you're using GoDaddy or whoever, their CA cert should be the same, so that SET TRUSTCERTS line would sort them out for a long time.

If you're using Workplace, you're going to want public certs so iPhones and stuff work easy.

If you're going to have iPhones and laptops, they'll eventually come into the office. So, either they should go through the SBC internally to use that public happy cert, or you should use public certs on SM, PS, AADS and any other interfaces those laptops would touch directly when in the office and not thru the SBC.

Here's what I'd do - generate a key/csr with many subject alternative names - yoursm1-sm100.company.com, yourpresencecluster.com, yourpresence1-sm100, yourpresence2-sm100, etc.

You can then apply that identity cert to the outside of the SBCs and on the SM100s of SM and Breeze and AADS. Then you wrap up the CA cert in your SET TRUSTCERTS line and make sure J's work inside and go with it. They'll have to cough up a few bucks every year to renew it and they would need you to apply it to the interfaces. Once the design and approach is solid, it's not much longer to a patch/maintenance window they should be doing every year anyway.
 
I am also working on an avaya sip remote worker project. Does anyone know if SIP Alg needs to be disabled on the end users home network (modem/router) if you are using tls and srtp?
 
Hi kyle555,

any good practice or easy way to distribute certificates to mobile client workplace? our deployment only SMGR as CA. Thanks
 
Put public certs on the outside interfaces.

Otherwise fight with iOS 12,13,14 to go deep and change stuff to let it use a private CA like SMGR
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top