I have implemented FCM for web using fcm documentation.
Everything'll be fine if I set url like : 'http://xxx' I have no error.
But when I set url : 'https://xxx..', I get error:
"Failed to register a ServiceWorker: An SSL certificate error occurred when fetching the script."
code: "messaging/failed-serviceworker-registration"
"Messaging: We are unable to register the default service worker. Failed to register a ServiceWorker: An SSL certificate error occurred when fetching the script. (messaging/failed-serviceworker-registration)."
Can anyone show me how to fix this error?
This is a general problem when wanting to test service workers in a local development environment without proper SSL certificates. It is not specific to Firebase Messaging but pertains to Service Workers in general.
Here is the solution I found when using Google Chrome: Testing Service workers locally with self-signed certificates
Unfortunately, I don't know yet how to circument the issue with other browsers, but probably there must be similar ways.
For Chrome, you need to start a new instance of Chrome, with some flags telling it to ignore SSL certificate errors for your local origin:
In Linux (and maybe Mac):
google-chrome --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://127.0.0.1 --user-data-dir=/tmp/foo
The https://127.0.0.1 here is the location where your app (and service worker) is hosted locally. You might need to adjust this to use the appropriate port, if serving on a different port than the standard HTTPS port 443, e.g. https://127.0.0.1:3000, when serving your app over HTTPS on port 3000.
The --user-data-dir=/tmp/foo is necessary to start a new instance, with a new user profile, if another instance of Chrome is already running.
In Windows (might vary, depending on where your chrome.exe is):
C:\Program Files (x86)\Google\Chrome\Application\chrome.exe --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://localhost:1123
Again, you might have to adjust the port.
Easier method that worked for me:
Just paste chrome://flags/#allow-insecure-localhost in your chrome browser, and Enable the setting that says something like "Allow invalid certificates for resources loaded from localhost."
Related
I'm new to Progressive Web Apps, and I'm adding a Service Worker to my app for the very first time. It's a simple Service Worker, with my goal being purely to test that it is being registered properly. The file is serviceWorker.js:
console.log('Hello Service Worker');
I'm adding this to an application that I'm running with the Webpack Dev Server. I'm using a self-signed certificate locally with it. I setup the Service Worker in my index.tsx (React Typescript) like this:
if ('serviceWorker' in navigator) {
navigator.serviceWorker
.register('/service-worker.js')
.then(() => console.log('Worker registered'))
.catch((ex) => console.error('Worker registration error', ex));
}
However, when I start the dev server and go to the app, I get an error:
Failed to register a ServiceWorker for scope ('https://localhost:3000/') with script ('https://localhost:3000/service-worker.js'): An SSL certificate error occurred when fetching the script.
The URL, https://localhost:3000/service-worker.js, does indeed work, the browser is just blocking it because of the self-signed piece of the cert.
I'm using Chrome Browser on on M1 Pro MacBook running MacOS Monterey, with Webpack 5.
For the record, I'm aware of plugins like Workbox, I would prefer not to use them at this time because I'm still very new to Service Workers. I believe in working with the low-level constructs when starting with a new tech to understand them better before embracing easier abstractions.
I'm not aware of any features—including service workers—that require HTTPS on localhost.
localhost, and equivalent IP address ranges, are specifically excluded from HTTPS requirements by Chromium-based browsers, and both Firefox and Safari follow that, at least when it comes to service workers.
So I would suggest that you just access your web site via http://localhost:3000 instead.
There are more details in this older answer.
I installed a new fresh Bigbluebutton server on VMware without domain and SSL, after installing bbb-demo when I logged in, it showed an empty blue screen. In the browser console this exception was written:
Uncaught TypeError: Cannot set property 'ondevicechange' of undefined
The last time when I face a similar situation, I try to set a self-signed SSL but it just makes lots of problems and it didn't work.
How I could solve this error?
Finally, I've solved the problem. In this address ffdixon(product manager for BigBlueButton) said:
We need to update the docs -- you must setup an SSL certificate for BigBlueButton or it won't load. If you see "Not Secure" on your browser URL, BigBlueButton will not load.
I didn't have any valid IP or domain for my VM, So I created a valid SSL with one other domain(not belong to my VMware) and setup bbb to use SSL based on this article.Then set /etc/host to redirect SSL domain name to my local IP.
This has been a problem for myself and my colleagues who have also tried this for quite some time (we keep revisiting the issue to try and fix) whereby the process of getting the packages for a flutter app fails. It works perfectly from my home pc but in work it does not.
Running flutter pub get from my cli returns pub get failed (-10737418819). If I append -v to flutter pub get I get much more information which describes the HTTP get it attempts to make which is:
https://pub.dartlang.org/api/packages/cupertino_icons
with an accept header of 'application/vnd.pub.v2+json'
If I then use a tool such as Postman to send a Http Get with this information, it fails and reports that it could be down to:
Self-signed SSL certificates are being blocked:
Fix this by turning off 'SSL certificate verification' in Settings > General
So I turn this setting off and it works as expected, returning JSON data about the cupertino packages. I think the fix to my problem has something to do with SSL certificate verification but I don't know where to start. Does anyone have any idea?
Generally the Issue is from server side as the Website does not has SSL Certificate and you are trying to access with "https".
use the Same URL we "HTTP" it will work
I have Data Virt running via the standalone.sh script, and can log in with my username and password. My next task is configuring it so that it automatically runs whenever the instance is up and running (without having to execute standalone.sh), and uses SSL (port 443) rather than my username and password to log me in. I added the vault.keystore, dv_keystore.jks, and dv_truststore.jks files, and modified both standalone.sh and standalone.xml, according to the JBoss and other online documentation, to account for using these files. I start the standalone.sh script, which runs without any errors. When I browse to:
http://<IP>:8443/dashboard
after starting standalone.sh, I get the following error:
This page can't be displayed
Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to https://:8443 again. If this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4, which is not considered secure. Please contact your site administrator.
The settings Use TLS-1.0-ON, Use TLS-1.1-ON, and Use TLS-1.2-ON are all checked in the Browser properties.
By contrast, when I browse to
http://<IP>:8443/dashboard
when standalone.sh is not running, I get the following:
This page can't be displayed
- Make sure the web address https://:8443 is correct.
- Look for the page with your search engine.
- Refresh the page in a few minutes.
It appears the browser is sensing something going on when standalone.sh is running, but something is not allowing the browser to access the dashboard.
What am I missing here?
Have you validated any other ssl access? Is it just an issue with the dashboard application?
I am trying to monitor https traffic with Fiddler, using current newest version:2.4.4.5
I've successfully set up https, certificates and I can see the full https encrypted traffic for example browsing my bank's web site.
...however...
When I trying to monitor an other server I got this error message in the response window:
"Failed to secure existing connection for 77.87.178.160. A call to SSPI failed, see inner exception. InnerException: System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm"
For full Fiddler window see:
The client is not a in this case browser, but a custom client program, which communicates with its own server.
My question: Is this exception misleading and in reality some other error prevents the secure channel to set up?
...or...
We have still chance to monitor this https communication?
Thx in advance
What is the client program?
This error typically indicates that that client application is only offering certain HTTPS ciphers, and those ciphers are not supported by Fiddler.
However, in this case, the specific problem here is almost certainly this: http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx
The client is trying to use AES with SSLv3, but that isn't one of the valid ciphers for SSL3. As a consequence, the connection fails.
You might be able to workaround this by clicking Rules > Customize Rules. Scroll down to the Main() function and add the following line within the function:
CONFIG.oAcceptedServerHTTPSProtocols =
System.Security.Authentication.SslProtocols.Ssl3;
Please let me know if this works.
NOTE Current versions of Fiddler offer a UI link for this: Look at the lis of enabled protocols on the HTTPS tab.
Unbelievably this issue is still present some 6 years later.
Just installed the latest version of Fiddle (v5.0.20194.41348), and sure enough on Win7 using Chrome or IE it keeps failing with the dreaded error:
"fiddler.network.https> HTTPS handshake to google.com (for #1) failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm"
After some hours of testing, I found a middle ground solution which seems to work with virtually all websites. The aim was to get the highest possible security with no errors in the log. Without needing to add any code, simply changing this line under Tools > Options > HTTPS > Protocols is what worked for me (just copy and paste it):
<client>;ssl3;tls1.1;tls1.2
Basically removed the ssl2 and tls1.0 protocols which leaves us with some pretty decent security and no errors so far. Having spent hours of frustration with this error, hope someone out there might find this useful, and a big thanks to EricLaw who discovered the root of the problem.
Yes I too have seen this error when working outside of fiddler and it was connected with AuthenticateAsServer but only went wrong when using IE10 and not Chrome as the browser.
Odd thing is that it did not break all the time for IE10 using SslProtocols.Tls for the protocol so I will add a bit of code to switch the protocol if one fails
The protocol that can be used also seems to change on if you are using a proxy server like Fiddler or using an invisible server by hijacking the DNS via the hosts file to divert traffic to the server