En iOS 13 se ha aumentado la seguridad respecto a estos certificados Root. Por lo tanto, no se trata de un error, sino que hay que cumplir con mayores requisitos para que esto funcione.
En primer lugar, el proceso para confiar manualmente en el certificado root se ha hecho ligeramente más complicado para garantizar que los usuarios no lo hagan involuntariamente. Antes podías importar un perfil y listo, pero ahora tienes que abrir también Configuración > General > Acerca de > Configuración de la confianza de los certificados, y luego activar "Habilitar la confianza total para los certificados root" para el certificado.
Además del cambio de proceso mencionado, también han cambiado los requisitos para el certificado real:
-
Si utiliza RSA, el tamaño de la clave debe ser de al menos 2048 bites.
-
El algoritmo hash debe ser SHA-2, y no SHA-1.
Puede leer la explicación de Apple al respecto nuevos requisitos aquí . Tenga en cuenta que la mayoría de los requisitos son sólo para los "certificados de servidor"; sólo tiene que cumplir los nuevos requisitos para las "CA emisoras".
Según tus comentarios, parece que el título de tu pregunta era realmente incorrecto y no era la confianza de la "CA root" con la que tenías problemas - era el certificado del servidor el que no era de confianza. En este caso, recuerde que el certificado del servidor debe seguir todos los nuevos requisitos enumerados en el enlace mencionado anteriormente.
Estos nuevos requisitos son, para todos los certificados de servidor:
- Cuando se utiliza para TLS (como se hace en Safari), el nombre DNS del servidor debe estar en el campo Subject Alternative Name
Tenga en cuenta que este requisito también significa que si está solicitando su página web utilizando una dirección IP en lugar de un nombre, entonces la dirección IP (sin número de puerto) debe aparecer en el campo SAN.
Y para los certificados de servidor emitidos después del 1 de julio de 2019, también los dos requisitos siguientes:
-
Si se utiliza para TLS, el certificado debe contener un campo ExtendedKeyUsage con el OID id-kp-serverAuth (es decir, no utilice un certificado que figure como certificado de cliente, certificado de firma de código, certificado de correo electrónico o VPN, etc.)
-
Cuando se utiliza para TLS, el certificado debe ser válido durante 825 días o menos
Resulta que su problema era que el periodo de validez del certificado era superior a 825 días. Tendrás que volver a emitir el certificado con un periodo de validez más corto.
El motivo del nuevo requisito de periodo de validez es que el foro mundial de CA/B (regula la industria de los certificados digitales) estableció nuevas directrices en las que las CA no deben emitir certificados de servidor con un periodo de validez de más de 825 días después del 1 de marzo de 2018. Para más información sobre quién está detrás de la nueva norma, puede encontrar la información de la votación aquí .
