Certificats SSL/TLS — Ce que signifient exactement ces champs et les dates de péremption

À un moment donné, vous avez regardé le petit verrou dans le navigateur, cliqué sur « Voir le certificat » et été confronté à une multitude de champs qui semblent importants mais qui ne sont pas expliqués : « Noms d'alternance », « OCSP », « SHA-256 avec chiffrement RSA ». Vous fermez la fenêtre. Le certificat est vert. Cela suffit.

Jusqu'à son expiration. À minuit un vendredi. En production.

Cet article décrit ce qui se trouve réellement dans un certificat TLS — champ par champ — afin que, la prochaine fois que vous devrez déboguer un certificat, vous sachiez ce que vous lisez.

Un certificat est simplement un document signé

Enlever la cérémonie et un certificat TLS est un document texte contenant quelques faits — qui possède ce domaine, quelle clé publique ils utilisent, quand ce document expire — qui a été cryptographiquement signé par une autorité de certification (CA). La signature de la CA est ce qui fait que les navigateurs l'acceptent. Tout le reste est une annotation.

Le format sous-jacent s'appelle X.509. Il a été défini en 1988, révisé plusieurs fois, et est maintenant spécifié dans RFC 5280. C'est la raison pour laquelle les dialogues de détails des certificats dans les navigateurs ont l'air conçus par des personnes qui considèrent 1988 comme une époque récente.

Les champs clés, expliqués

Voici une analyse annotée des champs que vous verrez dans un certificat réel. Les données brutes PEM ci-dessous sont représentatives (pas un certificat en ligne) :

Certificate:
  Data:
    Version: 3 (0x2)                          # Always v3 for modern certs
    Serial Number:                             # Unique ID issued by the CA
      04:b3:c2:...(truncated)
    Signature Algorithm: sha256WithRSAEncryption  # Hash + key algorithm used to sign
    Issuer:
      C  = US                                 # Country
      O  = Let's Encrypt                      # Organization (the CA)
      CN = R11                                # Common Name of the issuer
    Validity:
      Not Before: Apr  1 00:00:00 2026 GMT    # Cert isn't valid before this date
      Not After : Jun 30 23:59:59 2026 GMT    # Cert is invalid after this date
    Subject:
      CN = iotools.cloud                      # Domain this cert was issued for
    Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
      Public-Key: (2048 bit)                  # RSA key size
    X509v3 extensions:
      Subject Alternative Names:
        DNS:iotools.cloud                     # All domains this cert covers
        DNS:www.iotools.cloud
      Key Usage: Digital Signature, Key Encipherment
      Extended Key Usage: TLS Web Server Authentication
      Basic Constraints: CA:FALSE             # This is NOT a CA cert
      Authority Key Identifier: ...           # Fingerprint of issuer's key
      Subject Key Identifier: ...             # Fingerprint of this cert's key
      Certificate Policies: ...
        CPS: http://cps.letsencrypt.org
      OCSP: http://r11.o.lencr.org           # Where to check revocation status

Nom commun (CN)

Le champ initial pour spécifier quel domaine est couvert par le certificat. Vous verrez encore ce champ rempli — CN = example.com — mais les navigateurs ont principalement cessé de le dépendre. Depuis 2000, l'extension des Noms d'alternance est le champ autorisé pour le match de domaine. Le CN est aujourd'hui essentiellement obsolète ; si SAN existe, les navigateurs utilisent SAN uniquement.

Noms d'alternance (SAN)

C'est la véritable liste des domaines que le certificat sécurise. Un seul certificat peut couvrir des dizaines de noms — des entrées de type wildcards (*.example.com), des noms exacts, voire des adresses IP. Les certificats multidomaines (parfois appelés SANs ou UCC certs) sont une pratique standard. L'autorité de certification émet contre cette liste, et les navigateurs vérifient le nom d'hôte que vous visitez contre cette liste.

Une chose que les wildcards ne pouvez pas font : couvrir les sous-sous-domaines. *.example.com couvre app.example.com mais pas api.v2.example.com. Beaucoup de gens découvrent cela de manière difficile.

Période de validité

Deux dates : Avant la date de début et Après la date de fin. Le certificat est invalide en dehors de cette fenêtre — avant la date de début, après l'expiration. Les deux sont en UTC.

Les durées maximales des certificats ont été réduites de manière progressive. En 2015, la durée maximale était de 3 ans. En 2018, elle est tombée à 2 ans. En 2020, Apple a unilatéralement commencé à rejeter les certificats plus longs que 398 jours (environ 13 mois), forçant les fournisseurs de navigateurs et les autorités de certification à les suivre. À partir de 2026, le CA/Browser Forum a ratifié un plan de réduction de cette durée à 47 jours d'ici 2027.

L'argument en faveur de durées plus courtes est solide : si une clé privée est compromise, un certificat de courte durée limite la zone d'impact. La réalité opérationnelle est que des durées plus courtes augmentent la pression sur votre automatisation de renouvellement pour être correcte. Les certificats de 90 jours de Let's Encrypt ont été controversés en 2015 pour la même raison ; aujourd'hui, ils sont considérés comme la meilleure pratique et l'automatisation de renouvellement est attendue.

Émetteur et la chaîne de confiance

Le Émetteur le champ indique l'entité qui a signé le certificat. Pour la plupart des sites publics, c'est une CA intermédiaire (comme R11 de Let's Encrypt), et non une CA racine. Les CAs racines signent les certificats d'intermédiaires ; les CAs intermédiaires signent les certificats d'entité (ceux que votre serveur présente). Cette chaîne existe parce que les clés privées des CAs racines sont conservées hors ligne dans des HSMs isolés, et vous ne pouvez pas exposer une clé pour signer des millions de certificats par an.

Lorsque un navigateur valide votre certificat, il parcourt la chaîne : votre certificat → intermédiaire → racine. Si la racine est présente dans le stock de confiance du navigateur, la chaîne est valide. Si un certificat dans la chaîne est manquant, expiré ou signé avec une clé révoquée, la validation échoue.

C'est la raison pour laquelle la configuration TLS la plus courante est d'oublier de servir le certificat intermédiaire en parallèle de votre certificat de feuille. Votre navigateur pourrait stocker l'intermédiaire et sembler correct, tandis que d'autres clients — curl, les applications mobiles, les serveurs effectuant des appels API — échouent car ils n'ont pas de chemin vers la racine.

Algorithme de signature

Deux éléments regroupés dans un seul champ : la fonction de hachage utilisée pour digérer les données du certificat, et l'algorithme de clé utilisé pour signer ce hachage. sha256WithRSAEncryption signifie un hachage SHA-256, signature RSA. ecdsa-with-SHA256 signifie un hachage SHA-256, signature ECDSA.

Les signatures SHA-1 ont été dépréciées par les navigateurs en 2017 et provoquent maintenant des échecs. Les signatures MD5 ont été dépréciées plus tôt et sont effectivement disparues. Si vous gérez un système qui émet des certificats SHA-1, mettez à jour votre configuration de CA avant qu'un mises à jour de navigateur ne le fasse pour vous.

Les clés ECDSA (souvent P-256 ou P-384) produisent des clés et des signatures plus petites que les clés RSA pour une sécurité équivalente. Une clé EC de 256 bits est environ équivalente à une clé RSA de 3072 bits. L'échange : RSA est plus universellement compatible avec des clients très anciens ; ECDSA est plus rapide et plus légère. Les déploiements modernes configurent souvent les deux et laissent le négociation TLS choisir.

Utilisation de la clé et utilisation étendue de la clé

Utilisation de la clé est un masque spécifiant ce que la clé est autorisée à faire : signer des données, chiffrer des données, signer d'autres certificats (seulement pour les CAs). Utilisation étendue de la clé affine cela pour des protocoles spécifiques : TLS Web Server Authentication permet à ce certificat d'être utilisé pour HTTPS. TLS Web Client Authentication est pour les certificats clients mTLS. Code Signing est pour les certificats de signature logicielle.

Si vous tentez d'utiliser un certificat pour un usage en dehors de son utilisation déclarée, les implémentations modernes de TLS le refusent. Vous ne pouvez pas utiliser un certificat de signature de code sur un serveur web, même si le domaine correspond.

Contraintes de base : CA : FAUX

Ce champ spécifie si le certificat peut être utilisé pour signer d'autres certificats. CA:FALSE signifie qu'il ne peut pas — c'est un certificat de feuille (d'entité finale). CA:TRUE signifie qu'il s'agit d'un certificat CA, autorisé à signer d'autres certificats dans la chaîne.

Le pathLenConstraint ce qui apparaît parfois en conjonction avec cela indique combien d'intermédiaires sont autorisés sous ce certificat. Les CAs racines définissent souvent cette valeur pour limiter la profondeur de la chaîne.

OCSP et annulation

L'URL OCSP (Protocole de statut en ligne du certificat) dans le certificat indique aux clients où vérifier s'il a été annulé avant l'expiration. L'annulation se produit lorsque la clé privée est compromise ou que le certificat a été émis en erreur.

En pratique, le contrôle OCSP des navigateurs a une histoire complexe. Chrome a arrêté les vérifications OCSP en ligne il y a plusieurs années en faveur des CRLSets (une liste préchargée de certificats annulés). Firefox fait encore des vérifications OCSP mais par défaut, elle est en mode « échec doux », ce qui signifie que si le serveur OCSP est inaccessible, le certificat est considéré comme valide. L'effet global : pour la plupart des certificats, l'annulation dans le monde réel est assez théorique. C'est l'un des arguments en faveur des certificats à durée courte — à 47 jours, l'annulation devient moins importante parce que le certificat expire bientôt.

Pourquoi les certificats expireront

L'expiration n'est pas une friction bureaucratique. C'est le mécanisme qui limite la durée pendant laquelle un credentiel compromis reste valide. L'alternative — des crédentiaux permanents — est celle qui vous mène à des certificats SHA-1 et à des clés de CAs datant de dix ans qui flottent encore en production, ce qui est largement ce que l'industrie était en 2010.

Le compromis est opérationnel : des durées plus courtes exigent une automatisation fiable. Si votre renouvellement dépend d'un rappel dans le calendrier d'un administrateur système, vous expirerez un jour en production. La bonne réponse est un renouvellement automatisé via ACME (le protocole de Let's Encrypt) ou l'API de votre CA, accompagné d'un monitoring qui alerte plusieurs semaines avant l'expiration plutôt que la nuit où il meurt.

Comment lire un certificat sans ligne de commande

La méthode standard pour inspecter un certificat est openssl x509 -in cert.pem -text -noout, qui produit une sortie formatée pour les personnes qui trouvent la lecture de RFC 5280 facile. Si vous souhaitez la même information dans un format qui ne nécessite pas de mémoriser les flags openssl, la Décoder le certificat SSL/TLS et Analyseur de certificat X.509 sur iotools.cloud prend un certificat PEM encodé et retourne chaque champ étiqueté et organisé — utile lorsque vous déboguez un problème de chaîne en pleine nuit et que le texte de openssl est trop dense.

Vous aimerez peut-être aussi