Note de l'éditeur : Ce blog a été initialement publié en avril 2021. Il a depuis été mis à jour pour fournir de nouvelles dates pour la rotation de l'ICA et la dépréciation du champ OU, ainsi que pour fournir des informations supplémentaires sur les modifications de l'utilisation des clés ECC et le processus de réflexion qui les sous-tend.
Le CA/Browser Forum et Les programmes racines précisent les exigences auxquelles les AC doivent se conformer et faire l'objet d'un audit afin de fournir des exigences uniformes pour toutes les AC et de protéger les visiteurs des sites Web en fixant d'importantes exigences de conformité et de sécurité. Vous savez tous que la validité maximale des certificats TLS a été réduite de 5 ans à 3 ans, puis à 825 jours et, en septembre dernier, à 397 jours (environ 13 mois). Dans ce post, nous aimerions vous informer de certains des changements à venir qui ont été mandatés par les programmes racine et/ou le Forum CAB
L'AC DOIT vérifier les noms de domaine et les adresses IP au plus tard 397 jours avant la délivrance du certificat.
Date d'entrée en vigueur : 1er octobre 2021
En septembre dernier, Apple a imposé une période de validité maximale de 397 jours, mais la période de réutilisation de la validation des domaines et des organisations est restée à 825 jours. C'est la deuxième fois que ce changement est mis en œuvre. Cette réduction de la période de réutilisation des domaines était attendue et il est peu probable qu'elle soit la dernière. Elle découle de plusieurs études qui ont révélé que, dans certains cas, lors de changements de propriétaires de domaines, les certificats existants peuvent continuer à être remplacés/émis par l'ancienne AC. Une façon de remédier à cela est de réduire la période de réutilisation de la validation du domaine.
Prenez un peu de recul et pensez à la situation de la manière suivante :
- Jusqu'à la réduction de la validité maximale imposée par Apple, le délai entre la validation du domaine et l'expiration du certificat était de 825 + 825 jours, soit environ 4 ans et demi. C'est une longue période !
- Avec la réduction de la validité maximale imposée par Apple, la différence est de 825 + 398 jours, soit encore plus de 3 ans.
- Avec ce dernier changement, la différence maximale est de 397+397 jours, soit un peu plus de 2 ans.
- À titre de comparaison, l'autorité de certification qui délivre le plus de certificats par an, Let's Encrypt, délivre des certificats d'une validité maximale de 90 jours et réutilise la validation du domaine pour une durée maximale de 30 jours, soit un maximum de 4 mois entre la validation et l'expiration du certificat.
On peut s'attendre à ce que le secteur se rapproche de la ligne de base de Let's Encrypt et, éventuellement, à ce qu'elle soit encore plus courte.
Interdire la méthode de validation de domaine HTTP pour l'émission de sous-domaines et de caractères génériques.
Date d'entrée en vigueur : 1er décembre 2021
La méthode de validation du domaine HTTP (officiellement connue sous le nom de méthode 6, Agreed-Upon Change to Website) est couramment utilisée pour vérifier le contrôle du domaine. Si vous pouvez placer un fichier dans un répertoire spécifique du site web, cela "démontre" le contrôle de ce domaine. Contrairement au DNS, les sites Web ne disposent pas des mêmes contrôles où il existe une délégation formelle des autorisations du domaine aux sous-domaines. Ainsi, si exemple.com a été piraté, ou si son propriétaire a certaines tendances malveillantes, il peut approuver exemple.com et ensuite délivrer des certificats aux sous-domaines. Mais ces sous-domaines peuvent être des entités différentes, et encore une fois, puisqu'il n'y a pas le même niveau de délégation formelle de contrôle, Mozilla impose que l'émission de certificats contenant des domaines validés avec la méthode HTTP soit limitée à l'émission d'exactement le domaine validé. En d'autres termes, les Wildcards et les SAN de sous-domaines seront interdit pour les domaines validés avec la méthode HTTP.
Cela aura un impact sur les clients, car il s'agit d'une méthode courante de validation des domaines. Si vous voulez continuer à utiliser cette méthode, vous devez valider chaque SAN:DNSName individuellement.
Rotation des ICA à intervalles plus courts
Échéance : 24 août 2021 puis trimestriellement en 2022
GlobalSign commencera à faire tourner nos AC TLS Atlas à intervalles réguliers afin de promouvoir la sécurité et l'agilité de l'écosystème. Historiquement, nous avons mis en place des AC et les avons utilisées pendant de nombreuses années, mais il existe de nombreuses raisons de réduire cet intervalle de temps. En réduisant la durée d'utilisation des CA, nous obtenons les avantages suivants :
- Cela limite le nombre de certificats émis par une seule AC et sa clé privée correspondante, ce qui améliore notre propre crypto-agilité.
- Cela limite l'impact s'il y a un problème d'intégrité, de conformité ou de sécurité avec l'AC.
- Cela réduit la taille des LCR, ce qui augmente les performances de validation.
- Cela forme notre clientèle à s'attendre et à planifier le remplacement immédiat des AC, ce qui augmente leur crypto-agilité.
- Notre plan final prévoit une rotation trimestrielle de toutes les AC Atlas TLS de GlobalSign et une rotation annuelle de toutes les AC Atlas TLS dédiées aux clients.
- La première rotation des AC TLS d'Atlas GlobalSign pour 2021 aura lieu le 24 août 2021.
- À partir de 2022, nous mettrons à jour les AC TLS d'Atlas GlobalSign chaque trimestre, le deuxième lundi du trimestre, et nous mettrons à jour les AC TLS d'Atlas dédiées aux clients chaque année en janvier.
Impact et recommendations:
- Les clients doivent toujours être prêts à accepter de nouvelles AC lors de l'installation de nouveaux certificats TLS. L'autorité de certification émettrice est disponible dans l'API et doit être utilisée lors du téléchargement du certificat afin que l'autorité de certification actuelle soit toujours approvisionnée avec le certificat émis.
- Les clients NE DOIVENT pas faire d'épinglage de clé publique aux certificats d'AC, et nous décourageons fortement l'épinglage de clé publique tout court, car cela va à l'encontre de l'objectif d'agilité cryptographique.
- Nous encourageons les clients à suivre les pratiques agiles pour les AC émettrices et à toujours télécharger et installer l'ICA fourni lors de l'obtention de nouveaux certificats.
- Veuillez vous abonner à la page d'état de GlobalSign pour les mises à jour importantes ici - https://status.globalsign.com/.
Vous trouverez de plus amples informations sur notre site d'assistance.
Changements dans l'utilisation des clés ECC
Date d'entrée en vigueur : 26 juillet 2021
Nous allons modifier l'utilisation des clés dans nos certificats ECC TLS afin de nous aligner sur les meilleures pratiques de l'industrie et les changements en cours dans les exigences de base du CA/B Forum. Actuellement, nous incluons à la fois la signature numérique et l'accord de clé, mais à partir de cette date, nous allons changer cela pour inclure uniquement la signature numérique.
Notre TLS de confiance publique est utilisé par les navigateurs et les serveurs Web pour prendre en charge les sessions TLS afin de protéger l'utilisateur final. Nous garderons toujours la sécurité des utilisateurs de ces certificats au premier plan de nos considérations lors de la création de nouveaux profils ou de l'émission d'AC. Il a été décidé que la nécessité d'un accord de clé dans l'utilisation des certificats ECC n'était plus nécessaire dans un certificat TLS, tout en introduisant des problèmes de sécurité potentiels pour les utilisateurs finaux, car la clé de signature et la clé de cryptage devraient être des clés distinctes dans une session TLS. Pour ces raisons, l'extension a été abandonnée de nos offres générales TLS. Les clients qui ont besoin de profils personnalisés pour des outils et des systèmes en dehors des limites des sessions TLS traditionnelles entre navigateur et serveur devraient fortement envisager les offres de confiance privée.
Interdiction de l'utilisation du champ OU
Échéance : 31 août 2022
Google s'inquiète depuis longtemps de la manière dont le champ OU des certificats TLS est validé. Les exigences de base ont des exigences claires sur tous les champs de sujet (C, S, L, Org, etc.) qui exigent que les données soient obtenues à partir d'un référentiel d'entreprise ; cependant, l'exigence du champ OU reste la même :
L'AC DOIT mettre en œuvre un processus qui empêche un attribut OU d'inclure un nom, un DBA, un nom commercial, une marque de commerce, une adresse, un emplacement ou tout autre texte qui fait référence à une personne physique ou à une entité juridique spécifique, à moins que l'AC n'ait vérifié cette information.
Cela permet aux clients de fournir des informations non validées, voire trompeuses, auxquelles ils peuvent se fier (par inadvertance). C'est pourquoi Google préconise vivement la suppression de ce champ.
Ce champ est souvent utilisé par les organisations pour les aider à gérer les certificats en spécifiant le service auquel le certificat appartient. Les rapports de certificats aident l'organisation à allouer les renouvellements et les remplacements sur la base de ce champ ; cependant, l'objectif des données dans les certificats est destiné aux parties fiables, celles qui visitent le site et veulent prendre une décision quant à savoir si elles doivent faire confiance ou non au site, et non à la gestion des certificats de l'organisation.
Les clients doivent être conscients de ce changement à venir et commencer à planifier la dépréciation du champ OU. Bien que la date limite ait été fixée au 31 août 2022, nous supprimerons progressivement l'utilisation générale du champ OU dans les mois à venir et nous recueillerons des informations pour les programmes racine sur les raisons pour lesquelles certains continuent à avoir besoin du champ OU.
Vous avez des questions ? Visitez notre site d'assistance pour plus d'informations et des moyens de nous contacter.
