Mientras trabajaba en un escenario, recibí el mensaje de error "Los certificados del servidor no coinciden con la URL".
¿Es necesario que el certificado otorgado desde el sitio web tenga su URL? ¿Es necesario que el certificado tenga el nombre completo de la URL o también funcionará si uso una parte de la URL?
Primero, no es una URL, es un nombre de host o nombre de dominio. El nombre del host es una parte de la URL. http://security.stackexchange.com/questions/92838/is-it-neccessary-the-website-certificate-must-have-site-url es una URL y el nombre de host es security.stackexchange.com .
A continuación, sí, al menos un nombre de host en el certificado debe coincidir con el nombre de host exacto utilizado para acceder al sitio. Puede obtener certificados de comodín, por ejemplo, * .example.com, que coincidirá con < cualquier cosa > .example.com (pero no < nada >. < nada > .example.com o example.com).
Sí, el nombre de host en el certificado debe coincidir con la parte del nombre de host de la url desde la que se solicita el certificado. Ese es un requisito porque existe la expectativa de que SSL no solo asegure la comunicación (cifrado) sino que también garantice que el usuario se conecte al servidor adecuado (autenticación). Sin ese requisito sería trivial engañar a los usuarios con un ataque MITM. El usuario navega por enlace , el pirata informático de MITM no puede crear un certificado válido firmado por CA para example.com, por lo que solo usa cualquier certificado válido. El usuario ve que la url es enlace y tiene seguridad SSL, por lo que debe estar seguro, ¿no? No, él está conectado al servidor de hackers. Así que el navegador avisará al usuario. Oye, intentaste ir a enlace , el ejemplo real.com hubiera proporcionado un certificado para example.com pero obtuve algo diferente, muy probable que estés bajo ataque en este momento.
Un escenario común que conduce a errores es solicitar un certificado con un nombre de host de www. * como www.example.com. Todo está bien si el usuario intenta ir a enlace , pero si decide que desea unirse al siglo 21 y manejar el tráfico en enlace el usuario recibirá un error (tampoco puede redirigir sin un error diferente). El usuario está intentando ir a example.com pero obtiene un certificado para un nombre de host diferente (www.example.com).
Es una práctica (semi) estándar para la CA incluir www. * como un nombre alternativo para cert cuando el nombre de host solicitado es un dominio raíz (no hay subdominio). Una solicitud de un certificado con un nombre de host de example.com funcionará con enlace y enlace pero si la solicitud de un certificado para www.example.com solo funcionará con enlace .
Puede obtener un segundo certificado emitido para manejar el tráfico de enlace y usar el certificado único de www existente para enlace pero eso no tiene sentido ya que el nuevo certificado puede manejar ambos nombres de host. Es posible que desee comprobar si su CA volverá a emitir un certificado con el nombre de host raíz en lugar de www de forma gratuita. Dudo que lo hagan, pero podrían hacerlo especialmente si se trata de un certificado más caro.
Parece que algunas CA (ver comentarios) ahora harán lo contrario y para un certificado solicitado en www.example.com agregaremos example.com como un nombre alternativo. Nada puede ser simple, supongo. Consulte con su CA y los detalles del certificado. Para evitar las advertencias del navegador, el nombre de host de la url que se está utilizando debe aparecer en el certificado como nombre de host o nombre alternativo del sujeto.
Encontré la respuesta de (RFC2818) enlace Segun rfc Si una extensión subjectAltName de tipo dNSName está presente, DEBE utilizarse como la identidad. De lo contrario, DEBE usarse el campo Nombre común (más específico) en el campo Asunto del certificado. Si bien el uso del Nombre común es una práctica existente, está en desuso y se recomienda a las Autoridades de certificación que usen el nombreDNS.
También podemos usar Ip's, y como @mike dijo que puede ser un nombre de host con un operador comodín.
Mike Scott publicó una gran respuesta. Pero podría valer la pena señalar por qué importa. En un nivel técnico sus datos todavía estarán encriptados. Sin embargo, sus usuarios pueden ser rechazados porque no pueden confiar en el certificado, ya que la mayoría de los navegadores les avisarán del error y, por lo general, los harán realizar pasos adicionales a través de los mensajes de advertencia. Los mensajes están hechos para que parezcan aterradores a propósito, en un intento de rechazar incluso a los usuarios no técnicos. En algunos casos, es posible que un navegador nunca les permita visitar su sitio. En general no lo hagas. Su sitio de producción nunca debe cortar esquinas cuando se trata de seguridad.
Lea otras preguntas en las etiquetas public-key-infrastructure tls