IOS 13 a augmenté la sécurité concernant ces certificats racine. Il ne s'agit donc pas d'un bug, mais plutôt de l'obligation de répondre à des exigences plus élevées pour que cela fonctionne.
Tout d'abord, le processus de confiance manuelle du certificat racine a été rendu légèrement plus compliqué afin de garantir que les utilisateurs ne le font pas involontairement. Avant, vous pouviez importer un profil et c'était terminé, mais maintenant vous devez également ouvrir Paramètres > Général > À propos de > Paramètres de confiance des certificats, puis basculer "Activer la confiance totale pour les certificats racine" pour le certificat.
En plus du changement de processus mentionné ci-dessus, les exigences pour le certificat réel ont également changé :
-
Si vous utilisez RSA, la taille de la clé doit être d'au moins 2048 bits.
-
L'algorithme de hachage doit être SHA-2, et non SHA-1.
Vous pouvez lire l'explication d'Apple concernant ces nouvelles exigences ici. Notez que la plupart des exigences ne concernent que les "certificats de serveur" - vous devez simplement respecter les nouvelles exigences pour les "AC d'émission".
Selon vos commentaires, il semblait que le titre de votre question était vraiment incorrect et ce n'était pas la confiance de l'AC racine qui posait problème - c'était le certificat de serveur qui n'était pas de confiance. Dans ce cas, rappelez-vous que le certificat de serveur doit respecter toutes les nouvelles exigences répertoriées dans le lien mentionné ci-dessus.
Ces nouvelles exigences sont, pour tous les certificats de serveur :
- Lorsqu'il est utilisé pour TLS (comme dans Safari), le nom DNS du serveur doit figurer dans le champ Alternative Subject Name
Notez que cette exigence signifie également que si vous demandez votre page web en utilisant une adresse IP au lieu d'un nom, alors l'adresse IP (sans numéro de port) doit figurer dans le champ SAN.
Et pour les certificats de serveur émis après le 1er juillet 2019, également les deux exigences suivantes :
-
Lorsqu'il est utilisé pour TLS, le certificat doit contenir un champ ExtendedKeyUsage avec l'OID id-kp-serverAuth (c'est-à-dire ne pas utiliser un certificat répertorié comme certificat client, certificat de signature de code, certificat e-mail ou VPN, etc)
-
Lorsqu'il est utilisé pour TLS, le certificat doit être valide pendant 825 jours ou moins
Il s'est avéré que votre problème était lié à la période de validité du certificat étant supérieure à 825 jours. Vous devrez réémettre le certificat avec une période de validité plus courte.
La raison de la nouvelle exigence de période de validité est que le forum CA/B mondial (réglemente l'industrie des certificats numériques) a établi de nouvelles directives où les AC ne doivent pas émettre de certificats de serveur avec une période de validité de plus de 825 jours après le 1er mars 2018. Pour plus d'informations sur les personnes à l'origine de la nouvelle règle, vous pouvez trouver des informations sur le vote ici.
