En profil er en samling af karakteristika, der beskriver både den valideringsproces, der er nødvendig for at få et certifikat, og det endelige indhold af certifikatet. For langt de fleste af Let’ Encrypt abonnenter, bør du aldrig behøver at bekymre dig om dette: Vi vælger automatisk den bedste profil for dig, og sikre, at det opfylder alle de krav og bedste praksis, der gælder for webPKI. Men nogle mennesker kan være interesseret i proaktivt at vælge en bestemt profil, så denne side findes for at give de oplysninger, der er nødvendige for at foretage dette valg.
Nedenfor er beskrivelser af hver profil, herunder hvilke virkninger de har på både valideringsprocessen og indholdet af det udstedte certifikat. Bemærk, at ikke alle profiler er tilgængelige i alle miljøer: nogle kan kun være tilgængelige i Staging eller kun i Produktion, og nogle kan være (midlertidigt) låst bag en tilladt liste, så vi kan rulle dem ud langsomt. Listen over profiler annonceret i ACME Server’s directory endpoint er den kanoniske liste.
Du kan finde detaljerede definitioner af egenskaberne diskuteret i hver profil nederst på denne side.
Den klassiske profil er standardprofilen valgt for alle ordrer, som ikke anmoder om en bestemt profil. Valideringsprocessen og det resulterende certifikat er de samme som du er vant til fra de sidste mange år af Let’s Encrypt driften. Vi anbefaler at bruge denne profil til abonnenter, der gerne vil lade andre prøve nye ting først.
| Egenskaber | Værdi |
|---|---|
| Pending Authorization Lifetime | 7 dage |
| Authorization Reuse Period | 30 dage |
| Order Lifetime | 7 dage |
| Certificate Common Name | Ja* |
| Key Encipherment KU | Ja† |
| TLS Client Auth EKU | Ja |
| Subject Key ID | Ja |
| Validity Period | 90 dage |
*: Hvis CSR indsendt ved afslutningen af tiden anmoder om et specifikt fælles navn, er denne anmodning opfyldt. Hvis CSR ikke anmoder om et specifikt fælles navn, vil det første emnealternativ blive forfremmet til emnefællesnavnet. Hvis enten det ønskede navn eller det to-be-forfremmede navn er for langt til at passe i Common Name feltet (64+ tegn), vil fællesnavnet blive efterladt tomt.
†: Kun inkluderet for certifikater med RSA offentlige nøgler.
Tlsserveren profil er en ny profil, som opdaterer flere af disse validerings- og certifikategenskaber for at afspejle de seneste anbefalinger fra CA/Browser Forum Baseline Krav, samt generelle tendenser inden for WebPKI-fællesskabet. Vi anbefaler at vælge denne profil for abonnenter, der ønsker mindre certifikater, og som fuldt ud tager automatisering til sig.
Den afventende tilladelse levetid er blevet reduceret for yderligere at fremme automatisering: fuldt automatiserede systemer kan fuldføre en validering udfordring inden for sekunder, så en levetid på blot en time er mere end nok. Perioden for genanvendelse af tilladelser er blevet reduceret til syv timer. Dette skyldes, at Baseline Krav kræver, at vi genkontrollerer Certifikat Authority Authorization (CAA) efter otte timer, så begrænsning af genbrugsperioden betyder, at vi ikke behøver at udføre rechecks. Ordrens levetid er blevet reduceret til summen af to autorisationens levetid, fordi der ikke er noget formål med at have en ordre, der overlever godkendelserne, afhænger af det.
Det udstedte certifikat indeholder ikke længere nogen af de felter, der er nævnt ovenfor. Det fælles navn er blevet udeladt, da det er overflødigt med emnets alternative navne og er markeret som IKKE ANBEFALET ved baseline-kravene. Nøgle krypteringsnøgle anvendelsen udelades fordi det kun er relevant ved brug af ikke-fremadrettede hemmelige TLS-chiffersuiter, som er blevet fjernet af alle større browsere på grund af betydningen af fremadrettet. Den udvidede TLS-klient Auth nøgleanvendelse udelades for at overholde kommende krav til rodprogrammer, der kræver “single-purpose “(dvs. single EKU) certifikater. Og udvidelsen af Suybject Key ID er udeladt, fordi det ikke tjener noget formål i end-entity certifikater og er IKKE ANBEFALET af Baseline Krav.
| Egenskaber | Værdi |
|---|---|
| Pending Authorization Lifetime | 1 time |
| Authorization Reuse Period | 7 timer |
| Order Lifetime | 8 timer |
| Certificate Common Name | Nej |
| Key Encipherment KU | Nej |
| TLS Client Auth EKU | Nej |
| Subject Key ID | Nej |
| Validity Period | 90 dage |
Den kortlivede profil er identisk med tlsserver profil, med en hoved forskel, det resulterende certifikat er kun gyldigt i 6 dage. Dette gør det muligt for disse certifikater at kvalificere sig som “Kortlevende Abonnementscertifikater” i henhold til basiskravene, hvilket betyder, at de ikke behøver at indeholde tilbagekaldelsesoplysninger. Det betyder, at certifikaterne kan være endnu mindre, og fjerner enhver mulighed for, at en klient ved et uheld stoler på et certifikat, efter at det er blevet tilbagekaldt.
Vi anbefaler denne profil for dem, der fuldt ud stoler på deres automatisering til at forny deres certifikater til tiden. Denne profil er ikke for alle. Fordi denne profil resulterer i meget højere udstedelsesvolumen (da certifikater skal fornyes hvert par dage, i stedet for hvert par måneder), er det i øjeblikket låst bag en tilladelse.
| Egenskaber | Værdi |
|---|---|
| Pending Authorization Lifetime | 1 time |
| Authorization Reuse Period | 7 timer |
| Order Lifetime | 8 timer |
| Certificate Common Name | Nej |
| Key Encipherment KU | Nej |
| TLS Client Auth EKU | Nej |
| Subject Key ID | Nej |
| Validity Period | 160 timer |
Processen for at vælge en profil er beskrevet i denne Internet-Draft, som vi planlægger at arbejde sammen med IETF ACME-arbejdsgruppen om at gøre til en fuld RFC. Ikke alle ACME-klienter har implementeret dette udkast, så den klient, du bruger, kan måske endnu ikke vælge en profil.
Generelt, hvis du vil vælge en profil, bør du:
Nedenfor er beskrivelser af de valideringsegenskaber, der kan styres af vores profiler.
Dette er hvor længe en ACME-klient har til at fuldføre en valideringsudfordring for domænekontrol. Uret starter, når ACME Authorization objektet er oprettet (generelt som følge af, at en ny ordre bliver oprettet), og er repræsenteret ved expires tidsstempel i det afventende Authorization objekt. Denne værdi er begrænset til højst 30 dage af baseline-kravene.
Dette er hvor længe en allerede valideret godkendelse kan genbruges af nye ordrer, der indeholder samme identifikator. Uret starter, når en udfordring med succes er opfyldt, og er repræsenteret ved expires timestamp i det gyldige godkendelsesobjekt. Denne værdi er begrænset til højst 398 dage af baseline-kravene.
Det er hvor længe, en ACME-klient har til at gennemføre hele processen med at bestille et nyt certifikat: at placere en ny ordre, opfylder alle udestående godkendelser, og færdiggør denne ordre. Uret starter, når en ny ordre er oprettet, og er repræsenteret ved expires timestamp i det ordre objektet.
Nedenfor er beskrivelser af certifikatets egenskaber, der kan styres af vores profiler.
TLS-certifikater kan indeholde navne (f.eks. domænenavne eller IP-adresser) to steder: feltet Emne Fællesnavn og forlængelsen Emne Alternative Navne. Fællesnavnet bruges til at være det mest almindelige sted at sætte et domænenavn, og vises med mange certifikat-læsnings værktøjer. Bemærk at Common Name kan kun indeholde et navn, mens mange certifikater ønsker at indeholde flere navne (såsom example.com, www.example.com, og blog.example.com). I dag er fællesnavnet stort set overflødigt som det navn er indeholdt i det er nødvendigt at også være indeholdt i Emne Alternative Navne udvidelsen. At inkludere dette felt i vores certifikater er nu IKKE ANBEFALET af baseline krav.
TLS-certifikater har en “Nøgleanvendelse”-udvidelse, som bestemmer, hvilke typer af kryptografiske operationer nøglen i certifikatet har lov til at udføre. Alle Let’s Encrypt certifikater indeholder Digital Signature KU, som er nødvendig for at udføre TLS-håndtryk. Nøgle Encipherment KU var historisk krævet af gamle versioner af TLS til at udføre visse former for håndtryk med RSA-nøgler. Bemærk disse operationer er nu kendt for at være usikre, og er blevet forældet og fjernet fra browsere i flere år nu. At inkludere dette felt i vores certifikater er nu IKKE ANBEFALET af baseline krav.
Ud over ovenstående har TLS-certifikater også en “Udvidet nøglebrug”-udvidelse, som giver et ekstra lag af opløsning til Key Usage forlængelse beskrevet ovenfor. De to mest almindelige udvidede nøgleanvendelser er TLS Server Auth (som tillader certifikatet at blive præsenteret af en server under en TLS-håndtrykke) og TLS-klient Auth (som tillader certifikatet at blive præsenteret af en client under en TLS-håndtrykke). Sidstnævnte er meget sjældent, og rodprogrammer er flytter til kræver, at TLS Client Auth EKU udelades fra certifikater.
TLS certifikater kan have en [“Emne Key Identifier” udvidelse] (https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.2), som giver en kort streng, der entydigt identificerer den offentlige nøgle til stede i certifikatet. Denne udvidelse er meget vigtig for CA-certifikater fordi det giver browsere mulighed for hurtigt at finde det CA-certifikat, der udstedte det endelige enhedscertifikat, der præsenteres af et websted. Udvidelsen tjener imidlertid ikke noget formål i de endelige enhedscertifikater, og inklusive den er nu IKKE ANBEFALET ved Baseline kravene.
Dette regulerer mængden af tid mellem notBefore og notAfter tidsstempler der er indlejret i et TLS-certifikat med andre ord, hvor længe certifikatet vil være betroet før det udløber. Denne værdi er begrænset til højst 398 dage af baseline-kravene.