Switching to Workplace TLS SIP 1

[Fr0gg3r - MaartenS]

Hi all,
After searching the web for a few weeks I still haven't found a way to fix my problem.

I need to make the switch to SIP TLS to get SSO running for Workplace.
But I just can't seem to get the SIP TLS working on Workplace for newly installed workplace clients.
No issue with the already installed workplace clients.

Setup:
- SE IPO R11.1FP2SP2
- Installed a 3rd party CA domain certificate.
- 5 x Workplace running, using HTTPS (with the domain certificate).

communication is working fine, users are logged in, no errors or problems​

- a few J1xx serie phones.

All is working fine using TCP port 5080.
I'm not yet looking at remote working, just want to get it to work internally first.

I don't want to use TLS on the Jseries, create a 46xxspecials with siptcontroller= IP:5080 tcp
-> works good.

So: I enable TLS for port 5081 in the configuration of the IPO, after a reboot TLS is active.

The workplace still runs on TCP 5080. All good.​

I checked the autgenerated 46xxsettings file: SET SIP_CONTROLLER_LIST xxx.xxx.xxx.xxx:5081;transport=tls -> GOOD​

As a test I manually edit the configuration of the Workplace client and set it to TLS port 5081
-> logout/login -> PREFECT it is running on TLS now !
-> I see in Sysmon + SSA that the client is using TLS. Wireshark SIP is now not readable anymore, just TLS packets.

Now the issue:
I reset that Workplace client 'reset application':
Configure it via e-mail address -> it gets the 46xxsettings file -> I enter login credentials.
-> does not work.
-> the client is now not even able to connect the HTTPS(no green marker for presence), SIP not logged in on IPO.

trace of sysmon:

pcap of Workplace for HTTPS port 411:
I'm byfar an expert in this matter, but is does seems to be the correct workflow.

pcap of Workplace for SIP TLS:
Now this is something else, for me it looks like the TLS is being setup and terminated without any encrypted data going between the client and server ...

If anyone can help me out here.
[tt][/tt]
thanks.

 

[Fr0gg3r - MaartenS]

I just got it all working. After comparing the 46xxsettings of various setups I found out the following:

When enabling TLS and TCP the autogenerated 46xxsettings looks like this:
# SIPXAUTOGENERATEDSETTINGS
SET TLSSRVRID 1

# STIMULUSPHONECOMMONSETTINGS
SET AUTH 1

--> With these parameters the SIP TLS does not work.

If both are manually changed to 0 then the SIP TLS works.
# SIPXAUTOGENERATEDSETTINGS
SET TLSSRVRID 0

# STIMULUSPHONECOMMONSETTINGS
SET AUTH 0

Anyone know why this is??

So now I have a non-autogenerated 46xxsettingsfile which I don't like...

New issue:
When using the Nouser codes for RW_SBC_TLS , RW_SBC_REB , RW_SBC_PROV are enabled the system changes the autogenerated 46xxsettings file when accessed from the internet.
Because I have to change some parameters in the 46xx file the system will not change the manually created 46xxsettings.
What now ?

Is the Workplace client compatible with 46xxspecials.txt?

 

[IP Office Tech]

Is the Workplace client compatible with 46xxspecials.txt?
“IX Workplace 3.24 introduced support for IP Office 46xxSpecials.txt parsing however it fails when parsing dynamic 46xxsettings.txt but succeeds for the same 46xxsettings.txt as a static file, defeating the purpose of using 46xxspecials.txt Design has intended to included IP Office capability to assist Workplace in providing 46xxspecials through autogenerated 46xxsettings from version 11.2.”

Document is here but doesn't explain why or when it will be fixed

https://documentation.avaya.com/en-US/bundle/IPOfficeSIPPhoneInstall/page/46xxspecials_txt.html

# SIPXAUTOGENERATEDSETTINGS
SET TLSSRVRID 0
I have tried this often allows TLS protocol but ignores ID cert if it's incorrect/no available.

# STIMULUSPHONECOMMONSETTINGS
SET AUTH 0
I haven't used this one

- IP Office Tech

 

[sizbut]

Well whoever wrote that quoted text didn't believe in simple clear English.

Basically the IP Office doesn't add GET 46xxspecials.txt to the auto-generated settings file when the file is requested by Workspace, because it knows that Workspace doesn't support chaining files. Except the Workspace team then went and changed that and IP Office hasn't caught up yet. It's currently slated for the next 11.1 service pack which is hopefully January.

Using TLSSRVID 0 to make it work suggests the problem is in the certificate.

Stuck in a never ending cycle of file copying.