New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 715499 link

Starred by 4 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug

Blocked on:
issue 717340



Sign in to add a comment

Allow localhost with a self-signed certificate to register a ServiceWorker

Project Member Reported by surma@chromium.org, Apr 26 2017

Issue description

Chrome Version       : M60
OS Version: OS X 10.12.4
URLs (if applicable) :

What steps will reproduce the problem?
1. Spin up a HTTPS (or HTTP/2) server using a self-signed certificate on localhost
2. Deploy a site with a service worker

index.html:
```
<script>navigator.serviceWorker.register('/sw.js');
```

sw.js:
```
// can be empty
```

3. Load site

What is the expected result?
After proceeding through the certificate warning, the ServiceWorker registration should succeed.

What happens instead of that?
The site loads but the ServiceWorker registration fails with:

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

Currently, web developers need to start Chrome with `--ignore-certificate-errors` to be able to develop ServiceWorkers locally over h2. localhost should be considered safe with a self-signed certificates.

 

Comment 1 by est...@chromium.org, Apr 26 2017

Cc: est...@chromium.org
Labels: Needs-Feedback
Status: Available (was: Unconfirmed)
I thought this was addressed in  issue 561820 . Developers can use --allow-insecure-localhost for self-signed certificates on localhost, and I think the security team wants that flag to be required.

I agree that clicking through the certificate warning should probably work, but that's a bit difficult because service worker script loading is its own path separate from the page load. Is --allow-insecure-localhost a suitable workaround?
I read the internal email thread (I'm reading email from most recent to oldest).

It sounds like this will be a possible Chrome-wide security decision to do something like:
"I think we should make Chrome force all localhost names to resolve to loopback IPs, and then just allow certificate errors on localhost by default."

In that case, this bug's scope is beyond service worker and SW team won't do any changes except to make sure we're aligned with the Chrome-wide policy.
The email thread argues that a command-line flag isn't sufficient because it's too hard for devs to use.

I think it would be reasonable to allow certificate errors by default on https://127.0.0.1 and IPv6 equivalent, just not https://localhost until we ensure that localhost always resolves to loopback IPs.
Allowing certificate errors on https://127.0.0.1 and IPv6 equivalent makes sense to me.

I assume we'd want to make this change for Chrome as a whole, not just for when registering a service worker. So I'll open a bug for that and block this one on it.

We're starting to extract service worker from the network stack so hopefully when that's done, the extra certificate checks that service worker does in ServiceWorkerWriteToCacheJob will go away, and this bug will be fixed automatically after the Chrome-wide behavior changes.
Blockedon: 717340
Project Member

Comment 7 by sheriffbot@chromium.org, May 2 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Owner: falken@chromium.org
Status: Assigned (was: Untriaged)
Mac triage: kicking to falken@ for followup.

Sign in to add a comment