Introduction
HTTPS (via SSL /TLS) les usages cryptage à clé publique pour protéger les communications du navigateur contre la lecture ou la modification en transit sur Internet. Les serveurs fournissent aux navigateurs visiteurs une clé publique qui est utilisée pour établir une connexion cryptée pour tous les échanges de données ultérieurs.
Cependant, juste recevoir un de travail la clé publique seule ne garantit pas qu'elle (et par extension le serveur) est bien détenue par la bonne télécommande sujet (c'est-à-dire une personne, une entreprise ou une organisation). Man-in-the-middle les attaquants peuvent manipuler les réseaux pour servir leurs propres clés, compromettant ainsi toute communication.
Les navigateurs empêchent cela en authentifier Serveurs HTTPS utilisant certificats, qui sont des documents numériques lier une clé publique pour un sujet individuel. La liaison est assurée par un c de confianceautorité de certification (CA) comme SSL.com vérifier l'identité des propriétaires de certificats potentiels, via des vérifications automatiques et manuelles par rapport à des bases de données qualifiées.
Cette relation de confiance signifie que la sécurité des utilisateurs web n'est pas absolue ; elle exige plutôt que les utilisateurs fassent confiance aux navigateurs et aux autorités de certification pour protéger leur sécurité. Il est donc dans l'intérêt de chaque utilisateur de comprendre le fonctionnement de la validation des certificats.
Notez que le processus de validation du certificat (décrit en détail dans le document standard RFC 5280) est assez alambiqué. Dans cet article, nous allons essayer de vous guider sur un chemin (un navigateur validant le SSL /TLS certificat) et parcourez les détails complexes qui sont sans conséquence pour la plupart des utilisateurs.
À noter: À partir du mois d’août 2024, RFC 9618, un document de l'Internet Engineering Task Force (IETF), a mis à jour l'algorithme de validation des contraintes de politique dans les certificats numériques X.509 à partir de la RFC 5280.
Certificats et format X.509
Les certificats sont des fichiers numériques à tous égards, ce qui signifie qu'ils doivent suivre un format de fichier pour stocker des informations (par exemple, des signatures, des clés, des émetteurs, etc.). Bien que privés PKI les configurations peuvent implémenter n'importe quel format pour leurs certificats, de confiance PKIs (c'est-à-dire ceux approuvés par les navigateurs) doivent être conformes à la RFC 5280, qui exige l'utilisation du X.509 v3 le format.
X.509 v3 permet aux certificats d'inclure des données supplémentaires, telles que des contraintes d'utilisation ou des informations de stratégie, comme extensions, chaque extension étant soit critique or non critique. Si un client rencontre une extension non critique non reconnue, il peut l'ignorer. Si une extension est critique et non reconnue ou ne peut être traitée, le certificat doit être rejeté.
Chemins de certification et traitement des chemins
Les autorités de certification utilisent une clé privée pour signer cryptographiquement tous les certificats émis. Ces signatures peuvent cryptographiquement prouver qu'un certificat a été émis par une autorité de certification spécifique et qu'il n'a pas été modifié après sa signature.
Les AC établissent la propriété de leur clé de signature en détenant un certificat auto-émis (appelé racine) pour la clé publique correspondante. Les autorités de certification doivent respecter des procédures rigoureusement contrôlées et auditées pour créer, gérer et utiliser une racine. Pour minimiser l'exposition, elles utiliseront normalement une racine pour émettre intermédiaire certificats. Ces intermédiaires peuvent ensuite être utilisés pour émettre les certificats de leurs clients. Un certificat d'autorité de certification racine est autosigné et la clé privée est protégée par des procédures strictes. Son émission se fait généralement par des intermédiaires, et non directement depuis les racines.
Les navigateurs sont livrés avec une liste intégrée de racines de confiance. (Ce sont des racines d'autorités de certification qui ont passé les critères d'inclusion stricts du navigateur.) Pour vérifier un certificat, un navigateur obtiendra une séquence de certificats, chacun ayant signé le certificat suivant dans la séquence, connectant la racine de l'autorité de certification signataire au serveur du serveur. certificat.
Cette séquence de certificats est appelée chemin de certification. La racine du chemin s'appelle un ancre de confiance et le certificat du serveur s'appelle le feuille or entité finale certificat.
Construction de chemin
Souvent, les navigateurs web et les logiciels clients peuvent créer plusieurs ancres de confiance candidates (par exemple, en raison de signes croisés) et récupèrent fréquemment les intermédiaires manquants via AIA pour compléter une chaîne. Même si un chemin contient des certificats correctement liés à une ancre connue, le chemin lui-même peut être rejeté en raison de restrictions concernant la longueur du chemin, le nom de domaine, l'utilisation des certificats ou la politique.
La construction et l'évaluation de tous les chemins possibles est un processus coûteux effectué pour chaque nouveau certificat qu'un navigateur rencontre. Les navigateurs ont implémenté diverses optimisations pour minimiser le nombre de chemins candidats rejetés, mais approfondir ces détails dépasse largement le cadre de cet article.
Validation du chemin
Une fois qu'un chemin de certification candidat est construit, les navigateurs le valident à l'aide des informations contenues dans les certificats. Un chemin est valide si les navigateurs peuvent prouver par cryptographie qu'à partir d'un certificat directement signé par une ancre de confiance, la clé privée correspondante de chaque certificat a été utilisée pour émettre la suivante dans le chemin, jusqu'au certificat feuille.
Les exigences de base exigent que les noms du sujet et de l'émetteur soient tous les chemins possibles be identique octet pour octet, ce qui simplifie la construction de chemins fiables.
Algorithme de validation du chemin de certification
Comme indiqué précédemment, en août 2024, RFC 9618, un document de l'Internet Engineering Task Force (IETF), a mis à jour l'algorithme de validation des contraintes de politique dans les certificats numériques X.509 à partir de la RFC 5280. Fondamentalement, les navigateurs parcourent tous les certificats du chemin en commençant par l'ancre de confiance (c'est-à-dire le certificat racine), en validant les informations de base et les extensions critiques de chaque certificat.
Si la procédure se termine par le dernier certificat du chemin sans erreur, le chemin est accepté comme valide. Si des erreurs se produisent, le chemin est marqué comme non valide.
Traitement de base des certificats
Quelles que soient les extensions, les navigateurs doivent toujours vérifier les informations de base du certificat telles que la signature ou l'émetteur. Les sections suivantes présentent la séquence de vérifications effectuées par les navigateurs.
1. Le navigateur vérifie l'intégrité du certificat
Le Signature sur le certificat peut être vérifié en utilisant la cryptographie à clé publique normale. Si la signature n'est pas valide, le certificat est considéré comme modifié après sa délivrance et est donc rejeté.
2. Le navigateur vérifie la validité du certificat
Un certificat période de validité est l'intervalle de temps pendant lequel l'autorité de certification signataire garantit qu'elle conservera des informations sur son statut. Les navigateurs rejettent tous les certificats dont la période de validité se termine avant ou après la date et l'heure du contrôle de validation.
3. Le navigateur vérifie l'état de révocation du certificat
Lorsqu'un certificat est délivré, il devrait être utilisé pendant toute sa période de validité. Bien entendu, diverses circonstances peuvent rendre un certificat invalide avant son expiration naturelle.
De telles circonstances peuvent inclure un sujet changeant de nom ou une compromission présumée de sa clé privée. Dans de tels cas, une autorité de certification doit révoquer le certificat correspondant, et les utilisateurs font également confiance à une autorité de certification pour informer les navigateurs de l'état de révocation de leurs certificats.
Listes de révocation de certificats (CRL)
Les listes de révocation de certificats (CRL) sont devenues la norme de l'industrie pour la vérification de la révocation des certificats depuis 2024. Les autorités de certification émettent périodiquement des listes signées et horodatées de certificats révoqués que les navigateurs peuvent télécharger et mettre en cache localement.
Alors que les CRL étaient auparavant considérées comme moins efficaces que les méthodes de vérification en temps réel, l'industrie a reconnu des avantages significatifs qui en font l'approche privilégiée :
- Confidentialité améliorée:Les CRL protègent la confidentialité des utilisateurs en éliminant la nécessité d'interroger des serveurs externes sur des certificats spécifiques, ce qui pourrait révéler des habitudes de navigation
- Efficacité Opérationnelle:Les autorités de certification peuvent gérer la révocation plus efficacement sans maintenir de services de réponse en temps réel à haute disponibilité
- Coûts d’infrastructure réduits:L'élimination du besoin de répondeurs OCSP 24h/7 et XNUMXj/XNUMX réduit considérablement les frais opérationnels
- Meilleure mise en cache:Les navigateurs modernes peuvent mettre en cache et mettre à jour efficacement les CRL, minimisant ainsi les problèmes de latence qui favorisaient auparavant les méthodes en temps réel
En mars 2024, le CA/Browser Forum exige que toutes les autorités de certification de confiance publique fournissent des CRL tout en rendant les autres méthodes de révocation facultativesCertaines autorités de certification majeures ont abandonné les services de révocation alternatifs au profit d'approches CRL uniquement.
OCSP (Online Certificate Status Protocol)
Le protocole OCSP (Online Certificate Status Protocol), décrit dans RFC6960, a été conçu pour assurer la vérification de la révocation des certificats en temps réel en permettant aux navigateurs d'interroger les serveurs OCSP (répondeurs) sur des certificats spécifiques. Bien qu'OCSP ait été largement adopté dans les années 2010 comme une amélioration par rapport aux téléchargements périodiques de listes de révocation de certificats (CRL), le secteur a largement abandonné cette approche.
- OCSP est désormais facultatif pour les autorités de certification publiques de confiance (à compter de mars 2024). L'importance d'OCSP est déclinant; par exemple, Chiffrons supprimé les URL OCSP en mai 2025 et fermé les répondeurs en Août 2025.
- Certains navigateurs ont désactivé la vérification OCSP ou l'ont implémentée de manière à offrir des avantages de sécurité minimes.
Agrafage OCSP:Une variante appelée Agrafage OCSP reste utile dans certains scénarios, où les serveurs incluent les réponses OCSP directement dans le TLS Poignée de main, évitant ainsi des requêtes client distinctes aux répondeurs OCSP. Cependant, cela nécessite une configuration serveur spécifique. L'agrafage est pris en charge par la plupart des serveurs/CDN, mais son utilité diminue à mesure que les grandes autorités de certification abandonnent OCSP.
Comment cela fonctionne réellement aujourd'hui dans les navigateurs: Depuis le 15 mars 2024, le Forum CA/B exige que les autorités de certification de confiance publient des listes de révocation de certificats (CRL), tandis que le protocole OCSP est facultatif. Les navigateurs modernes n'interrogent généralement pas le protocole OCSP et ne téléchargent pas les CRL par site. Ils utilisent plutôt des mécanismes agrégés, construits à partir des CRL publiées par les autorités de certification : les CRLSets de Chrome et les CRLite de Firefox fournissent aux clients des données de révocation rapides et respectueuses de la confidentialité. Par conséquent, le rôle du protocole OCSP sur le Web public diminue ; par exemple, Let's Encrypt a supprimé les URL OCSP en mai 2025 et fermé les répondeurs OCSP en août 2025.
4. Le navigateur vérifie l'émetteur
Les certificats sont normalement associés à deux entités:
- Le émetteur, qui est l'entité détenant la clé de signature et
- Le sujet, qui fait référence au propriétaire de la clé publique que le certificat authentifie.
Les clients vérifient que chaque certificat du chemin est signé par la clé publique du certificat précédent et que les noms de l'émetteur/du sujet correspondent exactement tout au long du chemin. Pour plus de sécurité, la plupart PKI Les implémentations vérifient également que la clé de l'émetteur est identique à celle qui a signé le certificat actuel. (Ceci n'est pas vrai pour l'ancre de confiance, car les racines sont auto-émises, c'est-à-dire qu'elles ont le même émetteur et le même sujet.)
Traitement des contraintes
Le format X.509 v3 permet à une autorité de certification de définir des contraintes ou des restrictions sur la façon dont chaque certificat est validé et utilisé comme extensions critiques. Chaque certificat du chemin peut imposer des contraintes supplémentaires auxquelles tous les certificats suivants doivent obéir.
Les contraintes de certificat affectent rarement l'utilisateur Internet moyen, bien qu'elles soient assez courantes dans les solutions SSL d'entreprise. Les contraintes fonctionnelles peuvent servir plusieurs objectifs opérationnels, mais leur utilisation la plus importante est d'atténuer les problèmes de sécurité connus.
5. Le navigateur vérifie les contraintes de nom
Une autorité de certification intermédiaire privée (mais de confiance publique) avec les contraintes de nom Peut offrir à une organisation un contrôle précis de la gestion et de l'émission des certificats. Les certificats peuvent être limités à un domaine ou une arborescence de domaines spécifique (c'est-à-dire incluant des sous-domaines) pour le nom de domaine d'une entreprise ou d'une organisation. Des contraintes de nom sont souvent appliquées aux certificats d'autorité de certification intermédiaires achetés auprès d'une autorité de certification publiquement reconnue, afin d'empêcher cette dernière d'émettre des certificats parfaitement valides pour des domaines tiers (par exemple, google.com).
6. Le navigateur vérifie les contraintes de politique
Une politique de certification est un document juridique publié par une autorité de certification, détaillant officiellement les procédures suivies pour émettre et gérer ses certificats. Les autorités de certification peuvent émettre un certificat sous une ou plusieurs stratégies, et des liens vers celles-ci sont inclus dans chaque certificat émis afin que les parties utilisatrices puissent évaluer ces stratégies avant de décider d'approuver ce certificat.
Pour des raisons juridiques et opérationnelles, les certificats peuvent imposer des restrictions sur les politiques auxquelles ils peuvent être soumis. S'il s'avère qu'un certificat contient des contraintes de stratégie critiques, les navigateurs doivent les valider avant de continuer. (Cependant, des contraintes politiques critiques sont rarement rencontrées dans le monde réel et ne seront donc pas prises en compte pour le reste de cet article.)
7. Le navigateur vérifie les contraintes de base (aka longueur du chemin)
Le format X.509 v3 permet aux émetteurs de définir la longueur de chemin maximale qu'un certificat peut prendre en charge. Cela permet de contrôler dans quelle mesure chaque certificat peut être placé dans un chemin de certification. C'est en fait important - les navigateurs utilisés pour ignorer la longueur du chemin de certification jusqu'à ce qu'un chercheur démontre, dans un 2009 présentation, comment il a utilisé le certificat feuille de son site Web pour falsifier un certificat valide pour un grand site Web de commerce électronique.
8. Le navigateur vérifie l'utilisation des clés
L'extension «utilisation de la clé» indique le but de la clé contenue dans le certificat. Des exemples de telles fins comprennent le chiffrement, les signatures, la signature de certificats, etc. Les navigateurs rejettent les certificats qui enfreignent leurs contraintes d'utilisation de clé, telles que la rencontre d'un certificat de serveur avec une clé destinée uniquement à la signature CRL.
9. Le navigateur continue de traiter toutes les extensions critiques restantes
Après avoir traité les extensions mentionnées ci-dessus, les navigateurs procèdent à la validation de toutes les extensions restantes que le certificat actuel désigne comme critiques, avant de passer à la suivante. Si un navigateur atteint le certificat feuille d'un chemin sans erreur, le chemin est accepté comme valide. Si des erreurs se produisent, le chemin est marqué comme non valide et une connexion sécurisée n'est pas établie.
Gestion moderne des certificats : durée de vie réduite et automatisation
Le SSL /TLS Le secteur a connu plusieurs changements ces dernières années, modifiant fondamentalement la manière dont les certificats sont délivrés et gérés. Il est crucial de comprendre ces changements pour PKI gestionnaires, professionnels de l’informatique et/ou toute autre personne travaillant avec des certificats numériques.
Durée de validité des certificats raccourcie
En avril 2025, le CA/Browser Forum a approuvé une décision historique (Bulletin de vote SC-081v3) pour réduire considérablement les périodes de validité des certificats par phases :
- En cours (jusqu'en mars 2026):Maximum 398 jours (environ 13 mois)
- 15 mars : Maximum 200 jours
- 15 mars : Maximum 100 jours
- 15 mars : Maximum 47 jours
Modifications de la validation du contrôle de domaine (DCV)
Parallèlement à la durée de vie des certificats, la période de réutilisation des informations de validation de domaine diminue également :
- Mars 2026: 200 jours de réutilisation maximum
- Mars 2027: 100 jours de réutilisation maximum
- Mars 2029: 10 jours de réutilisation maximum
Cela signifie que les organisations devront valider la propriété du domaine beaucoup plus fréquemment, ce qui rend l’automatisation essentielle pour la gestion pratique des certificats.
Pourquoi ces changements sont importants
Avantages en matière de sécurité :
- La durée de vie plus courte des certificats réduit la fenêtre d'exposition lorsque les clés sont compromises
- Une validation plus fréquente garantit que la propriété du domaine reste à jour
- Déploiement plus rapide des améliorations de sécurité sur le Web
Impact opérationnel :
- La gestion manuelle des certificats devient pratiquement impossible
- Les organisations doivent mettre en œuvre une gestion automatisée du cycle de vie des certificats
- Des procédures de validation de domaine plus fréquentes sont requises
Exigences d'automatisation
Ces changements rendent l'automatisation des certificats non seulement bénéfique, mais essentielle. Les organisations devraient sérieusement considérer :
- Mettre en œuvre le ACME (environnement de gestion automatique des certificats) ou des protocoles similaires
- Déployer solutions de gestion du cycle de vie des certificats
- Préparer l'infrastructure pour des renouvellements et des validations fréquents
- Préparez-vous à la transition vers des durées de vie des certificats plus courtes
Intégration de la transparence des certificats
Les navigateurs modernes exigent ou valident de plus en plus les journaux de transparence des certificats (CT), qui fournissent des enregistrements publics et vérifiables de tous les certificats émis. Cela permet de détecter :
- Certificats mal délivrés
- Délivrance de certificat non autorisée
- Problèmes de conformité CA
Conclusion
Le paysage numérique reste un système complexe de composants interconnectés, et la sécurité des navigateurs continue d’être un domaine de développement actif qui comprend :
- Durée de vie des certificats plus courte:L'industrie évolue vers des périodes de validité des certificats de 47 jours d'ici 2029, ce qui rend l'automatisation essentielle pour la gestion pratique des certificats
- Modifications de la méthode de révocation:Le passage de l'OCSP aux CRL reflète la priorité accordée par l'industrie à la confidentialité des utilisateurs et à l'efficacité opérationnelle
- Surveillance plus stricte de l'AC:Les navigateurs sont devenus plus agressifs dans l'application de la conformité et la suppression de la confiance des autorités de certification sous-performantes
Ces changements représentent une évolution fondamentale vers une gestion des certificats plus automatisée, plus respectueuse de la confidentialité et plus axée sur la sécurité. Les organisations doivent se préparer dès maintenant à la réduction de la durée de vie des certificats et à l'automatisation des processus de renouvellement.
La confiance continue de jouer un rôle majeur dans la sécurité des utilisateurs en ligne. Nous vous encourageons à vous tenir informé de l'évolution de ces normes et à consulter les politiques et le bilan de conformité de votre autorité de certification. Comme le montrent ces changements, l'écosystème des certificats s'adapte activement pour renforcer la sécurité et la protection de la vie privée.
Pour obtenir les informations les plus récentes sur les meilleures pratiques de gestion des certificats et l'approche de SSL.com face à ces changements dans le secteur, veuillez consulter notre page de comparaison des certificats.
Merci d'avoir choisi SSL.com, où nous croyons plus sûre Internet est un mieux Internet.
