Création d’un certificate auto-signé pour le domaine et les sous-domaines – NET :: ERR_CERT_COMMON_NAME_INVALID

J’ai suivi ce tutoriel pour créer des certificates SSL signés sur Windows à des fins de développement, et cela a fonctionné parfaitement pour l’un de mes domaines (j’utilise le fichier hosts pour simuler DNS). Puis je me suis dit que j’avais beaucoup de sous-domaines, et que créer un certificate pour chacun d’entre eux poserait problème. J’ai donc essayé de créer un certificate en utilisant un caractère générique dans Common champ Common , comme suggéré dans certaines des réponses de serverfault. Comme ça:

 Common Name: *.myserver.net/CN=myserver.net 

Toutefois, après avoir importé ce certificate dans l’autorité de certificateion racine de confiance, NET::ERR_CERT_COMMON_NAME_INVALID erreur NET::ERR_CERT_COMMON_NAME_INVALID dans Chrome, pour le domaine principal et tous ses sous-modules, par exemple: https://sub1.myserver.net et https://myserver.net .

Ce serveur n’a pas pu prouver qu’il s’agit de myserver.net; son certificate de sécurité provient de * .myserver.net / CN = myserver.net.

Cela peut être dû à une mauvaise configuration ou à un pirate qui intercepte votre connexion.

Y a-t-il un problème dans le champ Nom commun qui est à l’origine de cette erreur?

Comme Rahul l’a dit, il s’agit d’un bug commun de Chrome et d’OSX. J’avais des problèmes similaires dans le passé. En fait, je me suis finalement lassé de faire les 2 clics supplémentaires [oui, je sais que ce n’est pas beaucoup] lorsque vous testez un site local pour le travail.

En ce qui concerne une solution possible à ce problème [avec Windows], j’utiliserais l’un des nombreux utilitaires de certificate auto-signés disponibles .

Étapes recommandées:

  1. Créer un certificate auto-signé
  2. Importer un certificate dans le gestionnaire de certificates Windows
  3. Importer un certificate dans Chrome Certificate Manager
    REMARQUE: L’ étape 3 résoudra le problème rencontré une fois que Google aura corrigé le bogue. Étant donné que le délai a été dépassé, il n’y aura pas d’ETA dans un avenir prévisible. **

    Autant que je préfère utiliser Chrome pour le développement, je me suis retrouvé dans Firefox Developer Edition ces derniers temps. qui n’a pas ce problème.

    J’espère que cela t’aides 🙂

Chrome 58 a cessé de prendre en charge les certificates sans autres noms de sujet .

En allant de l’avant, cela pourrait être une autre raison pour laquelle vous rencontrez cette erreur.

Une solution de contournement consiste à append les noms de domaine que vous utilisez en tant que “subjectAltName” (Autre nom d’object X509v3). Cela peut être fait en changeant votre configuration OpenSSL ( /etc/ssl/openssl.cnf sous Linux) et en modifiant la section v3_req pour qu’elle ressemble à ceci:

 [ v3_req ] # Extensions to add to a certificatee request basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = @alt_names [alt_names] DNS.1 = myserver.net DNS.2 = sub1.myserver.net 

Avec ceci en place, n’oubliez pas d’utiliser le commutateur -extensions v3_req lors de la génération de votre nouveau certificate. (voir aussi Comment puis-je générer un certificate auto-signé avec SubjectAltName en utilisant OpenSSL? )

Votre caractère générique *.example.com ne couvre pas le domaine racine example.com mais couvre toute variante d’un sous- domaine tel que www.example.com ou test.example.com

La méthode privilégiée consiste à établir des noms alternatifs du sujet comme dans la réponse de Fabian, mais gardez à l’esprit que Chrome exige actuellement que le nom commun figure également parmi les noms alternatifs du sujet (comme cela est correctement démontré dans sa réponse). J’ai récemment découvert ce problème car j’avais le nom commun example.com avec les SAN www.example.com et test.example.com , mais j’ai reçu l’avertissement NET::ERR_CERT_COMMON_NAME_INVALID de Chrome. J’ai dû générer une nouvelle demande de signature de certificate avec example.com en tant que nom commun et l’ un des SAN. Ensuite, Chrome a entièrement approuvé le certificate. Et n’oubliez pas d’importer le certificate racine dans Chrome en tant qu’autorité de confiance pour identifier les sites Web.

Créez le fichier openssl.conf :

 [req] default_bits = 2048 default_keyfile = oats.key encrypt_key = no utf8 = yes distinguished_name = req_distinguished_name x509_extensions = v3_req prompt = no [req_distinguished_name] C = US ST = Cary L = Cary O = BigCompany CN = *.myserver.net [v3_req] keyUsage = critical, digitalSignature, keyAgreement extendedKeyUsage = serverAuth subjectAltName = @alt_names [alt_names] DNS.1 = myserver.net DNS.1 = *.myserver.net 

Exécutez ce comand:

 openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:2048 -keyout app.key -out app.crt -config openssh.conf 

Les fichiers de sortie app.crt et app.key fonctionnent pour moi.

Je pense que cela peut être un bug dans le chrome. Il y avait un problème similaire depuis longtemps: voir ceci.

Essayez dans un autre navigateur. Je pense que ça devrait bien fonctionner.

Si vous êtes fatigué de cette erreur. Vous pouvez faire en sorte que Chrome ne se comporte pas comme ça. Je ne dis pas que c’est la meilleure façon de dire que c’est un moyen.

Pour contourner ce problème, une clé de registre Windows peut être créée pour permettre à Google Chrome d’utiliser le CommonName d’un certificate de serveur pour correspondre à un nom d’hôte si l’extension ne contient pas une extension subjectAlternativeName, à condition qu’elle soit validée et chaînée à une autorité de certificateion installée localement. certificates.

Type de données: Booléen [Windows: REG_DWORD] Emplacement du registre Windows: HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Google \ Chrome Nom de préférence Windows / Mac / Linux / Android: EnableCommonNameFallbackForLocalAnchors Valeur: 0x00000001 (Windows), true (Linux), true (Android), (Mac) Pour créer une clé de registre Windows, procédez comme suit:

Ouvrir le bloc-notes Copiez et collez le contenu suivant dans le Bloc-notes Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Google \ Chrome] “EnableCommonNameFallbackForLocalAnchors” = dword: 00000001 Allez dans Fichier> Enregistrer sous Nom de fichier: any_filename.reg Enregistrer sous le type: Tous les fichiers

Sélectionnez un emplacement préféré pour le fichier

Cliquez sur Enregistrer

Double-cliquez sur le fichier enregistré pour l’exécuter

Cliquez sur Oui dans l’avertissement de l’éditeur de registre

Vous trouverez ces informations sur la page de support de Symantec: https://support.symantec.com/en_US/article.TECH240507.html