I am using a self signed certificate for the development of an Open Layers 3 implementation.
OL3 is reading layers from a Geoserver using https://localhost:8443, and the website is being hosted at https://localhost:444. I am using Apache and Tomcat 7 for this.
This all works fine in Firefox. Though I get the initial warning about the certificate. But accepting the risk it then connects via https with no problem, and all of the content is delivered correctly.
In Chrome and IE however I am getting the following error in the console and the site isn't receiving content from the Geoserver:
https://localhost:8443/geoserver/
Failed to load resource: net::ERR_INSECURE_RESPONSE
This is associated with port 8443 which is what Tomcat is using to deliver Open Layers 3 content.
It turned out the reason is that Chrome and IE use a certificate store which it checks against to validate the certificate where as Firefox doesn't. You have to assign your self signed certificate to the certificate store for it to allow any data to be transferred through to the client in IE and Chrome.
In IE you can left click on the certificate error -> View Certificates -> Install Certificate, and then install the certificate in Trusted Root Certification Authorities Folder. Refresh and it worked for me.
Related
Setup:
I have an ESP32 running a HTTPs-Server with a self-signed certificate. It provides status information about some homeautomation-devices.
Now I built a Vue-based PWA that is served from a public HTTPs-Server with a regular certificate.
The PWA requests data from the ESP in the local network via https://192.168...
After installing the PWA on my mobile device, Chrome warns me that my PWA accesses content from an untrusted-cert https (which is perfectly reasonable for me).
As a workaround I have to do the following (only once): Access https://192.168... in Chrome, where I get the warning for 'NET::ERR_CERT_AUTHORITY_INVALID' and allow this untrusted access.
After this workaround the PWA works great with the ESP32 even after restarting and updating it.
I want to use the PeriodicSync-API to get the status from my ESP32 once a day and show a notification on my mobile device if something's not ok.
I setup the service-worker to listen for the periodicsync-event and then fetch() data from the ESP32 via https.
Problem:
This works correctly if I connect to my device via chrome://inspect/#devices and simulate the 'periodicsync'-event.
But if I leave the app alone for 12-24 hours and the regular periodicsync-event is finally triggered then fetch(...) catches an error with the following reason: TypeError: Failed to fetch
My guess (after spending many hours on that issue) is that this error relates to the untrusted certificate. It seems that chrome remembers that I agreed on the unsafe access as long as the PWA is open but it does not adopt this agreement for the service-worker.
Question:
Any ideas how to trust a self-signed-certificate in the service-worker or tell the service worker it should use the same permission as the PWA?
A no-go is:
starting browser with certain flags
using a paid long-term-certificate on the ESP32
Many modern Web APIs are gated by the browser to be HTTPS only. This is good for users but can make developing painful. During development I'd like to be able to turn off that requirement just for testing.
Is there a flag I can set (about:config in firefox, about:flags in chrome) or a command line parameter I can pass in to turn off that requirement so I can test without having to setup https certs and add them to the browser?
Note: I understand the https requirement is dropped for localhost but I'm often hosting on one machine (like a laptop) and testing on another (like an Android device) or a different desktop. I know I can generate a local cert and run a server that supports https. I then have to deal with security warnings on the browsers (invalid cert) and/or add the private certs to all the devices OR I have to register a domain solely for the purpose of getting a valid cert via letsencrypt. For my own dev I'd just like to temporarily turn off that check in the browser if possible. Of course what I actually serve to users will be https but during dev if I could turn off that requirement things would be so much easier.
In my particular case I'm trying to use WebXR so dev happens on my laptop but actual testing happens on an Android device where the page is served from my laptop.
One solution suggested here is to use Chrome's port forwarding
https://developers.google.com/web/tools/chrome-devtools/remote-debugging/local-server
That works for Chrome desktop to Android
On your desktop you tell desktop chrome what site at what port to forward to your android device at another port. That site can be a server on the internet or a server running locally on your desktop. On the android device you can then access that site at http://localhost:<port-you-specified>. https requirements are dropped for locahost host so you can now use the APIs that were restricted otherwise.
Chrome has a developer setting Insecure origins treated as secure in chrome://flags/, this is a text field where you can add a list of origins treated as secure for development purposes. (Via https://github.com/immersive-web/webxr/issues/60)
I have a Win Store App app which uses REST to communicate with a pinpad device attached by USB. It has it's own proprietary http server/software but it seems fairly simple.
In my dev machine and on my test machine all works as expected. However, on my tester's machine it does not. The issue is that the xhr GET is failing. It just times out and returns status 0.
A simple get using a browser is successful, as is a script run in a browser (ie, ff, ch).
I have swapped out xhr for httpClient, jquery.ajax and a direct XMLhttpRequest call - all have the same result. I have tried setting location header for CORS. Tried different formats for the address (localhost, 127.0.0.1, 192... etc). The app will happily get external content (eg google.com).
Has anyone come across something like this before? I suspect it's something to do with how a Windows Store App interacts with the lan but I don't know where else to look.
By default Windows Store apps are blocked from loopback connections to localhost. By default, Visual Studio sets up an exception when debugging and you can set one up yourself for testing or for side-loaded apps with the checknetisolation tool. If your app will be deployed from the store it cannot rely on a loopback exemption.
See Using network loopback in side-loaded Windows Store apps on MSDN:
To add a Windows Store app to the list of apps that are exempt from
the loopback firewall, run checknetisolation loopbackexempt -a
-n=<package family name> from an elevated command prompt. The package family name for a Windows Store app is available from Visual Studio
via the Package.appxmanifest editor on the packaging tab.
I have created Lync Presence and successfully integrated in my SharePoint site. And its works file in my environment.
When i have deployed solution to production server it shows error in namectrl.ShowOOUI method.
Permission denied
Error looks like this. And also not work in Firefox in production which also works in my environment
After working on issue finally i found solution that i am accessing production site from different domain then production domain thats why i got this error.
Everything works great if we add the domain on IE to trusted sites.
IE requires that the domain be added to trusted sites.
To add domain in trusted sites.
IE settings > Internet Options > Security tab,
add your SharePoint site to trusted sites and uncheck protected mode.
One workaround is to host the Silverlight application on a server that users have access to. Then you only need trust that server.
Reference
I followed the tabrisjs tutorial instructions to the letter when I get to this part
In the URL tab of the developer app, enter:
http://(development-machine-ip-address):8080/
I do as it instructs and I get the following error
Could not establish connection
Could not open file: http://(ipaddress):8080/package.json
How do I go about figuring out why it cannot find the file?
I am on the same network as my development laptop with the android device , so that shouldn't be the problem.
here is the link:
https://tabrisjs.com/documentation/0.9/getting-started
Open a browser on the device and point it to the package.json URL the developer client complains about (http://(ipaddress):8080/package.json). If the browser can open the file, but the developer client still complains, then this is a bug and should be reported in the tabris.js issue tracker. If the browser cannot open this file, the problem is on the server side.
One common reason is that http-server has been started in another directory.
Another common problem is that there is already a server running on port 8080. In this case, http-server would open on the next available port, e.g. 8081.
In my case I found that this was down to my firewall, AVG, blocking the connection attempt. The solution
From Menu->Settings->Components choose Firewall
Choose Network profiles
For your current network adaptor change the profile to private (you have to establish whether this is a safe thing to do)
Back on the Policies page check Allow all connections with friends in private mode
With other firewall software you will have to find out just how you allow access to that port from other devices on the same network
This is a bit old but, for anyone else who runs into the problem, I was able to fix it on Android M (S7Edge) by exiting the server (CTRL+C) then force stopping the developer app and removing all its data. After restarting the app and the server, everything worked fine.
I seemed to have caused the problem by trying to connect while the server was running in a directory which did not have a Tabris application. I accidentally miss-typed the directory name on the CD command and didn't notice until I started trying to figure out why it wasn't working.
After stopping the server and restarting it in the correct directory, the file could be opened from a web browser but the developer app still seemed to be using the old (incorrect) location. This issue persisted even after rebooting the computer.