VCS/Expressway X8.8 changes it’s behavior versus prior versions. 8.8 does a reverse lookup of the IP addresses it’s communicating with to make sure it matches the hostname between C and E.
From the Release notes:
Oddly enough, the two systems that I’ve been involved in the upgrade to 8.8.1 with, both had the Unified Communications traversal zone with show Active, and hard phones (8800 and DX 650) will register and work properly, but Jabber clients will be unable to login and Jabber will throw an error when trying to login through MRA:
"Unable to Communicate with Server."
Running the debugging logs on Expressway-C you see the following error:
"Certificate verification failed for host=x.x.x.x, additional info: Invalid Hostname expressway-e.domain.com"
The fix is to make sure that Expressway-C can do a reverse DNS lookup on the IP address of Expressway-E. Then flush the DNS cache of C to make sure it re-queries DNS properly.
The debugging log will give you the address and hostname it is trying to do the lookup on.
In a dual-NIC Expressway-E deployment the PTR recrod should point to the private IP address that C talks to. In a single-NIC NAT hairpin deployment, I’ve seen it talk on the private and public IP. So check that debug log.
After upgrading to 8.8.0 we also had an issue with Jabber and MFT. It appears that the HTTP rules to access https://:7336/files for POST,PUT are not automatically added. However in 8.8.1 it appears that this is fixed.
Thanks for the hint.
Unfortunately there still seems to be an issue with MFT and Expressway X8.8.1 but the workaround is fine.
I think this allow list is case sensitive. Our cups hostname is upper case and the uri from jabber client seems to be lower case.
It seems the automatically added rules adds the URL with /files/ as path. And it should be /files, without the last slash. I had this on the latest X8.9.
Thanks, we had this issue when upgrading from 8.6 to 8.8.1 and could resolve it quickly after finding your post.
I just did an attempt to upgrade from 8.6.0 to 8.8.2 which worked fine for the Exp-C server, but failed horribly with the Exp-E server. The Exp-E came back after the reboot with a “Database read error” and has even reset the admin password back to the default. For whatever reason the IP settings were kept so we were able to access the GUI. We had to roll back the update and will open a TAC case for that.
It can also be resolved running the command via CLI:
xConfiguration XCP TLS Certificate CVS EnableCvs: Off
Cheers