Comment réparer Firefox 59 n'acceptant plus mon certificat SSL auto-signé sur .dev virtualhost

20

Sur mon environnement Apache local, j'ai un site qui nécessite SSL pour le développement, donc j'utilise un certificat auto-signé. Le site local a bien fonctionné jusqu'à présent dans Firefox et Chrome, mais après la mise à jour de Firefox vers la version 59 aujourd'hui, je n'arrive pas à accepter l'exception de sécurité (sur Chrome, le certificat auto-signé continue de fonctionner).

Firefox me donne ces informations supplémentaires dans la page bloquée:

... utilise un certificat de sécurité non valide. Le certificat n'est pas approuvé car il est auto-signé. Code d'erreur: SEC_ERROR_UNknown_ISSUER

Il n'y a pas d'option pour autoriser l'exception ici comme auparavant, mais je suis allé dans les Préférences Firefox sous Certificats, puis dans l'onglet "Serveur" j'ai ajouté une exception pour le domaine local. Le certificat est ensuite répertorié dans le nom de serveur local correct, les détails montrent que mes paramètres de certificat sont émis par et émis comme étant identiques, avec une durée valide.

Quelqu'un rencontrant des problèmes similaires avec FF 59 ou pourrait-il avoir une idée de quoi essayer de faire fonctionner le certificat auto-signé localement?

Edit: Je ne vois aucune mention de cela dans les notes de publication de FF 59 mais quelque chose dans la nouvelle version fait que tous mes hôtes virtuels locaux sur les domaines * .dev essaient automatiquement d'établir une connexion https (c'est-à-dire tous http les demandes pour * .dev sont automatiquement envoyées à l'URL https). Peut-être que quelque chose à propos de ce comportement est également à l'origine de ces problèmes pour mes hôtes virtuels https réels.

ssl ssl-certificate firefox

— kontur
source

1

Je suppose que vous avez maintenant besoin d'une autorité de certification pour un certificat auto-signé, car Firefox a resserré progressivement les exigences au cours des dernières versions. Cependant, avec Let's Encrypt, il n'y a plus de raison d'utiliser des certificats auto-signés.

— Simon Greenwood

Je ne veux pas deviner mais je pense que @SimonGreenwood a raison. Mais généralement, Firefox définit simplement les nouvelles options par défaut et vous permet de modifier les paramètres. Vérifiez vos paramètres de confidentialité.

@Broco Si quelque chose se trouve dans les paramètres de sécurité, pas dans les paramètres de confidentialité. Comme indiqué ci-dessus, j'ai même ajouté une exception de sécurité, mais Firefox insiste toujours pour ne pas pouvoir valider le certificat, car évidemment l'émetteur est inconnu.

— kontur

@kontur pour moi, le lien concerne: les préférences # confidentialité pour définir les paramètres de confidentialité et de sécurité, c'est pourquoi j'ai dit confidentialité. Pensez à le poster comme un bug.

2

@SimonGreenwood Il y a de nombreuses raisons de ne pas utiliser Let's encrypt sur une connexion locale. On ne voudrait pas mettre en place encrpyt.

— Jon

15

Je ne suis toujours pas tout à fait clair sur la façon dont tout cela s'emboîte exactement, mais comme indiqué dans cette réponse, les .dev domaines sont maintenant des TLD officiels. En tant que tel, il semble que les navigateurs forcent une sorte de comportement HSTS et forcent les connexions https. Pour ces TLD, il semble que mon certificat auto-signé n'ait plus été accepté dans Firefox. Changer mes hôtes virtuels pour les utiliser a .testrésolu le problème sans avoir à changer quoi que ce soit dans mes certificats auto-signés.

Il convient de noter que dans Firefox, mes hôtes virtuels non SSL ont également agi depuis la version 59 aujourd'hui, car le comportement HSTS semblait forcer SSL sur les hôtes virtuels que je n'avais pas configurés comme servant via SSL. Sur Chrome, cela fonctionnait toujours, mais dans tous les cas, il est sûr de dire que s'éloigner du .devTLD maintenant officiellement utilisé résoudra de nombreux maux de tête.

— kontur
source

1

Oui, .devc'est un TLD valide depuis un certain temps, alors ne l' utilisez PAS pour nommer vos ressources internes. Idem pour tout autre nom: n'utilisez aucun nom que vous pensez que personne d'autre n'utilisera. Utilisez des noms de test référencés dans la RFC2606 ou enregistrez simplement un vrai nom de domaine n'importe où et utilisez un sous-domaine comme int.example.comou dev.example.compour suffixer tous vos noms internes. Vous n'aurez alors jamais de collisions ou de problèmes (tant que vous vous souvenez de renouveler le nom de domaine chaque année!)

— Patrick Mevzek

2

Voir ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts

— Patrick Mevzek

1

Merci pour le lien. Les délais mentionnés ici ne correspondent pas tout à fait, mais l'auteur a peut-être parlé d'aperçus de développement ou similaires. Compte tenu de ce que je sais maintenant, il est vraiment difficile de voir pourquoi les fournisseurs de navigateurs n'ajouteraient pas d'informations de débogage supplémentaires, en particulier en ce qui concerne les erreurs SSL sur les .devdomaines. À moins que vous ne sachiez qu'il s'agit d'un TLD, il n'y a aucune chance que vous en déduisiez que c'est le problème.

— kontur

12

Il existe un moyen simple de contourner ce problème.

Aller à about:config
Recherchez "network.stricttransportsecurity.preloadlist".
Réglez-le sur false.

AVERTISSEMENT: cela désactivera complètement HSTS . Jetez un œil aux commentaires sur cette réponse pour une discussion sur les inconvénients de cette méthode. Personnellement, je pense que les avantages l'emportent sur les risques, mais vous êtes responsable de votre propre sécurité.

— Andy Mercer
source

4

C'est une très mauvaise idée car ce paramètre s'appliquera à tous les sites Web que vous visitez, pas seulement au vôtre. Vous réduisez votre sécurité.

— Patrick Mevzek

Je ne suis pas d'accord. HSTS est relativement nouveau. Nous nous en sortons très bien depuis 20 ans, donc dire que le désactiver est très mauvais pour la sécurité est exagéré. Deuxièmement, même si c'est une mauvaise idée, il n'y a pas vraiment d'autre option si je veux que mes serveurs de développement continuent de fonctionner, ce qui n'implique pas de changements très longs dans mon environnement de développement.

— Andy Mercer

1

Une solution comme celle-ci: security.stackexchange.com/a/154176 n'impacte au moins qu'un seul site, pas tous.

— Patrick Mevzek

1

Aussi condescendant que je sache, cela va sembler, à mesure que vous vieillissez, vous vous rendrez compte que des choses comme les "meilleures pratiques" et les "mauvaises" sont flexibles et changent avec le temps. Ce que les gens considèrent comme «faux» en ce moment, n'a pas été considéré comme faux depuis de nombreuses années, et ne le sera peut-être plus à l'avenir. Quant à cette discussion spécifique, nous devrons simplement accepter d'être en désaccord.

— Andy Mercer

1

Merci pour ce correctif, fonctionne très bien pour moi dans Firefox 59.0.1 (et Firefox Dev Edition 60). Nos .devprojets actuels seront éventuellement déplacés vers un autre suffixe TLD, mais pour l'instant cela ne permet pas de stopper le développement local.

— Jake Bathman

4

Réglage security.enterprise_roots.enabledde truesur la about:configPage résolu pour moi et a permis à mon certificat auto-signé au travail au cours du développement.

Il y a un peu de discussion sur le bien-fondé de cette option par défaut ici:
Définissez security.enterprise_roots.enabled sur true par défaut .

Bien que l'intention de cet indicateur soit de permettre à Firefox d'utiliser le magasin racine de l'autorité de certification à l'échelle de la machine comme source valide pour les autorités de certification, cela a corrigé la situation pour mon propre cas d'utilisation où j'ai un certificat multi-domaine auto-signé que j'utilise localement pour les tests (subjectAltName's) . Même après avoir ajouté le certificat à la liste des certificats Firefox, ce n'est que lorsque je l'ai activé qu'il a permis au site local de se charger.

— Sean Aitken
source

Merci, ça a marché!

— informatik01

0

Eu le même problème sur Basilisk Web Browser . J'ai essayé de modifier les paramètres du proxy réseau ou de modifier les indicateurs "network.stricttransportsecurity.preloadlist" ou "security.enterprise_roots.enabled" ... mais cela n'a pas résolu le bouton manquant pour ajouter un certificat pour le site Web bloqué. Seulement cela a réussi:

Allez à about:support.
Cliquez Open Directorysur votre profil de navigateur.
Fermez complètement le navigateur.
Modifiez le fichier " SiteSecurityServiceState.txt " dans le répertoire ci-dessus.
Recherchez et supprimez toute la ligne contenant le site HSTS bloqué.
Enregistrez le fichier et rouvrez votre navigateur sur ce site.

— Noam Manos
source

-3

Je suis allé pour "Let's Encrypt"

https://letsencrypt.org/

Valable seulement 3 mois à la fois, mais le rafraîchissement peut être automatisé.

Comme vous pouvez le voir dans les remarques, il y a un hic. Nos domaines de développement et de test s'appellent dev-www.example.com et test-www.example.com. Nous utilisons le certificat générique de production.

— Gerard H. Pille
source

5

Ne chiffrons-nous pas que le serveur et le domaine soient accessibles au public? Je recherche des options pour utiliser SSL sur des hôtes virtuels locaux.

— kontur

Ouais ça ne marche pas pour les gens qui font du développement local.

— Andy Mercer

la question concerne LOCAL DEV

@Pieter est-ce la même chose que le "développement local"? Parce que c'est ce que nous faisons.

— Gerard

1

@ GerardH.Pille Vous ne pouvez générer des certificats Let's encrypt que si le serveur est accessible depuis Internet. Pour mon développement local, ce n'est pas le cas, donc ce n'est pas viable. Veuillez informer s'il manque quelque chose.

— kontur