I’m using a service worker with https not https for my angular 4 project. But I get this error :
Service Worker registration failed: DOMException: Failed to register a ServiceWorker: An SSL certificate error occurred when fetching the script.
Here is my service-worker.js
module.exports = {
navigateFallback: '/index.html',
stripPrefix: 'dist',
root: 'dist/',
staticFileGlobs: [
'dist/index.html',
'dist/**.js',
'dist/**.css',
'dist/assets/image/**.*',
'dist/assets/image/client-home-carousel/**.*',
]
};
An in angular-cli.json:
"assets": [
"assets",
"favicon.ico",
"service-worker.js"
],
asked Sep 26, 2017 at 22:33
Service Workers can only be used over an HTTPS connection. Are you using that or not? Also, the HTTPS certificate has to be valid.
As a sidenote, the code you’re showing is not your service-worker.js. That code is some parameters and options to some SW library that then generates your service-worker.js based on those options. Most likely your actual service-worker.js is located in the dist directory and is updated as a part of your build process.
answered Sep 27, 2017 at 5:15
patepate
4,7411 gold badge18 silver badges24 bronze badges
4
So as pate mentioned «Service Workers can only be used over an HTTPS connection»,
and if that specific DomException was happened locally, when accessing web resource at local machine with certificate, one of these latest version of browser launches may had helped:
open -a Opera.app --args --user-data-dir=/tmp/foo --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://localhost:8111
open -a Brave Browser.app --args --user-data-dir=/tmp/foo --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://localhost:8111
open -a Google Chrome.app --args --user-data-dir=/tmp/foo --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://localhost:8111
Chromium browser did not start with these settings to allow to overcome this specific DomException for using SSL with service worker locally.
This person provided some insights as a story as well for this matter: https://deanhume.com/testing-service-workers-locally-with-self-signed-certificates/
answered Aug 5, 2019 at 12:57
Service workers are awesome. They provide us with powerful functionality to intercept and handle network requests, cache resources, send useful push notifications and so much more. Because service workers have this ability to intercept network requests, it’s essential that they run over HTTPS. In the wrong hands, a malicious developer could do some nasty things!
Service workers need to run over HTTPS to ensure that the web page hasn’t been tampered with during its journey through the network. If you are developing and testing your service worker code locally before deploying to a live server, you can easily test it without any certificates on your localhost.
Recently, I’ve been developing a Node.js application that uses both service workers and HTTP/2. In the same way that service workers require HTTPS, so do some instances of HTTP/2. This means that when I’m working locally, I need to use self signed certificates. These self signed certificates are just fake ones that are used for testing, but it does mean that when I navigate to the site locally, I see the following warning message.
When I’m testing locally, this isn’t really a problem for HTTP/2 because I can just ignore the warnings and skip to the next page. However, my service worker will no longer register! If I open up the developer tools, I see an error similar to the image below.
In the console of the developer tools, I see the error “DOMException: Failed to register a ServiceWorker: An SSL certificate error occurred when fetching the script”. This acts as a safety net in order to ensure that the certificates are safe, but it makes it a bit harder to test locally. In order to ensure that my development workflow is seamless both locally and when it is deployed, I needed to get this working!
Fortunately there is a way around this. Google’s Chrome has a setting that allows you to override this for a given domain. I wouldn’t recommend running this all the time, but it can be helpful for when you are testing locally with self signed certificates.
In order to start a new instance of Google Chrome, you will need to open it with a few flags enabled. In your terminal, run the following command (you will want to replace localhost:1123 with your own).
/Applications/Google Chrome.app/Contents/MacOS/Google Chrome —user-data-dir=/tmp/foo —ignore-certificate-errors —unsafely-treat-insecure-origin-as-secure=https://localhost:1123
The command above will open up a new instance of Google Chrome and unsafely treat your chosen origin as secure. You also won’t see any warning errors anymore and your service worker will register. You wouldn’t want to use this all of the time, but it is perfect for testing.
If you are on a Windows machine, you’ll need fire up your command prompt and replace the path to point your Chrome installation, which might be something like:
C:Program Files (x86)GoogleChromeApplicationchrome.exe —ignore-certificate-errors —unsafely-treat-insecure-origin-as-secure=https://localhost:1123
I hope this was helpful for you, as it took me a while to figure this out!
When using Mock Service Worker on a local HTTPS server, you’ll encounter issues during the worker script registration in the browser:
1SecurityError: Failed to register a ServiceWorker: An SSL certificate error occurred when fetching the script.
Such error is expected and is thrown by the browser whenever you attempt to register a Service Worker over insecure HTTPS. That limitation is implemented according to the Service Worker specification and serves to prevent security vulnerabilities when intercepting a network traffic on insecure connections.
This issue is caused by how your application is served, not what resources it requests.
Solutions
Connections signed by invalid or self-signed certificates are automatically considered insecure. Below you can see a few suggestions on how to enable API mocking on a local HTTPS environment.
(Recommended) Use a signed SSL certificate
Always favor signed SSL certificates, even when developing locally. Use services like Let’s Encrypt to sign your SSL certificate and enable Service Workers in your application.
Trust the self-signed certificate
This is a system-wide option. You can configure your OS to trust the self-signed certificate you’re using for development. Please refer to the respective instructions depending on your OS.
Trust insecure localhost
Alternatively, you can configure your browser to trust https://localhost
despite it using an invalid certificate. Please resort to this option as a last measure, since adjusting the default browser security rules may lead to unexpected behavior and security vulnerabilities if handled poorly.
Chrome
- Go to
chrome://flags
- Locate the
allow-insecure-localhost
flag in the list. - Select the «Enabled» option from the flag’s dropdown.
Firefox
- Open your local HTTPS application.
- On the «Connection is not secure» screen click the «Advanced» button.
- In the section below, click the «Add Exception» button.
- Specify your application’s URL as the «Location» input value.
- Click the «Confirm Security Exception» button to enable the exception.