Can you use a service worker with a self-signed certificate?

Question

I have developer server that are used for testing. They have SSL self-signed certificates, which allow us to test the web application over HTTPS, but with prominent warnings that the certificates are not verifiable.

That's fine, but I have a Service Worker that throws an error with the navigator.serviceWorker.register

SecurityError: Failed to register a ServiceWorker: An SSL certificate error occurred when fetching the script.

How do I use a Service Worker with an intranet testing server which has a self-signed certificate?

Answer 1

As an alternative to using self-signed certificates, you can launch Chrome or Firefox such that it pretends certain domains are secure. For example, using Chrome on a Mac, you can launch it using:

/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ --user-data-dir=/tmp/foo --unsafely-treat-insecure-origin-as-secure=http://www.your.site

Service workers should then work from http://www.your.site.

More info can be found here: Options for testing service workers via HTTP

Edit: Changed --unsafety-... to --unsafely-...

Answer 2

The accepted answer above didn't work for me. I added the --ignore-certificate-errors to that as suggested by @stef52 for this question Error with Service Worker registration and that worked

chrome.exe --user-data-dir=/tmp/foo --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://localhost/

OR for MAC users

 ./Google\ Chrome --user-data-dir=/tmp/foo --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://localhost

Answer 3

For me working on latest Chrome available v.79. the following works on OS X.

Create new certificates - Only required If your default certificates are expired, which might be the case, if its been long time since Your apache installation.

Create a new certificate for localhost using the following snippet from letsencrypt.org

openssl req -x509 -out server.crt -keyout server.key \
  -newkey rsa:2048 -nodes -sha256 \
  -subj '/CN=localhost' -extensions EXT -config <( \
   printf "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")

Enable the newly created certificate by placing the created .crt and .key in /usr/local/etc/httpd or wherever Your certificates might be located.

server.key/server.crt should be default names for the certificates, but if You have changed it, it might be better to check the configuration which is located at /usr/local/etc/httpd/extra/httpd-ssl.conf for me

The following lines are the meaningful ones:

SSLCertificateFile "/usr/local/etc/httpd/server.crt"
SSLCertificateKeyFile "/usr/local/etc/httpd/server.key"

then restart the server

Make Your computer trust Your self signed certificates

Click the padlock icon on the left side of the URL, while https://localhost is open On said panel, choose 'certificates' and the window on the right will open up.

Select localhost, and on the bigger icon above 'details', drag the icon to Your desktop.

You should end up with file such as localhost.cer on Your desktop.

Double click this file or right click -> open with Keychain access

Select Category 'All items' and a certificate with name 'localhost' should appear on the right panel.

Double click the 'localhost' on the right panel and the following window should open up

Expand 'trust' and under 'when using this certificate' select 'always trust'

Close the window. Now this certificate should be trusted.

Answer 4

For local development we use self signed certs. To overcome the problems relating to local dev on OSX. We did the following:

• Create your certificate and serve it up
• Navigate to the https url
• Open dev tools > security > view certificate
• drag the certificate icon to the desktop and doubleclick on it, this will open up keychain access.
• drag the certificate icon to login, open up log-in and double click on the certificate (it should be named with the dev domain or similar) open up the trust dropdown and select always trust. Go back to your app close the window and re-open with https, you should now have 'faux' https for your dev domain.

Answer 5

This answer repeats some Chucks' points.

If that specific DomException was happened locally at some address port, when accessing web resource at local machine, 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/

Answer 6

For me, ignoring certificates or setting the insecure origin flag for mobile device did not work.

However, portforwarding did the trick. Service workers are allowed to run on localhost no matter if its signed with certificate and communicating through SSL, so basically you let your mobile device think that it runs on localhost but actually you are forwarding it to the real localhost on server machine. This can be achieved by each of these 2 methods:

• Using native chrome dev tools forwarding: https://stackoverflow.com/a/43426714/5048121
• Using ADB: https://stackoverflow.com/a/46795769/5048121

Answer 7

For those who are getting error No such file or directory after trying @Chucks accepted answer try below,

/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

More information can be found on this link

Answer 8

Yes, on Firefox 83/84 no problem. This didn't work for me on Chrome 87/88, so I switched.

You shouldn't need a public IP, FDQN, ssl cert, and/or fiddly settings to do basic web development.

Ultimately, I turned off PWA for my application in development.

Answer 9

Answers by Pasi Matalamäki and Lesbaa are the most correct. I'm going to explain why and talk through the concepts.

Yes, you might be able to start chrome in a mode that ignores cert errors from your site in dev -- even if you can do that today, my money says that in the future that will change. Therefore, I would not go that route in 2021.

The crux of the issue is that the browsers have the very difficult job of putting the power of PWA and serviceworkers into developers hands, while at the same time keeping those things away from black hat hacker's -- or at least making it practically impossible for someone to setup a malicious PWA that all the browsers will trust and let run.

When you think of the problem from that angle, the right solution is clear. You need a dev environment where your PWA is being served up with a cert that your browser will trust.

Let me say, that as a developer and as an infrastructure professional of decades, this stumped me too. But it shouldn't have.

I see lots of comments saying you shouldn't need a public IP and SSL Cert to do basic web development. I agree. But to be fair, developing a PWA and service workers is not basic web development -- it is powerful web development that has to be secured, as I said earlier.

Also, you don't need a public IP and you don't need to buy a cert -- not for the lone developer or for the enterprise development shop in a corporation.

In any case, you have to get a certificate generated by a CA that your browser trusts. In the context of or corporations internal network and developing internal apps, your infrastructure teams most likely already have a CA that all your company's internal PC's trust and therefore you will get the full lock in your browser. You just have to find out how to get a cert generated by them, and then THAT cert is the one you use with your http-server or whatever you are using to serve it up.

In the context of the developer that isn't in a corp, you just have to create your own CA, then using that CA you generate a certificate. Here is one, of many, good guides on doing that: https://www.ibm.com/docs/en/runbook-automation?topic=certificate-generate-root-ca-key

However, there is an important thing you must do next -- you have to install that CA into your OS so that your OS considers it a trusted third party CA. How you do that on windows and MacOS: https://smallbusiness.chron.com/make-computer-trust-certificate-authority-57649.html

On Linux, here is a good thread on how to do that on one popular flavor: https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu

Note, you may not have to, but I also installed the certificate I generated with the CA to my host(s). Probably not necessary.

You may run into issues because the tool you use to generate CA/CRTs outputs in a format that is different from what your OS expects. If you find that is your case, there are plenty of articles that can tell you how to transform certs into various formats.

Now, some readers may be thinking "but how do I get this to work for my entire team, etc". The answer is, you really can't. Not unless your team is on a corporate net with all the PC's managed and already setup to trust a corporate CA, etc. So again, if that is your use case, just find the infrastructure team that owns internal SSL services and have a discussion.

While it may seem a PITA to have to go through all of this, again think about how dangerous it would be if you somehow could get other PCs to trust your cert.

The good news is, when development is done and it is time to deploy, you do end up with a public IP and a cert tied to that IP, etc. So this is really just a dev environment issue.

Well, I suppose not in the case where your app lives on a corporate net and is only accessible internally. In that case you just get a production cert from that same infrastructure team.