Si eres técnico de servidores o desarrollador, es muy probable que te hayas topado con este frustrante escenario: acabas de instalar un certificado SSL en un servidor IIS para un cliente, todo parece funcionar bien en tu PC, pero de repente el cliente te llama. “Nuestros usuarios no pueden entrar desde sus iPhones”, te dicen. “Les sale un error de que la conexión no es privada”.
Empiezas a ver capturas de pantalla con mensajes como:
NET::ERR_CERT_AUTHORITY_INVALIDen Chrome.- “Safari no puede abrir la página porque no pudo establecer una conexión segura con el servidor”.
- O simplemente, “La conexión no es privada”.
Lo primero que muchos piensan es: “¿Será que el certificado no es compatible con móviles?”. Déjame ahorrarte el suspense: el certificado está bien. El problema es mucho más sutil y tiene que do con cómo tu servidor se presenta al mundo.
Este artículo te guiará a través del diagnóstico y la solución definitiva para este problema, basado en un caso de cliente real.
El Diagnóstico: ¿Por Qué mi iPhone no confía en mi servidor?
La razón por la que este error aparece con más frecuencia en dispositivos móviles (especialmente en iOS) es que sus sistemas operativos son más estrictos en cuanto a las reglas de seguridad SSL/TLS. No les basta con ver tu certificado; necesitan ver toda la “cadena de confianza” que lo respalda.
Piénsalo como una cadena de referencias laborales:
- Certificado Raíz (Root CA): Es una autoridad mundialmente reconocida (como Sectigo, Let’s Encrypt, etc.). Los sistemas operativos vienen con una lista preinstalada de estos “grandes jefes” en los que confían ciegamente.
- Certificado Intermedio: Son los “gerentes regionales” autorizados por un gran jefe. El Certificado Raíz firma digitalmente al Intermedio, dándole autoridad.
- Tu Certificado de Servidor: Es tu credencial personal, firmada por un “gerente regional” (el Intermedio).
Cuando un navegador estricto como Safari en un iPhone se conecta, espera que tu servidor le presente los tres documentos en orden. Si tu servidor solo le muestra tu certificado, el iPhone dice: “Conozco al gran jefe, pero no conozco a este gerente que te firmó a ti, y como no me presentas la prueba de que trabaja para el jefe, no confío”.
Ahí es donde se produce el error NET::ERR_CERT_AUTHORITY_INVALID.
Herramientas para Confirmar el Problema
Antes de tocar nada, confirma el diagnóstico. La mejor herramienta para esto es SSL Labs Server Test de Qualys.
Introduce el dominio de tu servidor. Si ves lo siguiente, has encontrado al culpable:
- Una calificación general de “B”.
- Una advertencia clara que dice “Chain issues: Incomplete”.
Esta prueba confirma que tu servidor no está enviando el certificado intermedio, y esa es la única razón del problema.
La Solución Definitiva: Generar e Instalar el PFX Correctamente
El cliente de nuestro caso de estudio nos dijo: “Pero si ya generé el archivo .pfx”. Esto es muy común. El problema no es tener un PFX, sino cómo se generó e instaló. Un .pfx debe contener la cadena completa.
Sigue estos pasos para solucionarlo para siempre.
Paso 1: Junta tus Archivos
Asegúrate de tener los tres componentes que te entregó tu proveedor de certificados:
- Tu certificado de servidor (ej:
tudominio.crt). - Tu clave privada, que generaste junto al CSR (ej:
tudominio.key). - El archivo “bundle” de la autoridad de certificación (ej:
My_CA_Bundle.ca-bundle). Este es el archivo más importante y el que suele olvidarse.
Paso 2: Genera el PFX con OpenSSL
La forma más segura y fiable de crear un .pfx completo es usando OpenSSL en la terminal. Evita a toda costa los conversores online, ya que te obligan a subir tu clave privada, lo cual es un riesgo de seguridad enorme.
Abre una terminal y ejecuta este comando, reemplazando los nombres de archivo con los tuyos:
openssl pkcs12 -export -out tudominio_completo.pfx -inkey tudominio.key -in tudominio.crt -certfile My_CA_Bundle.ca-bundle