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.

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.

• Racine ISRG X1
  • Objet : O = Internet Security Research Group, CN = ISRG Root X1
  • Type de clé : RSA 4096
  • Validité : jusqu’en 2030-06-04 (généré en 2015-06-04)
  • Détails de l’AC : crt.sh, certificats délivrés
  • Détails du certificat (auto-signé) : crt.sh, der, pem, txt
  • Détails du certificat (signé par l’AC racine DST X3) : crt.sh, der, pem, txt (retiré)
  • Test de sites web : valide, révoqué, expiré
• Racine ISRG X2
  • Objet : O = Internet Security Research Group, CN = ISRG Root X2
  • Type de clé : ECDSA P-384
  • Validité : jusqu’au 2035-09-04 (généré le 2020-09-04)
  • Détails de l’AC : crt.sh, certificats délivrés
  • Détails du certificat (auto-signé) : crt.sh, der, pem, txt
  • Détails du certificat (signé par l’AC racine ISRG X1) : crt.sh, der, pem, txt
  • Test de sites web : valide, révoqué, expiré

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.

• Let’s Encrypt E5
  • Objet : O = Let's Encrypt, CN = E5
  • 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 E6
  • Objet : O = Let's Encrypt, CN = E6
  • 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 R10
  • Objet : O = Let's Encrypt, CN = R10
  • 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 R11
  • Objet : O = Let's Encrypt, CN = R11
  • 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

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 :

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 :

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 :

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).