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.
la source
Réponses:
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
.devdomaines 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.la source
.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 commeint.example.comoudev.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!).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.Il existe un moyen simple de contourner ce problème.
about:configfalse.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é.
la source
.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.Réglage
security.enterprise_roots.enableddetruesur laabout: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.
la source
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:
about:support.Open Directorysur votre profil de navigateur.la source
Je suis allé pour "Let's Encrypt"
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.
la source