O Chrome apresenta um erro SSL devido à utilização do domínio de nível .local

Question

I just replaced the SSL cert on a few of our servers (all hosted on IIS7). At the suggestion of our IT manager, we're using a Subject Alternative Name certificate instead of individual certs for each server. We bought this cert from Digicert (it's not self-signed.) I have installed the certificate on our servers and the sites load without warning and show good locks in Firefox and Internet Explorer. However, Chrome displays a red "x" through the lock icon and strikethrough font for the "https" portion of the URL. The Connection tab displays the following error:

"The identity of this website has not been verified. The identity of the server you are connected to cannot be fully validated. You are connected to a server using a name only valid within your network, which an external certificate authority has no way to validate ownership of. As some certificate authorities will issue certificates for these names regardless, there is no way to ensure you are connected to the intended website and not an attacker."

Clicking on "Certificate Information" shows me the full chain of certs (our cert, Digicert's intermediate cert and Digicert's CA cert) and the certificate status for all three shows as "This certificate is OK.". I have quadruple checked that the hostname I am using in the URL is an exact match for either the common name or one of the subject alternative names in the cert. The previous cert we had on these sites was a wildcard cert for *.mycompany.local, while the new common name and SAN names are for specific hosts within the mycompany.local domain (i.e. eng-wiki.mycompany.local).

The explanation from Chrome almost sounds as though it has detected that an internal DNS server was used to resolve the IP of the server, but that was the case with the old wildcard cert as well, and if that were a valid reason to claim that the identity couldn't be verified, it should have failed the same way with the old wildcard cert (but it did not.) Moreover, that explanation would imply that no company internal servers can have their identity verified, which does a lot more harm to security than good, since we'll all have to teach our users to ignore the security warnings in Chrome despite having dropped hundreds of dollars on a legit cert specifically to avoid that.

I'd be grateful for any help.

Thanks!

- editar -

Procurando ainda hoje, pesquisei a fonte do Chromium em busca do texto de a mensagem de erro e descobriu que o problema é causado pelo Chrome concluindo que o nome do host não é exclusivo. Existem outros posts denunciar este problema como este com os certificados SAN quando usando um nome curto para seu URL. Mas eu estou usando um totalmente qualificado nome do servidor, por exemplo, wiki.mycompany.local

O código que determina meu nome de host como não exclusivo é aqui , e vejo alguns comentários discutindo gTLDs que suspeito serem a causa principal. Eu Não sei muito sobre domínios globais de nível superior, mas minha empresa usa o pseudo-TLD local. Wikipedia parece dizer que isso não é mais um boa idéia (eu não posso fazer 3 links b / c minha reputação é muito baixa no servidor falha, por favor, sinta-se livre para editar isso e torná-lo um link en.wikipedia.org/wiki/.local), embora tenha sido recomendado prática há muitos anos, quando nossa equipe de TI montou nossa rede. Não é um coisa fácil de pedir-lhes para mudar agora

Estou tentado a editar minha pergunta para remover o elemento SAN do equação, exceto que eu não tive esse problema ao usar um curinga cert para mycompany.local. Então, eu ainda suspeito que o uso de um certificado SAN é parte da questão. Ainda grato por qualquer ajuda.

    

Answer 1

Moreover, that explanation would imply that no company internal servers can have their identity verified, which does a lot more harm to security than good, since we'll all have to teach our users to ignore the security warnings in Chrome despite having dropped hundreds of dollars on a legit cert specifically to avoid that.

Mas eles não podem ter sua identidade verificada por terceiros, independentemente do custo do certificado.

Apenas uma empresa pode "possuir" contoso.com na Internet pública, e essa empresa pode especificar o que server1.contoso.com é e ninguém mais pode.

DigiCert (ou quem) pode verificar se a solicitação de certificado para server1.contoso.com é proveniente da mesma empresa que possui contoso.com e, portanto, (provavelmente) não é uma solicitação fraudulenta. Eles também podem emitir um certificado para server1.contoso.com e não mais.

Qualquer um pode ter contoso.local. Muitas pessoas de uma só vez. O Digicert não pode fazer nada para verificar se você tem ou não servidores com esse nome. E eles podem emitir certificados para esse nome várias vezes para pessoas diferentes.

O aviso de segurança é um aviso genuíno - o Chrome não pode verificar se este é o servidor pretendido1.contoso.local porque o mesmo certificado pode ser instalado em mil computadores chamados "server1.contoso.local" em todo o mundo. / p>

Se você está pensando em colocar os dados do seu cartão de crédito em um site, um certificado local não deve tranquilizá-lo muito.

Aparentemente, o IE e o FireFox têm visões diferentes sobre isso, optando por fingir que está tudo bem, quando na verdade não é.

Torne seu servidor acessível por um FQDN real e compre um certificado para isso.

    

Answer 2

O DigiCert não lista o Chrome como um navegador suportado no site . Como discutido em outro lugar , a interpretação de uma SAN depende da implementação do SSL, e suspeito que o Chrome possa fazer o Something Weird (tm) em comparação com o Firefox ou o Internet Explorer.

Por acaso você está usando um endereço IP no SubjectAltName ? Observar um dos exemplos de códigos on-line do Chrome App parece indicar que eles esperam um nome de host em lá (e não um IP).

    

Answer 3

Isso é bastante simples e resume-se a Autenticação. Como TessellatingHeckler declarou, o aviso de segurança é genuíno e há uma solução alternativa para isso. Isso não é um defeito no Chrome, mas sim uma abordagem proativa às melhores práticas de segurança que o IE ou o FF podem precisar para acompanhar. Você já se perguntou por que algumas CAs ainda estão vendendo certificados de 5 anos, enquanto outras vendem apenas 3 anos? Há uma mudança no período de validade do certificado em breve também.

Quando um certificado de OV (Organizational Validated) é emitido, a autoridade de certificação deve autenticar que o domínio está totalmente registrado em um registrador de domínio e que a empresa tem o direito de usá-lo. Ele faz isso consultando o WHOIS e o D & B para verificar essas informações. Qualquer coisa que seja .com / .net / .edu por exemplo. Por outro lado, um .local pode ser de propriedade de qualquer pessoa e não pode ser autenticado por nenhuma CA. Não tenho certeza de como a autenticação foi feita na Digicert, mas não deveria. Quando você compra um certificado SSL, você paga mais por Autenticação do que qualquer outra coisa.

Aqui está um link do fórum do navegador da CA informando que, até outubro de 2016, o uso de todos os nomes internos será eliminado para melhores práticas de segurança. Espero que isso traga alguma luz para a equipe de gerenciamento de TI e que eles adotem uma abordagem proativa em vez de esperar até o último minuto.

link

Posso perguntar por quantos anos este certificado é válido? A razão que eu pergunto é que há uma solução por enquanto para que você possa classificar as configurações do servidor em relação ao nome interno. Quando você gerar o CSR, coloque o nome comum como www.suaempresa.com e no campo SAN, insira "suaempresa.local" Dessa forma, quando a CA estiver em processo de autenticação, ela poderá verificar se você tem os direitos para www.suaempresa.com e no campo SAN, o endereço IP da suaempresa.local também será protegido. Essa solução alternativa é sensível ao tempo, já que nenhuma autoridade de certificação emitirá um certificado de três anos nessas condições, se o período de validade for aprovado na alteração obrigatória.

Espero que a informação seja útil.