☰

Por que estou recebendo incompatibilidades de URL no meu certificado curinga autoassinado?

tag-icon • tag-icon apache-2.4 openssl self-signed-certificate
Por que estou recebendo incompatibilidades de URL no meu certificado curinga autoassinado?

Estou tentando configurar um certificado curinga autoassinado para uso pelo Apache, normalmente isso é bastante simples. Acabei de definir um nome alternativo de assunto com o domínio raiz e especificar *.dcrdev.com no campo de nome comum. No entanto, parece que isso não está funcionando - quando tento acessar o site no Chrome ou testá-lo em sslabs, eles relatam incompatibilidades de URL ao acessar qualquer subdomínio, como www.dcrdev.com ou subdomain1.dcrdev.com. Não sei por que, quando visualizo as informações do certificado no Chrome, ele mostra o nome comum como *.dcrdev.com.

Meu RSE:

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=GB, ST=South Yorkshire, L=Sheffield, O=DCR Holdings, OU=DCR Development, CN=*.dcrdev.com/[email protected]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                lah blah

Meu certificado:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1048577 (0x100001)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=GB, ST=South Yorkshire, L=Sheffield, O=DCR Holdings, OU=DCR Root Authority, CN=*.dcrdev.com/[email protected]
        Validity
            Not Before: Oct 13 23:41:03 2015 GMT
            Not After : Oct 10 23:41:03 2025 GMT
        Subject: C=GB, ST=South Yorkshire, L=Sheffield, O=DCR Holdings, OU=DCR Development, CN=*.dcrdev.com/[email protected]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
               Blah blah
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                83:2D:84:F1:E2:B0:72:30:E6:3B:6A:F6:8E:6A:68:8E:3F:D4:69:44
            X509v3 Authority Key Identifier: 
                keyid:F5:A6:82:E2:DD:52:10:CE:FD:C5:C7:E1:E9:CF:C6:8C:30:26:D7:DC

            X509v3 Subject Alternative Name: 
                DNS:dcrdev.com
            X509v3 Key Usage: 
                Digital Signature, Non Repudiation, Key Encipherment
    Signature Algorithm: sha256WithRSAEncryption
        Blah blah

Responder1

Cruzado dehttps://stackoverflow.com/questions/3093112/certificateexception-no-name-matching-ssl-someurl-de-found.

O nome comum do assunto não controla mais certificados HTTPS.

AFAICT, na verdade não existe um padrão dizendo isso, masA prática há alguns anos é que os navegadores, etc., usem a extensão SubjectAlternativeName (SAN) se estiver presente, e CommonName (CN) no Assunto somente se SAN estiver ausente. Seu certificado tem SAN presente dcrdev.com, então apenas isso corresponde.

atualizar:encontrado emRFC2818 3.1:

Se uma extensão subjectAltName do tipo dNSName estiver presente, ela DEVE ser usada como identidade. Caso contrário, DEVE ser usado o campo Common Name (mais específico) no campo Assunto do certificado. Embora o uso do Nome Comum seja uma prática existente, ele está obsoleto e as Autoridades de Certificação são incentivadas a usar o dNSName.

Essa RFC era de maio de 2000, mas, pelo que me lembro, os certificados que encontrei só começaram a usar SAN perto de 2010. O mais recente, de março de 2011RFC6125identificado por @JennyD (funciona no corpo da resposta?) é um tratamento mais geral, mas diz explicitamente

Este documento também não substitui as regras para verificação da identidade do serviço fornecidas nas especificações para protocolos de aplicação existentes publicados antes deste documento, como aqueles extraídos do Apêndice B.

e o apêndice B inclui RFC2818.

Os requisitos básicos deFórum do navegador CAdigo que as CAs devememitircerts com SAN enquanto Subject.CN está obsoleto, embora isso não seja diretamente um requisito para navegadores/clientes.

Se você quiser usar o domínio e os subdomínios (apenas um nível), coloque duas entradas dnsName na SAN, uma para dcrdev.come outra para *.dcrdev.com.

informação relacionada