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

Au lieu d'utiliser des certificats auto-signés, vous pouvez lancer Chrome ou Firefox de manière à ce qu'il prétende que certains domaines sont sécurisés. Par exemple, si vous utilisez Chrome sur un Mac, vous pouvez le lancer en utilisant :

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

Les travailleurs sociaux doivent alors travailler à partir de http://www.your.site .

Vous trouverez plus d'informations ici : Options pour tester les travailleurs des services via HTTP

Edit : Changed --unsafety-... à --unsafely-...

Answer 2

La réponse acceptée ci-dessus n'a pas fonctionné pour moi. J'y ai ajouté l'option --ignore-certificate-errors comme suggéré par @stef52 pour cette question. Erreur d'enregistrement du Service Worker et cela a fonctionné

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

OU pour les utilisateurs de MAC

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

Answer 3

Pour moi qui travaille sur la dernière version de Chrome disponible v.79, ce qui suit fonctionne sur OS X.

Créer de nouveaux certificats - Nécessaire uniquement si vos certificats par défaut sont expirés, ce qui peut être le cas, si votre installation d'Apache est terminée depuis longtemps.

Créez un nouveau certificat pour localhost en utilisant l'extrait suivant de l'application 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")

Activez le certificat nouvellement créé en plaçant les fichiers .crt et .key créés dans /usr/local/etc/httpd ou quel que soit l'endroit où se trouvent vos certificats.

server.key/server.crt devraient être les noms par défaut des certificats, mais si vous les avez changés, il serait préférable de vérifier la configuration qui se trouve à l'adresse suivante /usr/local/etc/httpd/extra/httpd-ssl.conf pour moi

Les lignes suivantes sont les plus significatives :

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

puis redémarrer le serveur

Faites en sorte que votre ordinateur fasse confiance à vos certificats auto-signés

Cliquez sur l'icône du cadenas à gauche de l'URL, alors que https://localhost est ouvert Dans ce panneau, choisissez "certificats" et la fenêtre de droite s'ouvrira.

Sélectionnez localhost, et sur la grande icône au-dessus de 'details', faites glisser l'icône vers votre bureau.

Vous devriez vous retrouver avec un fichier tel que localhost.cer sur votre bureau.

Double-cliquez sur ce fichier ou cliquez sur le bouton droit de la souris -> ouvrir avec l'accès au trousseau.

Sélectionnez la catégorie "All items" et un certificat avec le nom "localhost" devrait apparaître sur le panneau de droite.

Double-cliquez sur 'localhost' dans le panneau de droite et la fenêtre suivante devrait s'ouvrir

Développez "confiance" et sous "quand utiliser ce certificat", sélectionnez "toujours faire confiance".

Fermez la fenêtre. Maintenant, ce certificat devrait être fiable.

Answer 4

Pour le développement local, nous utilisons des certificats auto-signés. Pour surmonter les problèmes liés au développement local sur OSX. Nous avons fait ce qui suit :

• Créez votre certificat et servez-le
• Naviguez vers l'url https
• Ouvrez dev tools > security > view certificate
• faites glisser l'icône du certificat sur le bureau et double-cliquez dessus, ce qui ouvrira l'accès au trousseau de clés.
• faites glisser l'icône du certificat vers le login, ouvrez le login et double-cliquez sur le certificat (il doit être nommé avec le domaine dev ou similaire) Ouvrez la liste déroulante de confiance et sélectionnez always trust. Retournez à votre application, fermez la fenêtre et rouvrez-la avec https, vous devriez maintenant avoir un 'faux' https pour votre domaine de développement.

Answer 5

Les réponses de Pasi Matalamäki et Lesbaa sont les plus correctes. Je vais expliquer pourquoi et parler des concepts.

Oui, il se peut que vous puissiez démarrer chrome dans un mode qui ignore les erreurs de certificat de votre site en développement - même si vous pouvez le faire aujourd'hui, je parie que cela changera à l'avenir. Par conséquent, je ne choisirais pas cette voie en 2021.

Le nœud du problème est que les navigateurs ont la tâche très difficile de mettre le pouvoir des PWA et des fournisseurs de services entre les mains des développeurs, tout en gardant ces choses à l'écart des pirates en chapeau noir - ou du moins en rendant pratiquement impossible pour quelqu'un de mettre en place une PWA malveillante à laquelle tous les navigateurs feront confiance et qu'ils laisseront fonctionner.

Lorsque vous envisagez le problème sous cet angle, la bonne solution apparaît clairement. Vous avez besoin d'un environnement de développement dans lequel votre PWA est servie avec un certificat auquel votre navigateur fait confiance.

Permettez-moi de dire qu'en tant que développeur et professionnel de l'infrastructure depuis des décennies, cette question m'a également laissé perplexe. Mais ça n'aurait pas dû.

Je vois beaucoup de commentaires disant que vous ne devriez pas avoir besoin d'une IP publique et d'un certificat SSL pour faire du développement web de base. Je suis d'accord. Mais pour être juste, développer une PWA et des travailleurs de service n'est pas un développement web de base -- c'est un développement web puissant qui doit être sécurisé, comme je l'ai dit plus tôt.

En outre, vous n'avez pas besoin d'une adresse IP publique ni d'acheter un certificat, que ce soit pour le développeur isolé ou pour l'atelier de développement d'une entreprise.

Dans tous les cas, vous devez obtenir un certificat généré par une autorité de certification à laquelle votre navigateur fait confiance. Dans le contexte du réseau interne d'une entreprise et du développement d'applications internes, il est fort probable que vos équipes d'infrastructure disposent déjà d'une autorité de certification à laquelle tous les PC internes de l'entreprise font confiance, ce qui vous permettra d'obtenir un verrouillage complet dans votre navigateur. Il vous suffit de trouver le moyen d'obtenir un certificat qu'elles ont généré, et c'est CE certificat que vous utiliserez avec votre serveur http ou tout autre moyen de diffusion.

Dans le contexte du développeur qui n'est pas dans une société, il suffit de créer sa propre AC, puis d'utiliser cette AC pour générer un certificat. Voici l'un des nombreux guides sur la façon de procéder : https://www.ibm.com/docs/en/runbook-automation?topic=certificate-generate-Root-ca-key

Cependant, il y a une chose importante que vous devez faire ensuite : vous devez installer cette AC dans votre système d'exploitation afin que celui-ci la considère comme une AC tierce de confiance. Comment faire cela sous Windows et MacOS : https://smallbusiness.chron.com/make-computer-trust-certificate-authority-57649.html

Sous Linux, voici un bon fil de discussion sur la façon de faire cela sur une saveur populaire : https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu

Notez que vous n'êtes peut-être pas obligé de le faire, mais j'ai également installé le certificat que j'ai généré avec l'AC sur mon ou mes hôtes. Ce n'est probablement pas nécessaire.

Il se peut que vous rencontriez des problèmes parce que l'outil que vous utilisez pour générer des CA/CRT sort dans un format différent de celui attendu par votre système d'exploitation. Si vous constatez que c'est votre cas, il existe de nombreux articles qui peuvent vous indiquer comment transformer les certificats en différents formats.

Certains lecteurs se demandent peut-être "mais comment faire pour que cela fonctionne pour toute mon équipe, etc. La réponse est que vous ne pouvez pas vraiment le faire. Sauf si votre équipe est sur un réseau d'entreprise avec tous les PC gérés et déjà configurés pour faire confiance à une autorité de certification d'entreprise, etc. Donc, encore une fois, si c'est votre cas d'utilisation, trouvez l'équipe d'infrastructure qui possède les services SSL internes et discutez-en.

Bien que cela puisse sembler être une corvée de devoir passer par tout cela, pensez à nouveau au danger que cela représenterait si vous parveniez à faire en sorte que d'autres PC fassent confiance à votre certificat.

La bonne nouvelle est que, lorsque le développement est terminé et qu'il est temps de déployer, vous disposez d'une IP publique et d'un certificat lié à cette IP, etc. Il ne s'agit donc que d'un problème lié à l'environnement de développement.

Eh bien, je suppose que non dans le cas où votre application se trouve sur un réseau d'entreprise et n'est accessible qu'en interne. Dans ce cas, il suffit d'obtenir un certificat de production auprès de la même équipe d'infrastructure.