06-08-2018 03:19 AM - edited 03-21-2019 09:12 AM
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.
Solved! Go to Solution.
06-12-2018 09:11 AM
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.
06-08-2018 07:03 AM
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
06-08-2018 07:14 AM - edited 06-08-2018 10:56 AM
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.
06-08-2018 07:27 AM
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
06-08-2018 07:33 AM
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?
06-08-2018 07:55 AM
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
06-08-2018 02:18 PM
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, .
06-12-2018 12:16 AM - edited 06-12-2018 12:18 AM
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.
06-12-2018 04:28 AM
Can you disclose the certificate used ? Certificate itself is not secret nor sensitive. I'm most interested in 'Subject' attribute used in it.
06-12-2018 06:51 AM
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
06-12-2018 09:11 AM
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.
06-13-2018 12:30 AM - edited 06-13-2018 03:17 AM
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?
06-13-2018 04:46 AM
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.
06-14-2018 04:32 AM - edited 06-14-2018 04:48 AM
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.
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?
06-14-2018 04:48 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide