SPA303 problem with https XML Applications

[consultingroupitaly]

I'm trying to load a simple xml from https://192.168.1.21/test/menu.xml and it doesn't work.

If I load the same url from http it does work, what is the problem with https?

PS: Syslog is attached

PS2: More info here.

[Iliya Gatsev]

Hi, 
My name is Iliya Gatsev from Cisco Technical Support Team.

For sure it works using HTTP.

I think it would be best if you could call our support line and open a support case so we can investigate this issue.

https://www.cisco.com/c/en/us/support/web/tsd-cisco-small-business-support-center-contacts.html

Iliya Gatsev
Cisco STAC Network Engineer
Together we are the human network .:|:.:|:. CISCO

[Dan Lukes]

Glad to hear the SMB SC is responding here.

But I dont understand why anyone should call SC to repeat things already written here - and read and understood by member of Cisco Technical Support Team. 

[Iliya Gatsev]

Hi Dan, 

In case that this is some kind of bug it can be tracked only if there is existing service request. ( support case)

It's just another idea!

Iliya Gatsev
Cisco STAC Network Engineer
Together we are the human network .:|:.:|:. CISCO

[consultingroupitaly]

Sorry I'm busy, I don't have time for a call.

I prefer to sort these things out in writing.

Isn't this the proper place?

[Iliya Gatsev]

Hi, 

Cisco Support Community is great place where you can discuss this topic and everybody could help you here.

Iliya Gatsev
Cisco STAC Network Engineer
Together we are the human network .:|:.:|:. CISCO

[Dan Lukes]

It's very unfortunate it's not enough the Cisco is aware of bug in it's software and require it will be reported by someone else instead. It says - we don't care quality by self, we act only if we can\t withstand customer complains ...

It's not so good for the overall user experience as well as for Cisco's reputation. Well, not my business.
 

By the way, the reported behavior is not bug - it's intentional (if I remember correctly). Sad to say, once Linksys division has been destroyed, no developers are willing to speak with customers and enthusiasts anymore, .

[consultingroupitaly]

The server (Apache server, internal in the LAN) use an https certificate signed with a self signed root CA (installed in the server), and the certificate is pulled from the phone with normal http using the "Custom CA RULE" setting.
I'm not sure if it is related to the problem.

If someone has some ideas please tell me.

[Dan Lukes]

Can you disclose the certificate used ? Certificate itself is not secret nor sensitive. I'm most interested in 'Subject' attribute used in it.

[consultingroupitaly]

The forum doesn't allow me to upload certs.

The main server cert and the CA (installed as root cert in the server) are here: https://ufile.io/d1oxi

[Dan Lukes · Accepted solution]

Forum allow you to upload any file you wish - it only restrict extensions allowed in name. So you need to rename file first to have one of allowed extensions. I attached the certificate here, as the link you provided will expire.

OK, so we have certificate now and I wish I see the issue cause.

You are trying to access https://192.168.1.21/test/menu.xml on server with certificate having Subject 
/C=IT/L=Rimini/O=Consulting Group Italy srl/CN=reception

Yes, you have Subject Alternate Name (SAN) set to DNS Name=reception & IP Address=192.168.1.21 but ...
1. I'm almost sure the IP Address king of SAN is not recognized

2. although I'm unsure, I suspect the SAN extension is ignored at all

So the certificate is valid for computer named "reception" (e.g. https://reception/...) only. Thus it's rejected as spoofed on https://192.168.1.21

My recommendation:

1. configure DNS and create a valid DNS name for 192.168.1.21

2. obtain certificate for /C=IT/L=Rimini/O=Consulting Group Italy srl/CN=<name you elected> and use it on HTTP server

3. use https://<name you elected>/test/menu.xml in phone configuration

OR

give up and use http instead.

I'm encouraging you to solve it "lazy way" for the reason. It seems anyone can fetch the menu.xml - it's just not sensitive and secret and there's no reason to encrypt it. Establishing of SSL connection is computing intensive operation while SPA303 have rather slow CPU. Assuming most common HTTPS configuration, it will take about 2 seconds per request. Users will wait for menu to be shown, and then for every next page required to find a phone number. It's not so good user experience. So sonsider not to use SSL for in-sensitive data at all.

[consultingroupitaly]

I have tried to rename the file but it does say that the content doesn't match the extension.

The menu.xml is only the first page, the other pages contains sensitive data (I have also setup digest authentication in PHP and it works); I'm writing a complex web application.

The LAN is small and doesn't contain a domain or a custom DNS server, the router is the one provided by the telephony company and it doesn't have many options.

"reception" is the computer name and "http://reception" (and https://reception) do work when used from the PCs in the LAN but they aren't working from the phones.

Isn't there any alternative?

[Dan Lukes]

---

it does say that the content doesn't match the extension.

Surprising. I'm doing it all the times and I never seen message you cited.

---

The menu.xml is only the first page, the other pages contains sensitive data

OK, in such case you may consider this article interesting for you.

"reception" is the computer name and "http://reception" (and https://reception) do work when used from the PCs in the LAN but they aren't working from the phones.

May be there's other issue with phone/configuration.

Configure phone to use https://reception/menu.xml, catch syslog&debug (make sure highest debug level is enabled) and, if possible, catch packets between phone and HTTP(s) server as well. 

[consultingroupitaly]

@Dan Lukes

Thanks, I was re-reading your previous message so I have tried to switch the certificate with a one using CN=192.168.1.21 inside Subject, so the phone use Subject while browsers use SAN and now everything work.

@Iliya Gatsev

But I still consider a bug a missing or incomplete support of Subject Alternate Name (SAN) since nowadays using it is the norm.

Is it possible to support it completely?

Plus the syslog didn't give any indication of a rejected certificate making it useless in this case.

Is it possible to improve it?

[Dan Lukes]

Note I'm unsure the SAN is not supported. I'm sure the IP Address kind of attribute is not supported. It may work with CN=reception and DNS Name=192.168.1.21 attribute appended to SAN.

Consider to try.

Also note that unnamed computers referred by IP only are not expected by casual SSL implementation. Not only SPA303 may cease to work with it. Working DNS is a must for current networks. As DNS server can run on almost any computer and cost nothing (note BIND for Windows), networks with no DNS at all are not supported well by software.