Thousands of people around the world make our work possible. Donate today.
Let's Encrypt

Chaînes de confiance

Dernière mise à jour :

Cette page décrit toutes les autorités de certification actuelles et historiques gérées par Let’s Encrypt. Notez qu’une AC est plus correctement considérée comme une clé et un nom : une AC donnée peut être représentée par plusieurs certificats qui contiennent tous les mêmes informations sur le sujet et la clé publique. Dans ce cas, nous avons fourni les détails de tous les certificats qui représentent l’AC.

Diagramme de la hiérarchie des certificats de l’ISRG, à partir de juin 2024

AC racine

Notre clé racine est conservé en toute sécurité hors ligne. Nous délivrons des certificats d’entité finale aux abonnés des intermédiaires décrits dans la section suivante. Tous les objets des certificats racine ont un champ Pays de C = US.

Notez que les AC racines n’ont pas de date d’expiration comme les autres certificats. Bien que leurs certificats auto-signés contiennent une date notAfter, les programmes racines et les magasins de confiance peuvent décider de faire confiance à une autorité de certification racine au-delà de cette date ou de mettre fin à la confiance qu’ils lui accordent avant cette date. Les dates de fin de validité indiquées ci-dessous sont donc approximatives et se fondent sur les politiques actuelles du programme Root.

Pour de plus amples informations sur la compatibilité de nos certificats racine avec divers appareils et magasins de confiance, voir Compatibilité des certificats.

AC subordonnées (intermédiaires)

Nous avons actuellement quatre intermédiaires en circulation active. Les certificats d’abonné contenant une clé publique ECDSA seront délivrés par l’un des intermédiaires ECDSA ; de même, les certificats d’abonné contenant une clé publique RSA seront délivrés par l’un des intermédiaires RSA.

Tous les objets de certificats intermédiaires ont un champ Pays (Country) de C = US.

Cliquez ci-dessous pour plus de détails sur les intermédiaires supplémentaires qui ne font pas partie de la hiérarchie des émissions actives :

Sauvegarde

Ces autorités de certification intermédiaires disposent de certificats en cours de validité, mais ne sont pas émises par elles. Nous pouvons commencer à émettre des certificats d’abonné à partir de ces derniers à tout moment, sans avertissement.

  • Let’s Encrypt E7
    • Objet : O = Let's Encrypt, CN = E7
    • Type de clé : ECDSA P-384
    • Validité : jusqu’au 2027-03-12
    • Détails de l’AC : crt.sh, certificats délivrés
    • Détails du certificat (signé par l’AC racine ISRG X2) : der, pem, txt
    • Détails du certificat (signé par l’AC racine ISRG X1) : der, pem, txt
  • Let’s Encrypt E8
    • Objet : O = Let's Encrypt, CN = E8
    • Type de clé : ECDSA P-384
    • Validité : jusqu’au 2027-03-12
    • Détails de l’AC : crt.sh, certificats délivrés
    • Détails du certificat (signé par l’AC racine ISRG X2) : der, pem, txt
    • Détails du certificat (signé par l’AC racine ISRG X1) : der, pem, txt
  • Let’s Encrypt E9
    • Objet : O = Let's Encrypt, CN = E9
    • Type de clé : ECDSA P-384
    • Validité : jusqu’au 2027-03-12
    • Détails de l’AC : crt.sh, certificats délivrés
    • Détails du certificat (signé par l’AC racine ISRG X2) : der, pem, txt
    • Détails du certificat (signé par l’AC racine ISRG X1) : der, pem, txt
  • Let’s Encrypt R12
    • Objet : O = Let's Encrypt, CN = R12
    • Type de clé : RSA 2048
    • Validité : jusqu’au 2027-03-12
    • Détails de l’AC : crt.sh, certificats délivrés
    • Détails du certificat (signé par l’AC racine ISRG X1) : der, pem, txt
  • Let’s Encrypt R13
    • Objet : O = Let's Encrypt, CN = R13
    • Type de clé : RSA 2048
    • Validité : jusqu’au 2027-03-12
    • Détails de l’AC : crt.sh, certificats délivrés
    • Détails du certificat (signé par l’AC racine ISRG X1) : der, pem, txt
  • Let’s Encrypt R14
    • Objet : O = Let's Encrypt, CN = R14
    • Type de clé : RSA 2048
    • Validité : jusqu’au 2027-03-12
    • Détails de l’AC : crt.sh, certificats délivrés
    • Détails du certificat (signé par l’AC racine ISRG X1) : der, pem, txt
Retiré

Ces autorités de certification intermédiaires ne sont plus utilisées pour émettre des certificats pour les souscripteurs. Ceux qui ont encore des certificats valides peuvent produire des réponses OCSP et/ou des CRL.

  • Let’s Encrypt E1
    • Objet : O = Let's Encrypt, CN = E1
    • Type de clé : ECDSA P-384
    • Validité : jusqu’au 2025-09-15
    • Détails de l’AC : crt.sh, certificats délivrés
    • Détails du certificat (signé par l’AC racine ISRG X2) : crt.sh, der, pem, txt
  • Let’s Encrypt E2
    • Objet : O = Let's Encrypt, CN = E2
    • Type de clé : ECDSA P-384
    • Validité : jusqu’au 2025-09-15
    • Détails de l’AC : crt.sh, certificats délivrés
    • Détails du certificat (signé par l’AC racine ISRG X2) : crt.sh, der, pem, txt
  • Let’s Encrypt R3
    • Objet : O = Let's Encrypt, CN = R3
    • Type de clé : RSA 2048
    • Validité : jusqu’au 2025-09-15
    • Détails de l’AC : crt.sh, certificats délivrés
    • Détails du certificat (signé par l’AC racine ISRG X1) : crt.sh, der, pem, txt
    • Détails du certificat (signé par IdenTrust) : crt.sh, der, pem, txt
  • Let’s Encrypt R4
    • Objet : O = Let's Encrypt, CN = R4
    • Type de clé : RSA 2048
    • Validité : jusqu’au 2025-09-15
    • Détails de l’AC : crt.sh, certificats délivrés
    • Détails du certificat (signé par l’AC racine ISRG X1) : crt.sh, der, pem, txt
    • Détails du certificat (signé par IdenTrust) : crt.sh, der, pem, txt
  • Let’s Encrypt Authority X1
    • Objet : O = Let's Encrypt, CN = Let's Encrypt Authority X1
    • Type de clé : RSA 2048
    • Validité : expiré le 2020-06-04
    • Détails de l’AC : crt.sh, certificats délivrés
    • Détails du certificat (signé par l’AC racine ISRG X1) : crt.sh, der, pem, txt
    • Détails du certificat (signé par IdenTrust) : crt.sh, der, pem, txt
  • Let’s Encrypt Authority X2
    • Objet : O = Let's Encrypt, CN = Let's Encrypt Authority X2
    • Type de clé : RSA 2048
    • Validité : expiré le 2020-06-04
    • Détails de l’AC : crt.sh, certificats délivrés
    • Détails du certificat (signé par l’AC racine ISRG X1) : crt.sh, der, pem, txt
    • Détails du certificat (signé par IdenTrust) : crt.sh, der, pem, txt
  • Let’s Encrypt Authority X3
    • Objet : O = Let's Encrypt, CN = Let's Encrypt Authority X3
    • Type de clé : RSA 2048
    • Validité : expiré le 2021-10-06
    • Détails de l’AC : crt.sh, certificats délivrés
    • Détails du certificat (signé par l’AC racine ISRG X1) : crt.sh, der, pem, txt
    • Détails du certificat (signé par IdenTrust) : crt.sh, der, pem, txt
  • Let’s Encrypt Authority X4
    • Objet : O = Let's Encrypt, CN = Let's Encrypt Authority X4
    • Type de clé : RSA 2048
    • Validité : expiré le 2021-10-06
    • Détails de l’AC : crt.sh, certificats délivrés
    • Détails du certificat (signé par l’AC racine ISRG X1) : crt.sh, der, pem, txt
    • Détails du certificat (signé par IdenTrust) : crt.sh, der, pem, txt
Protocole de Vérification de Certificat en Ligne (Online Certificate Status Protocol : OCSP)

Cette paire de clés était auparavant utilisée pour signer les réponses OCSP concernant l’état des intermédiaires de Let’s Encrypt au nom de la racine de Let’s Encrypt, afin que la racine puisse rester hors ligne en toute sécurité. Nous n’émettons plus de réponses OCSP pour nos intermédiaires ; à la place, nous émettons périodiquement des CRL à partir de notre racine pour communiquer l’état de révocation de nos intermédiaires.

  • Racine ISRG OCSP X1
    • Objet : O = Internet Security Research Group, CN = ISRG Root OCSP X1
    • Type de clé : RSA 2048
    • Validité : jusqu’au 2025-06-10
    • Détails du certificat (signé par l’AC racine ISRG X1) : crt.sh, der, pem, txt
    • Détails du certificat (signé par l’AC racine ISRG X1) : crt.sh (expiré)

Chaînes

Lorsqu’un client ACME télécharge un certificat nouvellement émis à partir de l’API ACME de Let’s Encrypt, ce certificat fait partie d’une « chaîne » qui comprend également un ou plusieurs intermédiaires. En général, cette chaîne se compose uniquement du certificat de l’entité finale et d’un intermédiaire, mais elle peut contenir des intermédiaires supplémentaires. L’idée est qu’en présentant toute cette chaîne de certificats au navigateur du visiteur d’un site web, ce dernier pourra valider les signatures jusqu’à une racine en laquelle il a confiance, sans avoir à télécharger d’intermédiaires supplémentaires.

Il existe parfois plus d’une chaîne valide pour un certificat donné : par exemple, si un certificat intermédiaire a fait l’objet d’une signature croisée, l’un ou l’autre de ces deux certificats peut constituer la deuxième entrée, « remontant » jusqu’à l’une ou l’autre des deux racines différentes. Dans ce cas, différents opérateurs de sites web peuvent vouloir sélectionner différentes chaînes en fonction des propriétés qui leur tiennent le plus à cœur.

Les certificats d’abonné avec des clés publiques RSA sont délivrés par nos intermédiaires RSA, qui sont délivrés uniquement par notre racine RSA ISRG Root X1 (c’est-à-dire qu’ils ne font pas l’objet d’une signature croisée). Par conséquent, tous les certificats d’abonné RSA ne disposent que d’une seule chaîne :

RSA Subcriber Cert ← RSA Intermediate (R10 or R11) ← ISRG Root X1

Les certificats d’abonné avec des clés publiques ECDSA sont délivrés par nos intermédiaires ECDSA, qui sont délivrés à la fois par notre racine RSA de l’ISRG X1 et par notre racine ECDSA de l’ISRG X2 (c’est-à-dire qu’ils font l’objet d’une signature croisée). C’est pourquoi nous proposons deux chaînes pour ces certificats :

ECDSA Subcriber Cert ← ECDSA Intermediate (E5 or E6) ← ISRG Root X1

ECDSA Subcriber Cert ← ECDSA Intermediate (E5 or E6) ← ISRG Root X2

La première chaîne, jusqu’à l’ISRG Root X1, offre la plus grande compatibilité, car ce certificat racine est inclus dans la plupart des magasins de confiance. La deuxième chaîne, jusqu’à l’ISRG Root X2, consomme moins d’octets de la bande passante du réseau lors de chaque handshake TLS. Nous fournissons la première chaîne par défaut, afin d’assurer la plus grande compatibilité possible. Les utilisateurs qui souhaitent privilégier la taille plutôt que la compatibilité peuvent consulter la documentation de leur client ACME pour savoir comment demander la chaîne alternative (par exemple, certbot’s --preferred-chain flag).