Chrome et Safari limitent les certificats SSL à un an de validité

Auteur Uwe GradeneggerPublié le Catégories Utilisation du certificatÉtiquettes , , , , , , , , ,

Apple a récemment annoncé que le navigateur Safari n'acceptera désormais plus que les certificats d'une durée de validité de 398 jours, à condition qu'ils aient été émis à partir du 1er septembre 2020.

Mozilla et Google souhaitent implémenter un comportement similaire dans leurs navigateurs. La question se pose donc de savoir si cette modification aura des répercussions sur les autorités de certification internes, c'est-à-dire si, à l'avenir, les certificats SSL internes devront également respecter ces règles, comme c'est le cas par exemple pour l'application du RFC 2818 comme cela a été le cas avec Google.

Les autorités de certification internes sont-elles concernées ?

Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.

Dans la documentation officielle d'Apple, on trouve la phrase suivante, qui stipule clairement que les autorités de certification internes sont exclues de la vérification :

Ce changement n'affectera que les certificats de serveur TLS émis par les autorités de certification racine préinstallées avec iOS, iPadOS, macOS, watchOS et tvOS.

About upcoming limits on trusted certificates (APPLE)

Il n'y a pas de déclaration écrite du projet Chromium à ce sujet, mais un coup d'œil dans son code source montre que la logique utilisée dans la fonction CertVerifyProc::HasTooLongValidity est exactement la même que celle utilisée pour la réduction précédente à 825 jours.

// For certificates issued on-or-after 1 March 2018: 825 days.
   if (start >= time_2018_03_01 &&
       validity_duration > base::TimeDelta::FromDays(825)) {
     return true;
   }
// For certificates issued on-or-after 1 September 2020: 398 days.
   if (start >= time_2020_09_01 &&
       validity_duration > base::TimeDelta::FromDays(398)) {
     return true;
   }

Des tests effectués avec Chrome et Edge ont toutefois révélé que, pour les autorités de certification internes, la limite actuelle de 825 jours n'entraînait déjà pas de message d'erreur - contrairement au forçage du RFC 2818, La nouvelle version de l'interface utilisateur de Chromium a été introduite en 2017.

Contrairement à Chrome et Edge Apple limite la validité des certificats à un maximum de 825 jours pour les certificats de serveur web émis par des autorités de certification internes après le 1er juillet 2019..

Mise à jour

Entre-temps, Google a publié un article à ce sujet, Le rapport de l'OCDE sur l'état de l'Union européenne confirme cette hypothèse.

Cela ne s'applique qu'à l'ensemble des AC approuvées par défaut par Google Chrome, et non aux AC exploitées par une entreprise et qui ne disposent pas de chemins de certification vers les AC approuvées par défaut.

Pourquoi les certificats internes sans SAN sont-ils contestés par Chrome, alors que les certificats internes avec une longue durée de validité ne le sont pas ?

Pour cela, nous jetons un coup d'œil au code qui vérifie la validité du certificat :

// Flag certificates using too long validity periods.
   if (verify_result->is_issued_by_known_root && HasTooLongValidity(*cert)) {
     verify_result->cert_status |= CERT_STATUS_VALIDITY_TOO_LONG;
     if (rv == OK)
       rv = MapCertStatusToNetError(verify_result->cert_status);
   }

Il s'agit ici de vérifier si le certificat provient d'une autorité de certification „publique“ et si la validité du certificat se situe dans les limites autorisées.

A titre de comparaison, le code qui prend en charge la vérification de la conformité au RFC 2818 :

if (!cert->VerifyNameMatch(hostname)) {
     verify_result->cert_status |= CERT_STATUS_COMMON_NAME_INVALID;
     rv = MapCertStatusToNetError(verify_result->cert_status);
   }

Il manque ici l'examen is_issued_by_known_root, qui limite le choix aux autorités de certification „publiques“. Ainsi, la vérification pour le RFC 2818 s'applique généralement à tous les certificats, mais la vérification de la validité des certificats ne s'applique qu'aux certificats qui n'ont pas été délivrés par une autorité de certification interne.

Est-ce que Microsoft Edge est concerné ?

Comme de nombreuses entreprises utilisent le navigateur Microsoft Edge, il est très intéressant pour nous de savoir si celui-ci est également concerné. Étant donné que le navigateur Microsoft Edge est désormais basé sur le projet Chromium, tout comme Google Chrome, il adopte (en grande partie) son comportement. Il est donc tout aussi concerné que Chrome.

Conclusion : est-il nécessaire d'agir ?

Pour Internet Explorer Safari, Chrome et Microsoft Edge, l'utilisation d'une propre autorité de certification interne permet d'un point de vue purement technique aucune action n'est nécessaire, car ils sont exclus lors du contrôle des certificats. Il est donc possible de continuer à utiliser en interne des certificats SSL dont la durée de validité est supérieure à 398 jours, mais pas plus de 825 jours.

Il est toutefois tout à fait conseillé de vérifier les processus d'émission et de retrait des certificats SSL pour voir si une validité de certificat aussi longue est réalisable tout en respectant le niveau de sécurité souhaité.

Liens complémentaires :

Sources externes

Les commentaires sont fermés.

fr_FRFrançais
de_DEDeutsch en_USEnglish fr_FRFrançais