La calificación A + aún no es segura según la opinión de Google Chrome

Estoy aprovisionando mi servidor en DigitalOcean , y aunque obtengo una calificación A + de ssllabs,

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

cuando me conecto a mi sitio, https://www.zandu.biz o https://zandu.biz , recibo un aviso no seguro dentro de Chrome.

¿Cómo puedo solucionar esto?

ssl apache-2.4 lets-encrypt

— El arquitecto
fuente

Este servidor no pudo probar que es www.zandu.biz; Su certificado de seguridad es de zandu.biz. Esto puede ser causado por una configuración incorrecta o un atacante que intercepta su conexión.

El nombre en el certificado de su sitio es zandu.biz, que no es válido para un nombre diferente (www.zandu.biz). Además, tiene una redirección de zandu.biz a www.zandu.biz, por lo que si utiliza el nombre, el certificado es válido, ya que redirige al nombre que no lo es.

Lo que necesita es obtener un certificado con ambos nombres .

— zrm
fuente

Los certificados comodín pueden ser más convenientes o necesarios si los nombres que desea utilizar no se conocen con anticipación. Pero también aumentan su exposición si la clave privada asociada se ve comprometida porque el atacante puede falsificar cualquier nombre en su dominio en lugar de solo los que el servidor estaba usando realmente.

— zrm

Let's Encrypt es una CA. Cuando comenzaron, IdenTrust los firmó de forma cruzada, pero eso termina en 2020 porque su propio certificado raíz ahora es de gran confianza. Nada de eso tiene nada que ver con su problema, que habría sido lo mismo de cualquier manera.

— zrm

s / Nombre común / Nombre alternativo del sujeto / - Chrome no ha usado el Nombre común en absoluto durante 2 años; otros navegadores lo hacen solo si SAN está ausente, lo que no ha sido cierto para ningún certificado (EE) de CA públicas desde antes de 2010, aunque puede organizarlo para los certificados de prueba que usted mismo cree. Es exactamente por eso que puede obtener un certificado para múltiples dominios: los certificados antiguos que usan solo Nombre común no podrían hacer eso.

— dave_thompson_085

@djdomi un certificado comodín para *.example.comtodavía no cubre el dominio desnudo example.com. Aún necesita dos valores en la SAN.

— Michael - sqlbot

La razón más importante para evitar un certificado comodín es que OP está usando LetsEncrypt. Si bien LetsEncrypt admite certificados comodín, esto requiere un desafío de DNS. Satisfacer un desafío de DNS es más difícil de automatizar. Además, automatizar un desafío de DNS puede significar que un servidor comprometido otorgará a los atacantes acceso a su DNS. Por lo tanto, es suficiente usar un certificado UCC o dos certificados (cuyo enfoque no importa mucho. Haga lo que sea más fácil).

— Brian