Re: HTTPS issue with MSE Notifications

hody.crouch · ‎11-21-2016

I am attempting to receive notifications from msesandbox.cisco.com for Location Updates. When I use a http receiver, everything works as expected. When I use a https receiver, I receive the same data, but the host header does not appear to be set correctly.

Here are a couple of lines from the server log comparing http and https notifications:

2016-11-21T16:13:46.022073Z srv1 56.25.132.87:55141 10.1.1.18:80 0.000015 0.114811 0.000034 200 200 604 0 "POST http://myserver.mydomain.com:80/path/mse HTTP/1.1" "Jetty/9.1.5.v20140505" - -

2016-11-21T16:14:06.407054Z srv1 56.25.132.87:43660 10.1.1.18:81 0.000017 0.043643 0.00002 404 404 595 58 "POST https://mse10:443/path/mse HTTP/1.1" "Jetty/9.1.5.v20140505" ECDHE-RSA-AES128-SHA256 TLSv1.2

The 404 status occurs because the host information is invalid (notice the "mse10:443")

Did I miss something in the configuration?

matfarre · ‎11-21-2016

Hi Hody,

The CMX sandbox urls are https://msesandbox.cisco.com for MSE 8.0 and https://msesandbox.cisco.com:8081 for CMX 10.2. Let us know if this resolves the issue.

curl --request GET \

--url https://msesandbox.cisco.com/api/contextaware/v1/location/clients \

--header 'authorization: Basic bGVhcm5pbmc6bGVhcm5pbmc=' \

--header 'cache-control: no-cache' \

--header 'content-type: application/json' \

--header 'postman-token: 91de8083-2731-b348-ae3e-26ce2a4c1378'

curl --request GET \

--url https://msesandbox.cisco.com:8081/api/location/v2/clients \

--header 'accept: application/json' \

--header 'authorization: Basic YWRtaW46Q2lzY28xMjM0NSE=' \

--header 'cache-control: no-cache' \

--header 'postman-token: d0ca3817-9a1c-c47d-f090-cabc004bc940'

Thanks,

Matt

hody.crouch · ‎11-21-2016

Sorry if I wasn't clear enough.

I don't have any problem configuring the notification.

When the notification is sent to my server via https, the request does not appear to contain the correct host information for the receiver.

When the notification is sent via http, the request does contain the correct host information.

matfarre · ‎11-22-2016

Hi,

The following url is CMX 10.2.3 DevNet sandbox, by coincidence mse10 is also the hostname for the CMX 10.2.3 DevNet sandbox on a private network resolving to 10.10.20.152. Hope that helps.

Matt

https://msesandbox.cisco.com:8081/login/

The connection to this site is encrypted and authenticated using a strong protocol (TLS 1.2), a strong key exchange (ECDHE_RSA), and a strong cipher (AES_256_GCM).

$ nslookup mse10.cisco.com <--- not sure who owns this CMX server

mse10.cisco.com canonical name = svl-prime-mse10-1.cisco.com.

Name: svl-prime-mse10-1.cisco.com

Address: 10.29.98.242

$ nslookup msesandbox.cisco.com <--- DevNet sandbox server hostname for CMX 10.2.3 and CMX 8.0, see my previous reply.

Name: msesandbox.cisco.com

Address: 64.103.26.61

From CMX UI System Settings under Node Details

Node ID	mse10
IP Address	10.10.20.152
Hostname	mse10
System Time	Tue Nov 22 18:40:49 GMT 2016

hody.crouch · ‎11-22-2016

I wonder if the underlying issue is the version of Jetty being used by this MSE environment to send notifications.

The User-Agent header shows Jetty 9.1.5.

Jetty added support for Server Name Identification (SNI) on TLS connections in version 9.3 in 2015.

I'm testing with the CMX 10.2 sandbox. I was surprised to see the older version of Jetty still in use. I don't know for sure that the lack of SNI support would cause the behavior, but it's a real possibility.