Unable to retrieve spec for http://<CUCM IP Address Here>/inbox/gadgets/msg/msg-gadget.xml. HTTP error 504

[Justin Westover]

I am getting this error when I attempt to use the unity connection web inbox. Does anyone know a solution for this or perhaps an article on a fix? I have look around but I can't seem to find anything so any help would be appricated.

[Dandelion13]

I have the same issue but only when putting the Web Inbox location through our F5 Load Balancer.  I have it pretty much straight through but nothing works.  Now if I take that error message and plug it into the Brower it returns the appropriate mailbox info.  Just has something to do with the way the mailbox iframe loads. 

[Justin Westover]

Did you try browsing to the site using only the ip address followed up by inbox? So an example would be https://10.10.10.10/inbox

Where 10.10.10.10 is the ip address of your cucm server.

Let me know your results after you try this.

Sent from Cisco Technical Support iPhone App

[Dandelion13]

If I go directly to Unity Connection, bypassing the F5, then I am able to connect without getting the 504 error mentioned above.

[martin.janes]

I have the same issue, but it only occurs when I access the Inbox via a public IP address or a server name URL such as https://..com/inbox via Safari or Firefox. If accessed via Internet Explorer 9, I get a different error message "The website cannot display the page - HTTP error 500" for the Messages section of the page.

When I connect via the https:///inbox I do not get the problem and the Web Inbox opens correctly (in Safari, Firefox and IE9). The Unity server is not configured with the FQDN that I want use as the URL, but instead with a style name.

Does anyone have a solution to this that allows the Web Inbox to open correctly when accessed via a to-Unity-unknown URL or IP address?

Unity Connection 8.5.1

[Justin Westover · Accepted solution]

We use a reverse proxy to fulfill out external access needs. The external URL matches the internal fqdn. The problem is that unity must be matching on the host header and comparing that to the fqdn configured and if it doesn't match then that is when we got the error. I fixed our original problem by fixing the fqdn on the unity server.

The reverse proxy could definitely solve your problem though. We use microsoft tmg but there are others out there. You just need to make sure the URL passed to the unity server matches the fqdn that is configured. I am not aware of a way around this.

Sent from Cisco Technical Support iPhone App

[Sam Hall]

Using Cisco Unity Connection version: 10.5.1.11900-13 and it does appear to work if you access the virtual server via IP address instead of a hostname, you then need an SSL certificate for the IP address (so it must be a public IP address allocated to your organisation, otherwise no one will issue the cert). You can then happily load balance the Web Inbox service without having to change any hostnames.

Use of an IP address could be hidden inside an iFrame, but you have to amend or remove the X-Frame-Options header or browsers will reject it.

An iRule like this works, but will reduce protection against clickjacking in browsers that don't support  the "ALLOW-FROM" option as yet:

when HTTP_RESPONSE priority 500 {
   HTTP::header replace X-Frame-Options "ALLOW-FROM https://voicemail-iframe.myorg.com";
}

[Sam Hall]

Upon further investigation it appears that the backend server simply needs to be able to hit port 80 on the forward facing virtual server, simple as that. Otherwise, it either fails with an inline HTTP 500 error message or may use what appears to be a locally cached version of "/inbox/gadgets/msg/msg-gadget.xml". In the latter case, hard coded host names don't match and anti-XSS browser features will prevent the inbox from loading.

In our environment, there appears to a HTTP request to "/inbox/gadgets/ifr" which sends a url parameter that doesn't use HTTPS. This parameter seems to be used by the server to access the contents of msg-gadget.xml which it then renders in the iframe. There are obvious MITM security implications to this that need to be taken into account if there is an untrusted network separating the load balancer and the backend servers.

[benoit.moinet]

Hello Sam,

We're facing the same issue with a CUC in 10.5.2 and F5 VIP.

Could you explain more how you solve your problem ?

Agree that it's definitely a security problem to use http request in a SSL session...

Thanks in advance,

Benoit

[Sam Hall]

I tracked the hard coded http reference to /inbox/wro/msg-gadget.js

I uploaded a fixed version of that file to the F5 as an iFile and then intercept any requests for it, replacing it with my version.

[benoit.moinet]

Thanks Sam,

In fact, we finally make it work by opening the http port between CUC and F5. And let the VIP being resolved in http.

Like you said, the "shitty" javascript code try to resolve its name by sending again a request with a http request... Even if the session was in SSL. This is security...

So the name resolved, should get the good IP of the server handling the request. That's why it's better to configure the VIP in failover.

[Sam Hall]

I've just had another look at my configuration. We're doing SSL Bridging (forget about trying to get SSL Offload working) also permitting port 80 traffic from the CUC server(s) to go through via the back end (port 443). That's like reverse SSL offloading! Otherwise you get those 500 errors from memory.

I asked the appliance administrator to add a local hosts entry pointing the VIP host name to 127.0.0.1, but apparently he doesn't have the access to do that. This is by far the most troublesome application I've had to configure because the appliance is all locked down, or so I'm told. You can't configure it to play nice at all.

The other issues I had in my initial, rather misguided post were caused because the appliance must be able to resolve the hostname used by the client to the F5 VIP. To confuse matters, it will also cache the initial DNS resolution for quite a while (which is why it only seemed to work for me via IP address).

So, due to the fact nobody is able to configure the appliance hosts file, I have some logic permitting what would normally be "loopback" type requests on port 80 to go through the F5. All other port 80 requests get a redirect. I have no idea how people safely load balance this service without the magic of F5.