Classificação A + ainda insegura pela opinião do Google Chrome

Estou provisionando meu servidor no DigitalOcean e, embora esteja recebendo uma classificação A + do ssllabs,

https://www.ssllabs.com/ssltest/analyze.html?d=zandu.biz

quando me conecto ao meu site, https://www.zandu.biz ou https://zandu.biz , recebo um aviso não seguro no Chrome.

Como eu resolvo isso?

ssl apache-2.4 lets-encrypt

— O arquiteto
fonte

Este servidor não pôde provar que é www.zandu.biz; o certificado de segurança é do zandu.biz. Isso pode ser causado por uma configuração incorreta ou por um invasor que interceptou sua conexão.

O nome no certificado do seu site é zandu.biz, que não é válido para um nome diferente (www.zandu.biz). Além disso, você tem um redirecionamento de zandu.biz para www.zandu.biz, portanto, se você usar o nome, o certificado será válido, pois ele será redirecionado para o nome que não é.

O que você precisa é obter um certificado com os dois nomes .

— zrm
fonte

Os certificados curinga podem ser mais convenientes ou necessários se os nomes que você pretende usar não forem realmente conhecidos antecipadamente. Mas eles também aumentam sua exposição se a chave privada associada for comprometida, pois o invasor pode forjar qualquer nome em seu domínio, e não apenas os que o servidor estava realmente usando.

— Zrm 14/08/19

Vamos criptografar é uma autoridade de certificação. Quando eles começaram, eles foram assinados pela IdenTrust, mas isso termina em 2020 porque seu próprio certificado raiz agora é amplamente confiável. Nada disso tem nada a ver com o seu problema, que teria sido o mesmo de qualquer maneira.

— zrm 15/08/19

s / Nome comum / Nome alternativo / - Chrome não usou Nome comum a todos por 2 anos; outros navegadores fazem isso apenas se a SAN estiver ausente, o que não é verdade para nenhum certificado (EE) de CAs públicas desde antes de 2010, embora você possa organizá-lo para certificados de teste criados por você. É exatamente por isso que você pode obter um certificado para vários domínios - certificados antigos usando apenas o Common Name não podiam fazer isso.

— Dave_thompson_085 15/08/19

@djdomi um certificado curinga para *.example.comainda não cobre o domínio básico example.com. Você ainda precisa de dois valores na SAN.

— Michael - sqlbot

O maior motivo para evitar um certificado curinga é que o OP está usando LetsEncrypt. Embora o LetsEncrypt ofereça suporte a certificados curinga, isso exige um desafio de DNS. Satisfazer um desafio de DNS é mais difícil de automatizar. Além disso, automatizar um desafio de DNS pode significar que um servidor comprometido concederá aos invasores acesso ao seu DNS. Portanto, é suficiente usar um certificado UCC ou dois certificados (cuja abordagem não importa muito. Faça o que for mais fácil).

— Brian