Que sont les certificats numériques ? Guide complet sur les types de certificats, les formats et la fiabilité

Chaque fois que vous chargez une page HTTPS, que vous vous connectez à un serveur via SSH, que vous envoyez un e-mail chiffré ou que vous connectez un appareil à un réseau, un certificat numérique fonctionne discrètement en arrière-plan. Ces informations d'identification constituent le fondement des communications sécurisées sur Internet et au sein des environnements d'entreprise. Elles associent une identité vérifiée à une clé cryptographique, permettant ainsi aux systèmes de se faire confiance même s'ils ne se sont jamais rencontrés auparavant.

Ce rôle, jusqu’alors discret, est désormais devenu un véritable casse-tête opérationnel. Les entreprises gèrent aujourd’hui plus de machines, de services et d’appareils que jamais, et le nombre de certificats en production a augmenté en conséquence. Parallèlement, la durée de vie maximale d’un certificat de confiance publique devrait être ramenée à seulement 47 jours à compter de mars 2029, ce qui réduit considérablement les délais de renouvellement et rend le suivi manuel impossible à long terme.

Ce guide explique ce qu'est un certificat, présente les principales familles de formats que vous rencontrerez, décrit comment la confiance est établie grâce aux autorités de certification et aux chaînes de certificats, et explique comment les certificats sont invalidés avant leur expiration. À la fin de cette lecture, vous comprendrez non seulement les mécanismes en jeu, mais aussi pourquoi la gestion des certificats est devenue un pilier de la confiance numérique.

Qu'est-ce qu'un certificat numérique ?

Un certificat numérique est un fichier qui associe une identité vérifiée, telle qu'un nom de domaine, une organisation, une personne ou un appareil, à une paire de clés cryptographiques. Cette association permet à deux systèmes de s'authentifier mutuellement et de chiffrer les données en transit, même s'ils n'ont jamais interagi auparavant.

On peut se le représenter comme un passeport numérique. Un passeport contient des informations sur son titulaire et est délivré par une autorité de confiance qui se porte garante de ces informations. Un certificat remplit la même fonction pour une machine ou un utilisateur : il contient des informations d'identité ainsi qu'une clé publique, et il est signé par une autorité à laquelle d'autres systèmes font déjà confiance.

Au cœur de chaque certificat se trouve une paire de clés. La clé publique est intégrée au certificat et diffusée publiquement, tandis que la clé privée correspondante reste sous le contrôle sécurisé de l'entité que le certificat représente. C'est cette paire asymétrique qui rend possible la vérification d'identité.

Comment fonctionne un certificat numérique ?

Concrètement, un certificat suit un processus simple. Il contient une clé publique et des données d'identité. Une autorité de confiance le signe afin de confirmer la légitimité de cette identité. Une partie qui s'appuie sur ce certificat, comme un navigateur ou une application, vérifie cette signature avant d'accepter de se fier à la connexion.

L'exemple le plus parlant est la négociation de sécurité « TLS », qui sécurise le trafic Web. En gros, voici comment cela fonctionne :

1. « Client hello » :le client établit la connexion en envoyant la version du protocole « TLS » qu’il prend en charge ainsi que les suites de chiffrement, accompagnées d’une valeur aléatoire appelée « nonce ».
2. Présentation du certificat :le serveur répond en fournissant son certificat signé ainsi qu'une signature sur le nonce, attestant ainsi de son identité vérifiée.
3. Validation :le client vérifie la signature du nonce à l'aide de la clé publique figurant dans le certificat, puis remonte la chaîne de signature du certificat jusqu'à une racine de confiance. Cela permet de confirmer que le serveur est bien celui qu'il prétend être.
4. Échange de clés :une fois l'identité confirmée, les deux parties négocient une clé symétrique commune.
5. Canal sécurisé :cette clé symétrique crypte le reste de la session, protégeant ainsi les données contre toute interception ou altération.

C'est la signature qui permet à l'ensemble du modèle de fonctionner. Étant donné que n'importe qui peut se procurer une copie d'un certificat public, le fait de vérifier que le nonce a été correctement signé prouve que la partie adverse détient bien la clé privée correspondante. Dans la plupart des connexions Web, seul le serveur présente un certificat, mais l'TLS e mutuelle (mTLS) exige que les deux parties s'authentifient, un modèle de plus en plus courant dans la sécurité des API, les architectures « zero-trust » et les systèmes industriels.

Un autre exemple bien connu est SSH, qui permet d'assurer la sécurité de l'administration à distance. Voici une description générale de ce protocole.

1. Salut du client :le client établit la connexion en échangeant des en-têtes indiquant la version du protocole ainsi qu'une liste des algorithmes pris en charge pour l'échange de clés, la clé hôte, le chiffrement et le contrôle de cohérence (MAC).
2. Échange de clés :les deux parties génèrent des paires de clés éphémères et échangent leurs clés publiques, ce qui permet de dériver un secret partagé qu’aucune des deux parties ne transmet. Toutes les informations mentionnées jusqu’à présent sont regroupées dans un seul hachage d’échange.
3. Authentification de l'hôte :le serveur présente soit son certificat, soit sa clé publique seule, accompagnés d'une signature sur le hachage de l'échange, prouvant ainsi qu'il détient la clé privée correspondante de l'hôte et liant son identité à cet échange spécifique.
4. Validation :le client vérifie la signature, puis s'assure qu'il fait confiance à la clé de l'hôte, soit parce que celle-ci figure déjà dans sa liste d'hôtes connus, soit parce qu'elle est associée à un certificat signé par une autorité à laquelle le client fait confiance. À partir de ce moment, le canal est chiffré.
5. Authentification de l'utilisateur :au sein du canal désormais chiffré, le client prouve son identité, le plus souvent en signant un défi à l'aide d'une clé privée dont la clé publique est déjà acceptée par le serveur.

Il convient de mentionner que, dans le cas de SSH, les certificats sont facultatifs. Le modèle « sans certificat » fonctionne bien à petite échelle, où chaque client conserve une liste d’hôtes connus et chaque serveur une liste de clés autorisées. Il devient toutefois difficile à gérer à mesure que le parc s’agrandit, et ce pour deux raisons. Premièrement, le nombre de relations de confiance à gérer augmente proportionnellement au produit du nombre d’utilisateurs par celui des hôtes, alors qu’une autorité de certification le réduit à une seule clé de confiance de chaque côté. Deuxièmement, les entrées de ces fichiers n’ont pas de date d’expiration ; l’accès persiste donc jusqu’à ce que quelqu’un les supprime manuellement, tandis que les certificats expirent d’eux-mêmes. Il existe également une lacune que le modèle basé sur des fichiers ne peut combler : lors d’une première connexion à un hôte inconnu, le client ne dispose d’aucun élément de validation et se rabat sur la demande à l’utilisateur d’accepter une empreinte qu’il vérifie rarement.

Combien existe-t-il de types de certificats numériques ?

Il existe trois grands types de certificats numériques, en fonction de leur usage :

• Les certificats de serveursécurisent les données transitant sur l'Internet public et garantissent qu'un site est bien celui qu'il prétend être. Ils fournissent la clé publique qui garantit la sécurité du protocole et contribuent à prévenir l'usurpation de domaine et les attaques de type « homme au milieu ».
• Les certificats de signature de codepermettent d'identifier l'éditeur d'un élément d'software et de confirmer que le code n'a pas été modifié depuis sa signature. Un horodatage appliqué lors de la signature garantit la validité de celle-ci même après l'expiration du certificat lui-même, ce qui est important pour les software à longue durée de vie.
• Les certificats utilisateur/clientpermettent d'authentifier des personnes ou des appareils. Ils constituent une alternative bien plus sûre aux mots de passe et s'intègrent naturellement dans les systèmes d'authentification à deux facteurs et les modèles d'accès « zero-trust ».

Ces trois éléments ont des finalités différentes, mais ils partagent un point commun : la confiance. Chacun repose sur une identité vérifiée et une paire de clés qu’une partie de confiance peut vérifier.

Familles de formats de certificats

Il n'existe pas de format de certificat universel adapté à toutes les applications. Les différents protocoles nécessitent des formats distincts, chacun étant conçu en fonction des besoins du système qu'il dessert. La norme X.509, par exemple, précise que SSH utilise délibérément un type de certificat différent, car le protocole SSH a ses propres exigences, et que PGP s'appuie sur un modèle décentralisé plutôt que sur des autorités centrales.

Quatre familles de formats couvrent l'essentiel de ce que vous rencontrerez dans la pratique : X.509, SSH, OpenPGP et les formats JOSE basés sur JSON. Les sections ci-dessous présentent chacun d'entre eux avant de les comparer côte à côte.

Certificats X.509

La norme X.509 constitue le fondement de l'infrastructure à clé publique (PKI). Issue de la norme d'annuaire X.500, elle a été introduite par l'Union internationale des télécommunications et adoptée comme norme Internet dans la RFC 5280. Elle associe une identité vérifiée à une paire de clés et définit les champs précis qui garantissent l'interopérabilité d'un certificat entre différents systèmes. Nous vous proposons ici un bref aperçu de ce format. Pour en savoir plus, consultez notreguide complet sur les certificats X.509.

Champs principaux.
Chaque certificat X.509 contient un ensemble défini de données, notamment un numéro de version, un numéro de série attribué par l’autorité de certification émettrice, un identifiant d’algorithme de signature, le nom de l’émetteur, une période de validité et les informations relatives à la clé publique du sujet. La période de validité est délimitée par deux horodatages (« not before » et « not after »), qui définissent la durée pendant laquelle le certificat peut être considéré comme fiable et limitent ainsi les dommages pouvant résulter d’une fuite de la clé privée.

Extensions de la version 3.
La version 3a introduit un cadre d'extensions qui a considérablement élargi les informations qu'un certificat peut contenir. Chaque extension possède un identifiant, un indicateur « critique » et une valeur. Si un destinataire ne reconnaît pas une extension marquée comme « critique », il doit rejeter le certificat. Parmi les extensions courantes, on trouve les contraintes d'utilisation des clés, les noms alternatifs du sujet (qui permettent à un seul certificat de couvrir plusieurs domaines), les politiques de certificat et les contraintes de base qui distinguent les certificats d'autorité de certification (CA) des certificats d'entité finale.

Historique des versions.
La version 1 (1988) a défini la structure de base. La version 2 (1993) a ajouté des identifiants uniques pour l'émetteur et le sujet, désormais considérés comme obsolètes. La version 3 (à partir de 1996) a introduit le cadre d'extensions, et la quasi-totalité des certificats actuellement en service sont de version 3.

Encodage : DER vs PEM.
La norme définit le contenu d’un certificat, mais pas la manière de l’encoder pour le stockage ou le transport. Deux formats s’imposent. Le format DER (Distinguished Encoding Rules) est un format binaire compact, traité efficacement par les navigateurs, les systèmes d’exploitation et les applications Java, et utilise généralement les extensions .der ou .cer. Le format PEM (Privacy Enhanced Mail) convertit ces données binaires en texte Base64, reconnaissable à son en-tête « BEGIN CERTIFICATE » ; c’est le choix le plus courant sur les systèmes Linux, les serveurs web et les outils en ligne de l command, tels qu’OpenSSL. Les deux formats contiennent des données identiques ; la seule différence réside dans leur représentation, et la conversion entre les deux est très simple.

Cas d'utilisation.
Les certificats X.509 assurent la sécurité du Web via HTTPS, la sécurité des e-mails via S/MIME, la signature de code, l'authentification des appareils, l'authentification VPN et l'TLS mutuelle pour les API. Ils sécurisent également les technologies opérationnelles, où des normes telles que l'OPC UA s'appuient sur eux et où la norme CEI 62443 impose une sécurité basée sur des certificats au-delà d'un certain niveau d'assurance.

Certificats SSH

L'authentification par clé SSH simple oblige à la fois le client et le serveur à stocker et à gérer manuellement des listes de clés de confiance, ce qui est difficile à faire évoluer et expose au risque d'usurpation d'identité lors de l'échange de clés. Les certificats SSH résolvent ce problème en associant une identité à une clé et en réduisant le point de confiance à une seule autorité de certification (CA) capable d'authentifier à la fois les clients et les serveurs.

SSH définit deux types de certificats : les certificatsd'utilisateurpour les clients et les certificatsd'hôtepour les serveurs. Contrairement aux noms distinctifs utilisés par X.509, les certificats SSH s'appuient surdes entités, qui associent un certificat à des identités spécifiques : les noms d'utilisateur pour les clients et les noms d'hôte pour les serveurs. Les certificats peuvent également comporter des options critiques qui restreignent leur utilisation, notamment :

• force-command, ce qui verrouille le certificat sur une seule adresse command , quelle que soit la saisie de l'utilisateur.
• « adresse source » : liste des adresses à partir desquelles le certificat peut être utilisé.
• « verify-required », qui nécessite une vérification de l'utilisateur via FIDO, par exemple à l'aide d'un code PIN ou d'une donnée biométrique pour les clés de sécurité.

SSH prend en charge le RSA quelle que soit la taille, les courbes elliptiques EC P256, P384 et P521, ainsi que l'algorithme ed25519. Il convient de noter que l'algorithme de signature n'est pas sélectionné séparément ; dans SSH, il est défini par le type de clé. Et comme SSH ne définit pas de hiérarchie d'autorités de certification, les autorités de certification SSH sont généralement auto-signées et reposent uniquement sur la clé publique.

Certificats OpenPGP

Les certificats OpenPGP adoptent une approche fondamentalement différente en matière de confiance. Au lieu de faire passer chaque décision par une autorité centrale, OpenPGP utilise un « réseau de confiance » décentralisé dans lequel tout utilisateur peut se porter garant de l'identité d'un autre utilisateur en signant sa clé. La confiance se construit à partir des avals de nombreux pairs plutôt que de provenir d'une seule racine.

Ce modèle reflète les origines d’OpenPGP dans la signature sécurisée d’e-mails et de fichiers entre particuliers et communautés, où aucune autorité centrale partagée n’existe ni n’est souhaitée. Sa force réside dans l’autonomie : aucun « gardien » ne décide qui peut participer. Sa faiblesse tient à l’échelle et à la cohérence, car la confiance dépend du degré de connexion d’une clé donnée au sein du réseau et de la rigueur avec laquelle les participants se vérifient mutuellement avant de signer. C’est pourquoi le réseau de confiance a tendance à fonctionner mieux au sein de communautés très soudées plutôt que sur l’Internet ouvert, où le modèle hiérarchique est devenu dominant.

Formats JOSE (JWT, JWS, JWK)

La famille JOSE, acronyme de « JSON Object Signing and Encryption », garantit l'identité et l'intégrité des systèmes basés sur JSON, plutôt que sur les structures binaires sur lesquelles repose la norme X.509. Il est utile de la connaître à titre de comparaison, car elle est omniprésente dans le développement web et d'API moderne, même si elle ne constitue pas un format de certificat au sens traditionnel du terme.

• Le JWT (JSON Web Token)est un jeton compact et compatible avec les URL qui contient des informations relatives à un sujet ; on le connaît surtout sous la forme de jetons « bearer » utilisés dans l'authentification Web et l'authentification unique.
• Le protocole JWS (JSON Web Signature)définit la manière de signer ce contenu JSON afin que le destinataire puisse vérifier qu'il n'a pas été altéré.
• JWK (JSON Web Key)représente une clé cryptographique sous la forme d'un objet JSON, ce qui simplifie la distribution des clés pour les services qui utilisent déjà le format JSON.

Alors que le protocole X.509 regroupe une identité et une clé publique au sein d’un certificat signé et validé par une chaîne d’autorités de certification, les formats JOSE permettent généralement de transférer des revendications signées et des clés entre des services qui entretiennent déjà une relation de confiance, comme un fournisseur d’identité et les applications qui s’appuient sur lui. Ces deux approches coexistent souvent : une passerelle API peut par exemple établir une connexion TLS à l’aide d’un certificat X.509, puis autoriser la requête à l’aide d’un JWT.

Comparaison des familles de formats en un coup d'œil

Format	Modèle de confiance	Utilisation courante	Encodage
X.509	Autorités de certification hiérarchiques	TLS, S/MIME, signature de code, authentification par périphérique et mTLS	DER (binaire) ou PEM (texte Base64)
SSH	Autorité de certification SSH unique, généralement auto-signée	Authentification client-serveur pour l'accès à distance	Format de certificat SSH, utilisant une clé RSA, EC ou ed25519
OpenPGP	Réseau de confiance décentralisé	Signature et chiffrement des e-mails et des fichiers	Format des messages et des clés OpenPGP
JOSE (JWT/JWS/JWK)	Confiance partagée entre les services	Jetons Web et API, revendications et échange de clés	Texte JSON

La distinction la plus nette réside dans le modèle de confiance. Les protocoles X.509 et SSH s'appuient sur des autorités désignées, OpenPGP répartit la confiance entre les pairs, tandis que JOSE part du principe qu'une relation de confiance existe déjà entre les services échangeant des jetons.

Le modèle de confiance : comment les certificats instaurent la confiance

Derrière chaque format se cache une question de confiance : pourquoi une partie de confiance devrait-elle croire un certificat ? Deux modèles apportent une réponse à cette question.

Lemodèle hiérarchiqueplace les autorités de certification au sommet de la hiérarchie. Un petit nombre d'autorités racines jouissant d'une large confiance constituent le fondement du système, et tous les autres éléments tirent leur crédibilité de celles-ci. Leréseau de confiance décentralisé, utilisé par OpenPGP, répartit la confiance entre des pairs qui se garantissent mutuellement, sans point d'ancrage central.

Les deux approches sont valables, mais elles évoluent différemment. Le modèle hiérarchique est celui qui sous-tend l'utilisation en entreprise et sur Internet, car les décisions centralisées en matière de confiance et la validation automatisée répondent précisément aux besoins des environnements de grande envergure et en constante évolution. Le réseau de confiance, en revanche, prospère au sein de communautés plus restreintes où les participants peuvent se vérifier mutuellement de manière personnelle.

Chaînes de certificats et autorités de certification

La confiance hiérarchique repose sur une chaîne que le client peut parcourir depuis le certificat qui lui est présenté jusqu'à une racine à laquelle il fait déjà confiance. Une chaîne type comporte trois niveaux :

1. Un certificat d'autorité de certification racine auto-signé, préinstallé dans les magasins de certificats de confiance du navigateur et du système d'exploitation, dont la clé privée est conservée en toute sécurité hors ligne.
2. Un certificat d'autorité de certification intermédiaire, qui se charge au quotidien de signer les certificats afin que la clé racine reste protégée.
3. Le certificat d'entité finaleprésenté par un site web, un serveur ou un appareil.

Lorsqu'un client reçoit un certificat d'entité finale, il valide chaque signature en remontant la chaîne, n'acceptant le certificat que si chaque maillon est valide et qu'il aboutit à une racine de confiance. Les magasins de certificats varient selon les clients. Firefox gère son propre magasin contenant environ 120 racines de confiance pour TLS, selon laliste des certificats CA inclus de Mozilla, tandis que Chrome s'en remet généralement au magasin du système d'exploitation, à quelques exceptions près, telles que sa liste distincte pour la validation étendue (Extended Validation) et ses exigences en matière de transparence des certificats (Certificate Transparency). La confiance peut même s'étendre à d'autres organisations grâce à la certification croisée, dans laquelle deux racines signent mutuellement leurs certificats, de sorte que les clients faisant confiance à l'une d'entre elles acceptent les certificats émis par l'autre.

Niveaux de validation

Tout système de certification, quel que soit son format, doit répondre à la même question avant de délivrer quoi que ce soit : dans quelle mesure sommes-nous sûrs que le sujet est bien celui qu’il prétend être ? La réponse n’étant jamais binaire, chaque famille de certificats développe une méthode pour évaluer ce niveau de confiance et communiquer cette évaluation à toute personne qui s’appuiera ultérieurement sur le certificat. Dans TLS , il s’agit de l’échelle bien connue de la validation de domaine (Domain Validation), qui prouve uniquement le contrôle d’un nom ; de la validation d’organisation (Organization Validation), qui vérifie en outre qu’une entité juridique existe et est liée à ce nom ; et de la validation étendue (Extended Validation), qui ajoute les documents constitutifs, la présence physique et la confirmation du pouvoir de signature. La signature de code utilise la même logique de niveaux, son niveau le plus bas ayant été supprimé, de sorte que l’identité de l’éditeur est désormais toujours vérifiée au niveau de l’organisation à l’aide de clés conservées dans hardware. Les certificats client et S/MIME suivent le même schéma, allant du contrôle de la boîte mail jusqu’à l’identité individuelle vérifiée et étayée par des documents officiels. Dans chaque cas, le niveau est enregistré sous la forme d’un OID de politique à l’intérieur du certificat, ce qui permet à une partie qui s’y fie de lire le niveau d’assurance plutôt que de le déduire.

Ce même instinct se manifeste partout où des certificats sont utilisés, même dans des systèmes qui ne ressemblent en rien au modèle des autorités de certification publiques. PGP l'enregistre sous la forme d'une valeur de confiance que le signataire attribue à chaque signature, permettant ainsi à la partie qui s'y fie de peser plusieurs attestations plutôt que de se fier à une seule. SSH l’enregistre implicitement, dans le processus de provisionnement qui sous-tend l’autorité de certification : un certificat délivré uniquement après l’inscription de l’hôte dans le système de gestion de configuration, ou après l’authentification de l’utilisateur auprès d’un fournisseur d’identité, offre exactement le même niveau d’assurance que celui fourni par ces vérifications en amont, ce qui explique pourquoi les autorités de certification SSH peuvent délivrer en toute sécurité des certificats en quelques heures. Ce qui diffère d’une famille à l’autre, c’est l’endroit où ce niveau de confiance est consigné et la personne à qui l’on fait confiance pour l’attribuer. Ce qu’elles ont en commun, c’est la reconnaissance du fait qu’un certificat n’est jamais plus solide que la vérification d’identité effectuée avant sa signature, et que la solidité de cette vérification doit accompagner le certificat plutôt que d’être laissée à la conjecture de la partie qui s’y fie.

Certificats auto-signés et certificats émis par une autorité de certification

Un certificat auto-signé est signé par l’entité même qui l’a créé. Il permet certes l’authentification, mais n’offre aucune vérification indépendante de l’identité. L’analogie avec le passeport est pertinente : écrire son propre nom sur un bout de papier et le présenter à la frontière donne un joli document, mais sans aucune preuve d’identité derrière. Les professionnels qualifient les certificats auto-signés de non gérés et non vérifiés, car personne ne surveille la date d'expiration que le créateur a discrètement fixée. Lorsque ces certificats expirent, cela entraîne souvent une interruption de service, et les problèmes liés aux certificats auto-signés en sont une cause fréquente.

C’est pourquoi les certificats auto-signés ne conviennent qu’à des environnements contrôlés et hors production, tels que le développement local, les laboratoires internes isolés et les démonstrations de faisabilité. Les certificats émis par une autorité de certification (CA) sont obligatoires en production, car ils fournissent une chaîne de confiance vérifiable que les navigateurs et les applications valident automatiquement, adossée à une autorité ayant vérifié l’identité du titulaire et à un cycle de vie géré qui assure le suivi de l’expiration. Une nuance mérite d’être soulignée : les certificats d’autorité de certification racine sont eux-mêmes auto-signés, mais il s’agit là d’une propriété structurelle d’un ancrage de confiance, la confiance étant conférée par leur distribution dans des magasins de confiance plutôt que par la signature.

Révocation de certificat

Les certificats comportent une date d'expiration par défaut, mais celle-ci ne suffit pas à elle seule. Il arrive parfois qu'un certificat doive être invalidé bien avant sa date d'expiration, par exemple lorsqu'une clé privée est compromise, qu'un système est mis hors service ou qu'un certificat n'est tout simplement plus nécessaire. Dès qu'on constate qu'une clé privée a été compromise, le certificat est considéré comme non valide, quelle que soit la durée de validité restante.

Il est utile de distinguer deux concepts.L'expirationcorrespond à la période de validité passive intégrée à chaque certificat.La révocation, quant à elle, désigne la mesure active consistant à retirer la confiance avant l'expiration de cette période. La révocation est une étape fondamentale de la gestion du cycle de vie des certificats et le mécanisme qui garantit l'intégrité de la chaîne de confiance lorsque les conditions réelles évoluent plus rapidement que ne le permettent les périodes de validité.

Fonctionnement de la vérification des révocations (CRL et OCSP)

Les parties qui se fient à un certificat doivent pouvoir savoir qu'un certificat a été révoqué. Deux mécanismes prédominent.

Uneliste de révocation de certificats (CRL)est un fichier signé et horodaté, publié par une autorité de certification (CA), qui répertorie les numéros de série des certificats révoqués avant leur date d’expiration. Définie dans la RFC 5280, chaque entrée comprend le numéro de série, la date de révocation et, éventuellement, un code de motif tel que la compromission de la clé ou la cessation d’activité. Une partie de confiance retrouve cette liste grâce à l’extension « CRL Distribution Points » (Points de distribution des CRL) présente dans le certificat, la télécharge, puis vérifie si le numéro de série y figure. Les CRL sont simples et universellement prises en charge, mais leur taille peut devenir importante ; c’est pourquoi il existe des CRL partitionnées et des CRL delta, qui permettent de limiter la taille des téléchargements. Vous pouvez approfondir vos connaissances surce qu’est une liste de révocation de certificats dans ce guide.

Leprotocole OCSP (Online Certificate Status Protocol), défini dans la RFC 6960, inverse ce modèle. Au lieu de télécharger une liste complète, le client se renseigne sur un seul certificat en interrogeant le répondeur OCSP indiqué dans l’extension « Authority Information Access » du certificat. Le répondeur renvoie une brève réponse signée indiquant « valide », « révoqué » ou « inconnu ». L’« OCSP stapling » améliore encore ce processus en permettant au serveur web de récupérer et de mettre en cache la réponse, puis de la transmettre lors de la négociation de la connexion « TLS », ce qui réduit la latence et protège la vie privée des utilisateurs. Pouren savoir plus sur lefonctionnement de l’OCSP, consultez cet article explicatif.

Ces deux approches impliquent un compromis entre actualité et efficacité, et de nombreuses équipes utilisent les deux. Si vous hésitez entre les deux, cette comparaison entreCRL et OCSPvous aidera à prendre une décision. À noter : pour le Web public, les navigateurs s'orientent de plus en plus vers des données de révocation distribuées localement, tandis que les protocoles OCSP et CRL restent essentiels pour les environnements d'PKI d'entreprise et privés.

Révocation sur tous les formats

La révocation ne s'applique pas de la même manière selon les types de certificats. SSH, par exemple, utilise des listes de révocation de clés (KRL) plutôt que des listes de révocation de certificats (CRL) de type X.509, et s'appuie largement sur des certificats à courte durée de vie, parfois même éphémères. Lorsqu’un certificat n’a qu’une durée de vie de quelques heures, la fenêtre dans laquelle la révocation a une importance se réduit considérablement, ce qui diminue d’emblée le recours à la vérification de la révocation. Ce modèle, qui privilégie les durées de vie courtes plutôt que l’invalidation active, exerce une influence croissante dans l’univers des certificats en général, alors que la durée de vie publique des certificats tend à se réduire à 47 jours.

Comment Keyfactor vous aider

Gérer un seul certificat est facile. Gérer l'ensemble des certificats et de tous les formats au sein d'une entreprise, sans interruption de service ni lacunes dans les politiques, voilà le véritable défi, et c'est là que l'automatisation devient indispensable. À mesure que la durée de vie des certificats se raccourcit pour atteindre des renouvellements tous les 47 jours, le volume opérationnel des renouvellements est multiplié par huit environ, et les tableurs ainsi que les rappels par e-mail ne suffisent plus.

Keyfactor répond à ce besoin grâce à une approche de bout en bout de l'automatisation du cycle de vie des certificats pour les normes X.509 et SSH. EJBCA, sa plateforme d’ PKI s d’entreprise, émet et gère les certificats à grande échelle, prend en charge les protocoles d’inscription standard tels que SCEP, CMP, EST et ACME, et offre la flexibilité cryptographique nécessaire à la transition vers l’ère post-quantique. Keyfactor Command Elle s’intègre à toutes les autorités de certification (CA) de l’environnement pour permettre, à partir d’un seul et même endroit, la découverte, l’inventaire, la surveillance, le renouvellement et la révocation, ainsi que la surveillance des terminaux via CRL et OCSP, afin qu’aucune liste expirée ou aucun répondeur inaccessible ne passe inaperçu. Pour les équipes qui préfèrent ne pas gérer elles-mêmes l’infrastructure, l’ PKI as a Service fournit une infrastructure gérée d’ PKI s et de révocations.

Les avantages découlent directement des défis abordés dans ce guide : réduction des interruptions de service, application cohérente des politiques, préparation à des durées de validité plus courtes des certificats et prise d'avance sur la cryptographie post-quantique.