J'ai suivi le didacticiel this pour la création de certificats Signed SSL sous Windows à des fins de développement. Il fonctionnait parfaitement pour l'un de mes domaines (j'utilise un fichier hosts pour simuler un DNS). Ensuite, je me suis dit que j'avais beaucoup de sous-domaines et qu'il serait très pénible de créer un certificat pour chacun d'entre eux. J'ai donc essayé de créer un certificat en utilisant un caractère générique dans le champ Common
comme suggéré dans certaines des réponses de serverfault. Comme ça:
Common Name: *.myserver.net/CN=myserver.net
Toutefois, après l'importation de ce certificat dans l'autorité de certification racine de confiance, l'erreur NET::ERR_CERT_COMMON_NAME_INVALID
apparaît dans Chrome, pour le domaine principal et tous ses sous-domaines, 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 certificat de sécurité provient de * .myserver.net/CN = myserver.net.
Cela peut être dû à une mauvaise configuration ou à un attaquant qui intercepte votre connexion.
Y a-t-il quelque chose qui cloche dans le champ Nom commun qui cause cette erreur?
Comme Rahul l'a déclaré, il s'agit d'un Chrome commun et d'un bogue OSX. J'avais des problèmes similaires dans le passé. En fait, je me suis finalement fatigué de faire 2 clics supplémentaires (oui, je sais que ce n’est pas beaucoup) lors du test d’un site local.
En ce qui concerne une solution possible à ce problème [sous Windows], j’utiliserais l’un des nombreux tilitaires de certificat à signature automatique disponibles .
Étapes recommandées:
Chrome 58 a suppression de la prise en charge des certificats sans nom alternatif de sujet .
À l'avenir, cela pourrait être une autre raison pour laquelle vous rencontrez cette erreur.
Une solution de contournement consiste à ajouter les noms de domaine que vous utilisez en tant que "subjectAltName" (nom alternatif de sujet X509v3). Cela peut être fait en modifiant 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 certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = myserver.net
DNS.2 = sub1.myserver.net
Avec cela en place, n'oubliez pas d'utiliser le commutateur -extensions v3_req
lors de la génération de votre nouveau certificat. (voir aussi Comment puis-je générer un certificat auto-signé avec SubjectAltName en utilisant OpenSSL? )
Créer 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.2 = *.myserver.net
Exécutez cette commande:
openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:2048 -keyout app.key -out app.crt -config openssl.conf
Les fichiers de sortie app.crt
et app.key
fonctionnent pour moi.
Votre caractère générique *.example.com
ne pas couvre le domaine racine example.com
mais couvrira toute variante d'un sub - domaine tel que www.example.com
ou test.example.com
La méthode préférée consiste à établir des noms de substitution de sujet, comme dans réponse de Fabian , mais gardez à l’esprit que Chrome requiert actuellement que le nom commun soit également répertorié en tant que nom de substitution de sujet (comme cela est correctement démontré dans sa réponse). J'ai récemment découvert ce problème parce que j'avais le nom commun example.com
avec les réseaux SAN www.example.com
et test.example.com
, mais l'avertissement NET::ERR_CERT_COMMON_NAME_INVALID
de Chrome. J'ai dû générer une nouvelle demande de signature de certificat avec example.com
comme nom commun et l'un des réseaux de stockage. Ensuite, Chrome a pleinement approuvé le certificat. Et n'oubliez pas d'importer le certificat racine dans Chrome en tant qu'autorité de confiance pour l'identification de sites Web.
Je pense que cela peut être un bug en chrome. Il y avait un problème similaire il y a longtemps: Voir ceci.
Essayez dans un autre navigateur. Je pense que ça devrait marcher.
Il existe une solution pour tous ceux qui rencontrent ce problème et qui souhaitent accepter le risque de le tester: passez en mode navigation privée dans Chrome pour pouvoir ouvrir "Avancé" et cliquer sur "Continuer vers .url ".
Cela peut être utile si vous devez consulter un site Web que vous gérez vous-même et que vous ne testez qu'en tant que développeur (et que vous n'avez pas encore configuré le certificat de développement approprié).
Bien sûr, ce n’est PAS POUR LES PERSONNES utilisant un site Web en production où cette erreur indique un problème de sécurité du site Web.
Si vous êtes fatigué de cette erreur. Vous pouvez faire en sorte que Chrome ne se comporte pas de la sorte. Je ne dis pas que c'est le meilleur moyen de dire que c'est un moyen.
Pour contourner le problème, une clé de registre Windows peut être créée pour permettre à Google Chrome d'utiliser le nom commun d'un certificat de serveur pour correspondre à un nom d'hôte si le certificat manque une extension subjectAlternativeName, à condition qu'il valide et chaîne avec succès. certificats d'autorité de certification installés localement.
Type de données: Boolean [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:
Ouvrez le Bloc-notes Copiez et collez le contenu suivant dans le bloc-notes Éditeur du registre de Windows, version 5.00
[HKEY_LOCAL_MACHINE\LOGICIEL\Policies\Google\Chrome] "EnableCommonNameFallbackForLocalAnchors" = dword: 00000001 Allez dans Fichier> Enregistrer en tant que nom de fichier: nom_fichier.reg Enregistrer en tant que type: Tous les fichiers
Sélectionnez un emplacement préféré pour le fichier
Cliquez sur Enregistrer
Double-cliquez sur le fichier sauvegardé à exécuter
Cliquez sur Oui dans l'avertissement de l'éditeur de registre.
Vous avez trouvé ces informations sur la page de support Symantec: https://support.symantec.com/en_US/article.TECH240507.html