Não é possível se livrar do erro `net :: ERR_CERT_COMMON_NAME_INVALID` no chrome com certificados autoassinados


19

Existem inúmeras perguntas na web em que as pessoas estão tendo dificuldade em configurar certificados autoassinados para uso na rede interna.

Apenas para vincular alguns:
Fazer o Chrome aceitar o certificado de host local autoassinado O
Chrome aceitar o certificado de host local autoassinado
Gerar um certificado autoassinado com openssl que funciona no certificado StartCom do Chrome 58
Erro: ERR_CERT_AUTHORITY_INVALID

Passei por todos e cada um deles, mas ainda não consigo me livrar do (net::ERR_CERT_COMMON_NAME_INVALID).erro.

Passos seguidos:

  • geração de chave e certificado no servidor

    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
    
  • configurando o processo do servidor (apache) para usar o certificado e o arquivo de chave recém-gerados para conexões seguras

  • exportando o arquivo de certificado do servidor para o cliente, navegando para https://192.168.0.1:3122 através do Chrome Dev Tools e usando a opção Exportar
  • adicionando a CA à lista de autoridades de certificação conhecidas (no Fedora 26) usando
    • certutil
    • sudo cp file.crt /etc/pki/ca-trust/source/anchors; sudo upate-ca-trust
  • reiniciando o chrome

Eu também tentei vários valores para o CNcampo acima como: hostname, common.name.com, Common Name,192.168.0.1

Mesmo depois de tudo isso, o erro persiste quando eu navego para https://192.168.0.1:3122 e não sei mais o que estou fazendo.

A representação de texto é semelhante a:

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

Observe que esta é a minha primeira vez que configuro certificados SSL / TLS para esses fins. Por favor, conselhos sobre como se livrar do erro.


Adicione uma representação de texto do seu certificado à sua pergunta. Use openssl x509 -noout -text -in <filename>.
garethTheRed

Eu adicionei a representação de texto.
Ashesh Kumar Singh

Eu acho que o Chrome espera que o endereço IP seja codificado como endereço IP na extensão SAN, e não um nome DNS.
Crypt32 # 28/17

Respostas:


25

O Chrome 58 ou superior não corresponde mais ao Nome comum ( CN) em alguns certificados.

Agora, ele usa Nomes alternativos para assuntos ( SAN).

SANdeve conter adequada DNSou IPentrada.

  • Quando o DNS é usado, ele deve ser um nome resolvível do FQDN.
  • Quando um endereço IP é usado, ele deve ser especificado explicitamente como tal dentro da SANcadeia.

Dito isto, isso deve funcionar:

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

1
Especificamente, isso ocorre devido a tools.ietf.org/html/rfc6125#section-5.7.3.1, que declara "Para autenticação TLS com certificados X.509, uma identidade do espaço para nome DNS DEVE ser verificada em cada extensão subjectAltName do tipo dNSName presente Se essa extensão não estiver presente, a identidade DEVE ser comparada com o (mais específico) Nome Comum no campo Assunto do certificado. " Portanto, se houver uma SAN, a CN não será verificada.
26617 Jason Martin

7
Corrija-me se estiver errado, mas o Chrome não aceita mais certificados que utilizam o nome comum. Portanto, mesmo se uma SAN não existir, a CN não será verificada. Portanto, a SAN parece obrigatória.
krisFR

@krisFR está certo, porque eu já tentei com certificados sem a extensão SAN que falhou. Especificar o campo IP foi a solução.
Ashesh Kumar Singh

1
Poupança de vida. Para qualquer pessoa que tente fazer isso no Windows, o Cygwin vem com uma cópia do openssl.cnf aqui:. \ Cygwin \ etc \ defaults \ etc \ pki \ tls \ Além disso, eu tive que alterar minhas linhas CN = hostname e DNS: hostname para serem localhost em vez de hostname
abelito 17/04

Funcionou perfeitamente! Teve que adicionar o certificado com este procedimento: corvil.com/kb/…
yota 18/10
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.