Pouvez-vous utiliser un travailleur de service avec un certificat auto-signé ?

Question

J'ai un serveur de développement qui est utilisé pour les tests. Ils disposent de certificats SSL auto-signés, qui nous permettent de tester l'application web sur HTTPS, mais avec des avertissements bien visibles indiquant que les certificats ne sont pas vérifiables.

C'est très bien, mais j'ai un Service Worker qui jette une erreur avec l'adresse suivante navigator.serviceWorker.register

SecurityError : Impossible d'enregistrer un ServiceWorker : Une erreur de certificat SSL s'est produite lors de l'extraction du script.

Comment utiliser un Service Worker avec un serveur de test intranet qui possède un certificat auto-signé ?

Answer 1

Cette réponse répète certains points de Chucks.

Si cette DomException spécifique s'est produite localement sur un port d'adresse, lors de l'accès à une ressource Web sur une machine locale, l'une de ces dernières versions du navigateur peut avoir aidé :

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

Le navigateur Chromium n'a pas démarré avec ces paramètres pour permettre de surmonter cette DomException spécifique pour l'utilisation de SSL avec le service worker localement.

Cette personne a également fourni des informations sur cette question : https://deanhume.com/testing-service-workers-locally-with-self-signed-certificates/

Answer 2

Pour ceux qui obtiennent l'erreur No such file or directory après avoir essayé la réponse acceptée par @Chucks, essayez ci-dessous,

/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

Vous trouverez de plus amples informations sur ce lien

Answer 3

Oui, sur Firefox 83/84 pas de problème. Cela ne fonctionnait pas pour moi sur Chrome 87/88, alors j'ai changé.

Vous ne devriez pas avoir besoin d'une IP publique, d'un FDQN, d'un certificat SSL et/ou de paramètres compliqués pour effectuer un développement web de base.

En fin de compte, j'ai désactivé la PWA pour mon application en cours de développement.

Answer 4

Pour moi, ignorer les certificats ou définir l'indicateur d'origine non sécurisée pour le périphérique mobile n'a pas fonctionné.

Cependant, le portforwarding a fait l'affaire. Les travailleurs de service sont autorisés à s'exécuter sur localhost, peu importe s'ils sont signés par un certificat et s'ils communiquent par SSL. En fait, vous laissez votre appareil mobile penser qu'il s'exécute sur localhost, mais en réalité, vous le redirigez vers le véritable localhost de la machine serveur. Cela peut être réalisé par chacune de ces 2 méthodes :

• Utilisation du transfert des outils de développement de chrome natif : https://stackoverflow.com/a/43426714/5048121
• Utilisation de l'ADB : https://stackoverflow.com/a/46795769/5048121