66 votes

Google Chrome localhost | NET::ERR_CERT_AUTHORITY_INVALID

Tout à coup, je semble avoir un problème avec Google Chrome utilisant localhost.

J'essaie d'accéder à l'un de mes sites de développement (à l'aide d'Ampps) et j'obtiens l'erreur suivante :-.

Votre connexion n'est pas privée Des attaquants peuvent essayer de voler vos informations à partir du site web. informations à partir de website.dev (par exemple, des mots de passe, des messages ou cartes de crédit). En savoir plus NET::ERR_CERT_AUTHORITY_INVALID

Lorsque je visite l'un des sites de développement, il est redirigé à partir de http://website.dev a https://website.dev automatiquement. Je n'ai aucun problème dans Safari ou Firefox, je ne comprends donc pas ce qui se passe.

J'ai essayé de réinstaller Google Chrome, de rétablir les paramètres d'usine par défaut...

Je pense que cela pourrait être un problème avec Keychain Access --> Certificats mais cela ne signifierait-il pas que cela ne fonctionnerait pas dans Firefox et Safari si c'était le cas ?

J'ai passé un certain temps à essayer de trouver une solution, mais jusqu'à présent, rien n'a fonctionné. J'aimerais donc avoir des suggestions sur la façon de résoudre ce problème. Je ne peux même pas passer cet avertissement, car je n'obtiens pas le lien de validation (non sécurisé), comme indiqué ci-dessous :-.

enter image description here

2 votes

Salut ! Exactement le même problème ici. Des progrès ? Ce qui est curieux, c'est que tout allait bien, par exemple, hier et qu'aujourd'hui, c'est un désastre total. Je soupçonne que Chrome a été mis à jour (63.0.3239.84 maintenant sur mon PC). J'ai lu plusieurs articles/posts sur le web et j'ai essayé de vider le cache, de réinstaller Chrome, de supprimer les politiques HSTS pour les domaines, d'accéder avec et sans https.

1 votes

@curveball Je pensais que je devenais fou. J'ai testé cela sur une installation complètement différente sur un autre ordinateur et cela a bien fonctionné, mais je ne pensais pas que cela serait lié au .dev et je le testais avec .localhost ! Cela s'est littéralement produit pendant la nuit, donc ce doit être Chrome. Merci beaucoup, Google, pour avoir gâché plusieurs jours de travail à essayer de résoudre ce problème stupide. Pourquoi ont-ils réglé .dev sur SSL forcé ?

0 votes

Alison, tu es la bienvenue ! Oui, ce problème a surgi de nulle part. Je ne suis pas assez compétent pour énumérer des raisons solides pour lesquelles ils l'ont fait. Cela tourne autour de l'idée du "https partout". Peut-être qu'ils voulaient tellement ajouter cette fonctionnalité qu'ils l'ont fait à la hâte pendant la nuit. Bien que le message qu'ils affichent dans Chrome soit totalement vrai ("votre connexion n'est pas privée"), il est également très déroutant car il existe plusieurs causes différentes menant au même message et la cause réelle d'un tel comportement est plutôt cachée. J'ai moi-même essayé plusieurs conseils avant de trouver l'essentiel.

184voto

Matt Smith Points 597

Naviguez vers

chrome://flags/#allow-insecure-localhost

et définissez-le comme étant activé.

enter image description here

2 votes

Après avoir passé une journée entière sur ce problème, j'ai finalement trouvé une solution de contournement qui m'a aidé !

9 votes

Cela ne fonctionne qu'avec le nom d'hôte littéral "localhost", pas avec les autres domaines locaux.

0 votes

@MikeShiyan J'ai finalement utilisé localhost.dev y localhost.test et ça a marché.

37voto

curveball Points 2784

Après avoir joué un peu, j'ai trouvé une sorte de solution.

Tout d'abord, parlons du problème : la cause de cette erreur est que nous avons tous les deux utilisé une .dev pour notre développement local. Si vous allez aquí vous découvrirez que Root .dev est la propriété de Google et s'applique HSTS dans Chrome, ils appliquent la redirection https pour ce domaine. Puisque nous utilisons .dev nous sommes redirigés vers la version https et en même temps nous n'avons pas de certificats installés. Donc, nous voyons cette erreur ennuyeuse. Si vous allez sur chrome://net-internals/#hsts vous pouvez vérifier votre .dev et vous découvrirez que

static_sts_domain: dev
static_upgrade_mode: FORCE_HTTPS
static_sts_include_subdomains: true

qui confirme que le HSTS est appliqué sur *.dev en effet. Le type de politique est statique et, d'après ce que je comprends, il est codé en dur pour https-redirect. .dev domaines.

Il y a donc au moins deux possibilités : obtenir et configurer un certificat réel d'une manière ou d'une autre, ou utiliser un autre certificat (qui n'est pas un certificat de sécurité). .dev ) Domaine racine dans httpd-vhosts.conf pour votre développement local (n'oubliez pas de mettre à jour le fichier /etc/hosts et relancer apache). J'ai emprunté une autre voie pour le domaine racine et cela a résolu le problème.

2 votes

Merci pour l'explication @curveball - Est-ce nouveau ? J'utilise .dev pour tous mes domaines depuis deux ans et je n'ai jamais eu ce genre de problème auparavant. Cela fonctionne toujours avec .dev sur mon ordinateur portable mais pas sur mon iMac. Les deux exécutent la même version du système d'exploitation et la même version de Chrome.

0 votes

D'après ce que j'ai compris, l'idée n'est pas nouvelle, mais c'est aussi la première fois que je rencontre ce problème. Je pense que ce qui est nouveau, c'est que cette histoire avec les hsts est devenue le comportement par défaut dans chrome. En outre, la liste des domaines comme .dev qui nécessitent une redirection vers la version https s'allonge.

0 votes

Merci encore @curveball - donc à l'avenir, il suffit d'utiliser 'test' au lieu de 'test.dev' ou nous pouvons utiliser autre chose comme test.yourcompanyname ? (tant que c'est quelque chose qui n'est pas déjà utilisé).

6voto

Mihail Ivanchev Points 191

C'est vraiment ennuyeux à gérer, mais le mappage du site web local à autre chose que .dev (J'utilise personnellement .devo ) fonctionne et corrige le problème dans chrome. Vous pouvez également ajouter une exception pour la page dans Mozilla Firefox et ne pas vous préoccuper du tout de ce problème. Le problème ne se pose que dans Chrome 63+.

3 votes

Il semble que cela fonctionne sans le '.dev', mais il est étrange que cela fonctionne avec .dev pour tous mes domaines locaux depuis deux ans et que cela cesse soudainement de fonctionner uniquement sur Chrome.

0 votes

J'utilisais également .dev depuis deux ans et il a soudainement cessé de fonctionner. C'est ce qui a fonctionné pour moi. Merci.

0 votes

Cette réponse ressemble plus à un commentaire pour moi. Cela n'apportera aucune aide aux internautes sur cette question et votre réponse ne leur sera d'aucune utilité. Pouvez-vous mettre à jour votre réponse avec des explications, etc.

4voto

Klemart3D Points 68

La meilleure solution est de ne pas utiliser .dev car il appartient à Google. Vous trouverez ici une liste actualisée de tous les TLD revendiqués : https://www.rfc-editor.org/rfc/rfc6761

Pour être sûr, choisissez un TLD non réclamé comme .test o .localhost . Vous pouvez lire un article de blog utile ici : https://iyware.com/dont-use-dev-for-development/

0 votes

Vous pouvez également utiliser .local :)

1 votes

@solomonculaste oui vous pouvez, mais il est possible qu'il soit réclamé comme .dev . Le mieux est d'utiliser .test tools.ietf.org/html/rfc2606#section-2 et ne plus avoir à s'en soucier.

0 votes

Merci d'avoir partagé cet article. Il était bien écrit et a beaucoup de sens. J'ai changé mon dev local pour utiliser .loc

0voto

moonclearner Points 1

J'ai eu le même problème parce que le fichier CRL n'est pas à jour et la solution est de mettre à jour le fichier CRL.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X