Impossible de se débarrasser de l'erreur «net :: ERR_CERT_COMMON_NAME_INVALID» dans Chrome avec des certificats auto-signés

19

Il existe de nombreuses questions sur le Web où les gens ont du mal à configurer des certificats auto-signés à utiliser sur le réseau interne.

Juste pour en relier quelques-uns:
obtenir que Chrome accepte le certificat localhost auto-signé
Chrome accepter le certificat localhost auto-signé
Génération d'un certificat auto-signé avec openssl qui fonctionne dans Chrome 58
Certificat StartCom Erreur: ERR_CERT_AUTHORITY_INVALID

J'ai parcouru chacun d'eux, mais je ne peux toujours pas me débarrasser de l' (net::ERR_CERT_COMMON_NAME_INVALID).erreur.

Étapes suivies:

  • génération de clés et de certificats sur le serveur

    openssl req \          
    -newkey rsa:2048 \
    -x509 \
    -nodes \
    -keyout file.key \
    -new \
    -out file.crt \
    -subj /CN=Hostname \
    -reqexts SAN \
    -extensions SAN \
    -config <(cat /etc/ssl/openssl.cnf \
        <(printf '[SAN]\nsubjectAltName=DNS:192.168.0.1')) \
    -sha256 \
    -days 3650
    
  • configuration du processus serveur (apache) pour utiliser le certificat et le fichier de clés nouvellement générés pour des connexions sécurisées

  • exporter le fichier de certificat du serveur vers le client en accédant à https://192.168.0.1:3122 via Chrome Dev Tools et en utilisant l' option Exporter
  • ajout de l'AC à la liste des autorités de certification connues (sur Fedora 26) à l'aide
    • certutil
    • sudo cp file.crt /etc/pki/ca-trust/source/anchors; sudo upate-ca-trust
  • redémarrage de chrome

J'ai aussi essayé différentes valeurs pour le CNchamp ci - dessus comme: hostname, common.name.com, Common Name,192.168.0.1

Même après tout cela, l'erreur persiste lorsque je navigue vers https://192.168.0.1:3122 et je ne sais plus ce que je fais.

La représentation du texte ressemble à:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            9e:ae:33:24:3a:2d:2b:e2
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = Hostname
        Validity
            Not Before: Oct 28 20:18:06 2017 GMT
            Not After : Oct 26 20:18:06 2027 GMT
        Subject: CN = Hostname
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a4:80:6c:3a:1b:5e:c4:e6:f6:7d:a5:be:d6:cd:
                    d9:23:bd:1a:b1:e6:f1:e3:b0:76:47:37:a3:d8:b0:
                    60:44:23:c3:8a:58:1c:c3:0a:99:3d:42:32:ca:8b:
                    ec:31:9d:a8:df:6c:13:43:e6:78:12:b8:24:04:5a:
                    9f:6e:11:24:2a:56:e3:20:36:78:a4:cc:ed:45:7c:
                    a3:c1:36:7b:25:f6:6b:2d:01:59:02:74:8b:7a:13:
                    ec:83:63:90:2e:a0:a3:aa:23:de:ea:f0:8e:1f:99:
                    b9:50:b1:5f:64:e4:c9:91:c0:0c:56:15:3c:c0:ff:
                    0f:bf:e1:af:7a:bf:51:40:37:b0:34:20:95:a1:05:
                    14:k2:35:20:e8:98:48:65:ad:26:cc:de:a2:50:48:
                    77:8c:e2:7a:d5:bd:83:96:86:ef:20:79:2f:15:a3:
                    07:48:f4:1f:c7:9d:a1:4b:bd:ee:47:83:51:f3:09:
                    27:ed:b7:09:c8:56:40:0c:68:25:92:d8:62:dc:14:
                    6c:fa:f1:e3:93:1b:79:3c:58:9c:53:69:ff:6a:0f:
                    ee:4c:9f:8e:22:2d:62:6b:b3:ae:22:d6:e3:d0:bd:
                    06:43:a7:c3:e1:1e:23:07:61:b0:4e:64:14:92:0c:
                    5b:f1:a8:c5:29:67:64:7d:65:10:b9:60:41:b8:3b:
                    1y:1f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:192.168.0.1
    Signature Algorithm: sha256WithRSAEncryption
         11:65:6d:86:04:7f:5a:b0:ce:b2:6e:95:7e:03:8c:fe:a9:d0:
         81:2c:6f:50:63:2e:91:77:79:cd:27:32:b0:19:2b:ac:ea:c0:
         4b:f7:56:d9:be:34:54:f1:a6:1d:bc:d0:3b:bb:bf:90:0e:2d:
         1d:83:28:97:8e:f8:37:5d:3e:00:5a:cd:3d:36:5d:c4:5d:a8:
         7e:a4:59:f0:91:3d:af:3d:28:03:3e:78:3b:5b:0a:fb:24:34:
         02:a2:09:ec:d6:0c:58:63:ab:69:26:5e:fe:1d:1f:19:54:0f:
         68:4e:31:f9:de:1e:de:86:81:3f:b7:62:c5:67:02:05:a2:7a:
         03:f4:b5:3b:ba:c4:ba:26:8e:a2:ee:1c:ef:69:63:07:b0:97:
         fd:a8:42:e2:11:6d:de:b5:70:a5:4a:62:d2:62:d9:5b:17:f4:
         d5:cd:6f:71:75:dd:35:33:55:52:2e:30:29:f8:42:ec:b9:d3:
         82:85:a1:e7:f6:f5:90:dd:cb:07:15:a7:44:70:1c:93:e6:ec:
         03:3a:be:41:87:3c:f0:a4:88:a5:65:d9:29:2c:78:de:90:b8:
         6a:8b:99:6e:d0:e5:8c:08:a4:71:51:fd:1d:e1:8c:0c:17:d5:
         b0:31:fc:7f:99:23:dd:1a:c4:0b:45:17:68:88:67:c6:22:df:
         2b:ac:ea:c0

Veuillez noter qu'il s'agit de ma première configuration de certificats SSL / TLS à ces fins. S'il vous plaît des conseils sur la façon de se débarrasser de l'erreur.

Ashesh Kumar Singh
la source
Ajoutez une représentation textuelle de votre certificat à votre question. Utilisez openssl x509 -noout -text -in <filename>.
garethTheRed
J'ai ajouté la représentation textuelle.
Ashesh Kumar Singh
Je pense que Chrome s'attend à ce que l'adresse IP soit codée en tant qu'adresse IP dans l'extension SAN, pas un nom DNS.
Crypt32

Réponses:

25

Chrome 58+ ne correspond plus au nom commun ( CN) dans les certificats.

Maintenant, il utilise à la place des noms de sujet alternatifs ( SAN).

SANdoit contenir une bonne DNSou IPentrée.

  • Lorsque DNS est utilisé, il doit s'agir d'un nom de domaine complet résolvable.
  • Lorsqu'une adresse IP est utilisée, elle doit être explicitement spécifiée comme telle dans la SANchaîne.

Cela dit, cela devrait fonctionner:

openssl req \
-newkey rsa:2048 \
-x509 \
-nodes \
-keyout file.key \
-new \
-out file.crt \
-subj /CN=Hostname \
-reqexts SAN \
-extensions SAN \
-config <(cat /etc/ssl/openssl.cnf \
    <(printf '[SAN]\nsubjectAltName=DNS:hostname,IP:192.168.0.1')) \
-sha256 \
-days 3650
krisFR
la source
1
Plus précisément, cela est dû à tools.ietf.org/html/rfc6125#section-5.7.3.1 qui indique «Pour l'authentification TLS avec les certificats X.509, une identité de l'espace de noms DNS DOIT être vérifiée par rapport à chaque extension subjectAltName de type dNSName présente dans le certificat. Si une telle extension n'est pas présente, alors l'identité DOIT être comparée au nom commun (le plus spécifique) dans le champ Objet du certificat. " Donc, si un SAN existe, le CN n'est pas vérifié.
Jason Martin
7
Corrigez-moi si je me trompe, mais Chrome n'accepte plus les certificats qui reviennent au nom commun. Ainsi, même si un SAN n'existe pas, le CN n'est pas vérifié. Le SAN semble donc obligatoire.
krisFR
@krisFR a raison car j'ai déjà essayé avec des certificats sans l'extension SAN qui a échoué. La spécification du champ IP était la solution.
Ashesh Kumar Singh
1
Épargnant de vie. Pour ceux qui essaient cela sous Windows, Cygwin est livré avec une copie de openssl.cnf ici:. \ Cygwin \ etc \ defaults \ etc \ pki \ tls \ De plus, j'ai dû changer mon CN = nom d'hôte et DNS: les lignes du nom d'hôte à localhost au lieu de hostname
abelito
Fonctionne parfaitement! J'ai dû ajouter le certificat avec cette procédure: corvil.com/kb/…
yota