100% of our funding comes from people like you. Donate today.

Chains of Trust

Seneste opdatering:

Denne side beskriver alle de nuværende og relevante historiske certificeringsmyndigheder, som drives af Let’s Encrypt. Bemærk, at en Certifikatmyndighed - CA - mest korrekt opfattes som en nøgle og et navn: enhver given CA kan være repræsenteret af flere certifikater, som alle indeholder den samme Emne og Offentlige nøgle Information. I sådanne tilfælde har vi givet nærmere oplysninger om alle de certifikater, der repræsenterer CA’en.

ISRG Certifikate Hierarki Diagram, fra juni 2024

Root CAs

Vores root certifikater holdes sikkert offline. Vi udsteder end-entity certifikater til abonnenter fra intermediate certifikater som beskrevet i næste afsnit. Alle root-certifikat Emner har et landefelt på C = US.

Bemærk, at Root CAs ikke har udløbsdatoer på helt samme måde som andre certifikater. Selv om deres selvsignerede certifikater indeholder en notAfter dato, Root Programs and Trust Stores kan vælge at have tillid til en Root CA efter denne dato, eller afslutte tilliden inden denne dato. Som sådan er de end-of-validity datoer angivet nedenfor omtrentlige, baseret på aktuelle Root Program politikker.

Se Certificate Compatibility for yderligere information om kompatibiliteten af vores rodcertifikater med forskellige enheder og trust stores.

Underordnede (CA’er)

Vi vedligeholder i øjeblikket fire mellemled i aktiv rotation. Abonnementscertifikater med en offentlig ECDSA-nøgle vil blive udstedt fra en af ECDSA-underordnet CA. Tilsvarende udstedes Abonnementscertifikater med en offentlig RSA-nøgle fra en af RSA-underordnet CA.

Alle underordnede certifikatemner har et landefelt på C = US.

Klik nedenfor for oplysninger om yderligere under ordnede Ca’er, som ikke er en del af det aktive udstedelseshierarki:

Backup

Disse underliggende CA’er har gyldige certifikater, men anvendes ikke til udstedelse. Vi kan til enhver tid begynde at udstede abonnentcertifikater fra dem uden varsel.

  • Let’s Encrypt E7
    • Emne: O = Let's Encrypt, CN = E7
    • Nøgletype: ECDSA P-384
    • Gyldighed: indtil 2027-03-12
    • CA detaljer: crt.sh, udstedte certifikater
    • Certifikatdetaljer (underskrevet af ISRG Root X2): der, pem, txt
    • Certifikatdetaljer (underskrevet af ISRG Root X1): der, pem, txt
  • Let’s Encrypt E8
    • Emne: O = Let's Encrypt, CN = E8
    • Nøgletype: ECDSA P-384
    • Gyldighed: indtil 2027-03-12
    • CA detaljer: crt.sh, udstedte certifikater
    • Certifikatdetaljer (underskrevet af ISRG Root X2): der, pem, txt
    • Certifikatdetaljer (underskrevet af ISRG Root X1): der, pem, txt
  • Let’s Encrypt E9
    • Emne: O = Let's Encrypt, CN = E9
    • Nøgletype: ECDSA P-384
    • Gyldighed: indtil 2027-03-12
    • CA detaljer: crt.sh, udstedte certifikater
    • Certifikatdetaljer (underskrevet af ISRG Root X2): der, pem, txt
    • Certifikatdetaljer (underskrevet af ISRG Root X1): der, pem, txt
  • Let’s Encrypt R12
    • Emne: O = Let's Encrypt, CN = R12
    • Nøgletype: RSA 2048
    • Gyldighed: indtil 2027-03-12
    • CA detaljer: crt.sh, udstedte certifikater
    • Certifikatdetaljer (underskrevet af ISRG Root X1): der, pem, txt
  • Let’s Encrypt R13
    • Emne: O = Let's Encrypt, CN = R13
    • Nøgletype: RSA 2048
    • Gyldighed: indtil 2027-03-12
    • CA detaljer: crt.sh, udstedte certifikater
    • Certifikatdetaljer (underskrevet af ISRG Root X1): der, pem, txt
  • Let’s Encrypt R14
    • Emne: O = Let's Encrypt, CN = R14
    • Nøgletype: RSA 2048
    • Gyldighed: indtil 2027-03-12
    • CA detaljer: crt.sh, udstedte certifikater
    • Certifikatdetaljer (underskrevet af ISRG Root X1): der, pem, txt
Trukket tilbage

Disse underordnede CA’er bruges ikke længere til at udstede Abonnentcertifikater. De, der stadig har gyldige certifikater, kan producere OCSP-svar og/eller CRL’er.

  • Let’s Encrypt E1
  • Let’s Encrypt E2
  • Let’s Encrypt R3
  • Let’s Encrypt R4
  • Let’s Encrypt Autoriteten X1
    • Om: O = Let's Encrypt, CN = Let's Encrypt Autoriteten X1
    • Nøgletype: RSA 2048
    • Gyldighed: udløbet 2020-06-04
    • CA detaljer: crt.sh, udstedte certifikater
    • Certifikat detaljer (underskrevet af ISRG Root X1): crt.sh, der, pem, txt
    • Certifikat detaljer (krydsunderskrevet af IdenTrust): crt.sh, der, pem, txt
  • Let’s Encrypt Autoriteten X2
    • Om: O = Let's Encrypt, CN = Let's Encrypt Autoriteten X2
    • Nøgletype: RSA 2048
    • Gyldighed: udløbet 2020-06-04
    • CA detaljer: crt.sh, udstedte certifikater
    • Certifikat detaljer (underskrevet af ISRG Root X1): crt.sh, der, pem, txt
    • Certifikat detaljer (krydsunderskrevet af IdenTrust): crt.sh, der, pem, txt
  • Let’s Encrypt Autoriteten X3
    • Om: O = Let's Encrypt, CN = Let's Encrypt Autoriteten X3
    • Nøgletype: RSA 2048
    • Gyldighed: udløbet 2021-10-06
    • CA detaljer: crt.sh, udstedte certifikater
    • Certifikat detaljer (underskrevet af ISRG Root X1): crt.sh, der, pem, txt
    • Certifikat detaljer (krydsunderskrevet af IdenTrust): crt.sh, der, pem, txt
  • Let’s Encrypt Autoriteten X4
    • Om: O = Let's Encrypt, CN = Let's Encrypt Autoriteten X4
    • Nøgletype: RSA 2048
    • Gyldighed: udløbet 2021-10-06
    • CA detaljer: crt.sh, udstedte certifikater
    • Certifikat detaljer (underskrevet af ISRG Root X1): crt.sh, der, pem, txt
    • Certifikat detaljer (krydsunderskrevet af IdenTrust): crt.sh, der, pem, txt
Delegerede OCSP-svar

Dette nøglepar blev tidligere brugt til at signere OCSP-svar vedrørende status for Let’s Encrypts underordende certifikater på vegne af Let’s Encrypt roden, så roden kan forblive sikker offline. Vi udsteder ikke længere OCSP-svar for vores underordnede certifikater; vi udsteder i stedet regelmæssigt CRL’er fra vores rod for at formidle tilbagekaldelsesstatus for vores underordnede certifikater.

  • ISRG Root OCSP X1
    • Emne: O = Internet Security Research Group, CN = ISRG Root OCSP X1
    • Nøgletype: RSA 2048
    • Gyldighed: indtil 2025-06-10
    • Certifikat detaljer (underskrevet af ISRG Root X1): crt.sh, der, pem, txt
    • Certifikat detaljer (underskrevet af ISRG Root X1): crt.sh (udløbet)

Certifikat kæder

Når en ACME-klient henter et nyligt udstedt certifikat fra Let’s Encrypt ACME-API, at certifikatet kommer som en del af en “certifikat kæde”, der også omfatter en eller flere underordnede CA’er. Som regel består denne kæde af kun den endelige enhed certifikat og et underordnet, men den kan indeholde yderligere mellemled. Tanken er, at ved at præsentere hele denne kæde af certifikater til en hjemmeside besøgende browser, browseren vil være i stand til at validere signaturerne hele vejen op til en rod, browseren stoler på uden at skulle downloade yderligere underordnede certifikater.

Nogle gange er der mere end en gyldig kæde for et givet certifikat: for eksempel, hvis et underordnet certifikat er blevet krydssigneret, så enten et af disse to certifikater kunne være den anden post, “kæde op til” en af to forskellige rod-certifikater. I dette tilfælde kan forskellige webstedsoperatører ønsker at vælge forskellige kæder, afhængigt af de egenskaber, de bekymrer sig mest om.

Abonnentcertifikater med offentlige RSA-nøgler udstedes fra vores RSA-underordnede CA, som kun er udstedt fra vores RSA-rod ISRG Root X1 (i. De er ikke krydsunderskrevet). Derfor har alle RSA-abonnentcertifikater kun en enkelt kæde til rådighed:

RSA Abonnementcert ← RSA underordnet (R10 eller R11) ← ISRG Root X1

Abonnentcertifikater med offentlige ECDSA-nøgler udstedes fra vores ECDSA-underordnede CA, som udstedes begge (i.. krydssigneres) fra vores RSA-rod ISRG Root X1 og vores ECDSA-rod ISRG Root X2. Derfor tilbyder vi to kæder til disse certifikater:

ECDSA Abonnementcert ← ECDSA Underordnet (E5 eller E6) ← ISRG Root X1

ECDSA Abonnementcert ← ECDSA Underordnet (E5 eller E6) ← ISRG Root X2

Den første kæde, op til ISRG Root X1, giver den største kompatibilitet, fordi dette rodcertifikat er inkluderet i de fleste certifikat samlinger. Den anden kæde, op til ISRG Root X2, bruger færre bytes af netværkets båndbredde i hver TLS-håndtryk. Vi leverer den første kæde som standard, for at sikre den bredeste kompatibilitet. Abonnenter, der ønsker at prioritere størrelse frem for kompatibilitet, kan henvise til deres ACME-klients dokumentation for instruktioner om, hvordan du beder om alternativ kæde (f. eks. certbot’s --preferred-chain flag).