tengo unempresa.svdominio y recientemente compré un certificado comodín RapidSSL, lo instalé y lo probé con muchos navegadores (Firefox, Chromium, Chrome, IE) y herramientas de verificación SSL, funcionó bien en todos excepto en Google Chrome ni en Windows, Linux ni Android.
Cada vez que accedo al sitio web a través de Google Chrome aparece una advertencia que dice que intenté accederwww.empresa.svocualquier.empresa.svpero el servidor se identifica como **.empresa.sv*. Si continúo a pesar de la advertencia y hago clic en el candado rojo, me dice que estoy conectado a un servidor que sólo es válido dentro de mi red y no puede ser validado a través de una entidad de certificación externa.
Me comuniqué con el servicio de soporte del revendedor de certificados pero no pudieron darme una respuesta directa sobre cuál era el problema. Me he estado preguntando si tiene algo que ver con que el TLD sea.sv. También revisé el código fuente de Chromium, pero parece un poco inútil ya que el certificado funciona perfectamente en Chromium.
Tal vez valga la pena mencionar que estoy usando NGINX en un servidor Ubuntu 12.04 y que probé un certificado de dominio único gratuito de Comodo antes de comprar el comodín.
Respuesta1
Parece que olvidó instalar el paquete de certificados intermedios en su servidor web. Visite el sitio web del proveedor del certificado para descargar el paquete intermedio.
Para nginx, esto debe concatenarse con su certificado y colocarse en la ssl_certificatedirectiva, por ejemplo:
# cat company.sv.crt ca_bundle.crt > company.sv.chained.crt
Y en tu configuración de nginx:
ssl_certificate /etc/path/to/company.sv.chained.crt
Respuesta2
Sospecho que tiene el nombre del sitio en el campo Asunto CN=, debe estar en el campo de nombre alternativo del asunto para que Chrome lo acepte. si muestra el certificado en el navegador, o conopenssl x509 -in certificate-file -text
Ver:
Estos requisitos básicos exigen que las autoridades certificadoras siempre incluyan al menos un Nombre alternativo del sujeto en los certificados SSL que emiten, esto significa que hoy en día una aplicación no necesita buscar tanto en el Nombre común como en el Nombre alternativo del sujeto; solo necesita verificar el último.
Actualmente, la mayoría de las autoridades de certificación también incluirán el primer nombre DNS del nombre alternativo del sujeto en el campo Nombre común, pero esto se hace principalmente por razones heredadas y en algún momento en un futuro no muy lejano se detendrá.
Los certificados tienen dos formas de expresar el dominio/IP al que están vinculados: una que no está estructurada y es ambigua (commonName) y otra que está bien definida (subjectAltName). En ausencia de cualquier sujetoAltNames, Chrome actualmente recurre a comparar el dominio con el nombre común, si está presente.
Esta propuesta tiene como objetivo eliminar ese camino alternativo; de hecho, requiere un sujetoAltName. Idealmente, haríamos esto para todos los certificados (de confianza pública y privada), pero si existen dudas sobre el riesgo de compatibilidad, podemos restringirlo a los certificados de confianza pública.