ACME 2.0-pro­to­col voor au­to­ma­ti­sche cer­ti­fi­ca­ten

ACME 2.0-pro­to­col voor au­to­ma­ti­sche SSL/TLS-cer­ti­fi­ca­ten

C’t Magazine - - Inhoud - Pi­na Mer­kert

Met Let's En­crypt kun je vol­au­to­ma­tisch gra­tis SSL/TLS-cer­ti­fi­ca­ten krij­gen om het da­ta­ver­keer van je web­si­tes via in­ter­net te ver­sleu­te­len. Het on­der­lig­gen­de pro­to­col is als ACME 2.0 op weg om een in­ter­net­stan­daard te wor­den, zo­dat het in de toe­komst ook op an­de­re plek­ken voor cer­ti­fi­ca­ten ge­bruikt kan wor­den.

Let's En­crypt dankt zijn suc­ces on­der meer aan ACME, het Au­to­ma­tic Cer­ti­fi­ca­te Ma­na­ge­ment En­vi­ro­ment. Dat pro­to­col au­to­ma­ti­seert het be­stel­len van gra­tis TLS-cer­ti­fi­ca­ten bij de Cer­ti­fi­ca­te Aut­ho­ri­ty (CA) en re­gelt ook de check dat de be­stel­ler daad­wer­ke­lijk de vol­le­di­ge con­tro­le heeft over het in het cer­ti­fi­caat aan­ge­ge­ven do­mein. ACME 1.0 was ge­heel toe­ge­spitst op de wen­sen van Let's En­crypt. Een uni­for­me stan­daard om cer­ti­fi­ca­ten au­to­ma­tisch aan te vra­gen en in te trek­ken, is ech­ter niet al­leen han­dig voor Let's En­crypt maar voor el­ke CA. ACME is de af­ge­lo­pen ja­ren door de In­ter­net En­gi­nee­ring Task For­ce (IETF) dan ook door­ont­wik­keld als stan­daard­con­cept. We zijn al aan­be­land bij con­cept­ver­sie 9, die als ACME 2.0 een goe­de kans heeft om de de­fi­ni­tie­ve stan­daard te wor­den.

Let's En­crypt on­der­steunt als het goed is van­af eind fe­bru­a­ri op zijn cer­ti­fi­caat­ser­ver 'Boul­der' ACME 2.0. Van­af dat mo­ment staat het ook cer­ti­fi­ca­ten toe die wild­cards be­vat­ten in de vorm van *.example.com. Daar­mee kun­nen be­heer­ders voor al­le sub­do­mei­nen van een do­mein het­zelf­de cer­ti­fi­caat ge­brui­ken zon­der elk sub­do­mein apart in een 'Sub­ject Al­ter­na­ti­ve Na­me'-veld te hoe­ven aan­ge­ven. Der­ge­lij­ke uni­ver­se­le cer­ti­fi­ca­ten kun­nen TLS-set-ups dui­de­lijk ver­een­vou­di- gen, ze­ker als je voor pu­blic-key-pin­ning gaat en daar­om niet in hoog tem­po van cer­ti­fi­ca­ten wilt wis­se­len.

ACME 2.0 is nog niet com­pa­ti­bel met eer­de­re ver­sies en wordt op dit mo­ment nog maar door drie ACME-clients on­der­steund: ac­me4j (Ja­va), gets­sl (shell) en acme.sh (shell, zie pa­gi­na 110). De of­fi­ci­ë­le Let's-En­crypt-client Cert­bot (Py­thon) on­der­steunt ACME 2.0 nog niet. Om­dat met ACME 2.0 ech­ter al­les kan wat voor­heen ook mo­ge­lijk was, is te ver­wach­ten dat de ac­tief door­ont­wik­kel­de clients vroe­ger of la­ter naar de nieu­we ver­sie over­gaan. Daar hoe­ven ze geen haast mee te ma­ken om­dat Let's En­crypt nog geen ter­mijn heeft ge­noemd van­af wan­neer het ou­de pro­to­col wordt uit­ge­fa­seerd. Als je dus een wer­ken­de Let's-En­crypt-set-up hebt en niet per se wild­card-cer­ti­fi­ca­ten hoeft te ge­brui­ken, hoef je voor­lo­pig niets te ver­an­de­ren.

Wild­cards al­leen met DNS-va­li­de­ring

ACME kan op drie ver­schil­len­de ma­nie­ren chec­ken of een be­stel­ler ook de con­tro­le heeft over een do­mein waar­voor hij een cer­ti­fi­caat aan­vraagt. Al­le drie ge­brui­ken ze een random to­ken in het Ba­se64-URLal­fa­bet met min­stens 128-bit en­tro­pie en de open­ba­re sleu­tel die ACME-clients au­to­ma­tisch aan­ma­ken om zich voort­aan bij de ser­ver te iden­ti­fi­ce­ren. Bij de een­vou­dig­ste va­li­de­ring via HTTP stuurt de Let's-En­crypt-ser­ver een re­quest naar een web­ser­ver voor een be­stand met een cryp­ti­sche naam (de be­stands­naam komt over­een met het to­ken) in de map ./wel­l­known/acme-chal­len­ge/. Die be­vat de vol­gen­de te­kens: het to­ken, een punt en een hash van de open­ba­re sleu­tel van het ac­count. Daar­aan ziet de Let's-En­crypt­ser­ver dat de aan­vra­ger via dit do­mein wil­le­keu­ri­ge be­stan­den be­schik­baar kan stel­len.

De TLS-SNI-chal­len­ge werkt ver­ge­lijk­baar, maar ge­bruikt een TLS-ser­ver in plaats van een web­ser­ver. Die geeft een tij­de­lijk cer­ti­fi­caat uit met twee sub­jec­tAl­ter­na­ti­veNa­mes: SAN A en SAN B. SAN A be­staat uit een SHA-256-hash van het to­ken in hexa­de­ci­ma­le weer­ga­ve met een punt na de helft van de cij­fers, ge­volgd door .to­ken. acme.in­va­lid. SAN B be­vat met het­zelf­de for­maat de hexa­de­ci­ma­le hash van de open­ba­re sleu­tel, ge­volgd door .ka.acme. in­va­lid. Om­dat er hier geen re­quest komt van­af het in het cer­ti­fi­caat ge­noem­de sub­do­mein, kan dat pro­ble­men op­le­ve­ren als meer­de­re ge­brui­kers ach­ter de­zelf­de TLS­ser­ver cer­ti­fi­ca­ten be­he­ren. Daar­om heeft Let's En­crypt de­ze va­li­de­rings­me­tho­de uit be­vei­li­gings­over­we­gin­gen uit­ge­scha­keld (zie de link on­der­aan dit ar­ti­kel).

De der­de me­tho­de vraagt via DNS naar een TXT-re­cord voor het sub­do­mein _ac­me­chal­len­ge van het in het cer­ti­fi­caat aan­ge­ge­ven do­mein. Dus _ac­me­chal­len­ge.ctis­gre­at.example.com bij een cer­ti­fi­caat voor *.ctis­gre­at.example.com. Als het TXT-re­cord de SHA-256-hash be­vat van de com­bi­na­tie van to­ken, punt en sleu­tel, is con­tro­le over het do­mein on­om­sto­te­lijk aan­ge­toond.

Voor wild­card-cer­ti­fi­ca­ten wordt door Let's En­crypt al­leen de DNS-va­li­de­ring toe­ge­staan. Als je geen * in je cer­ti­fi­ca­ten ge­bruikt, kun je ook bij ACME 2.0 al­le drie de va­li­da­tie­me­tho­den ge­brui­ken.

Bij de DNS-va­li­de­ring kan de ACME­client al­leen au­to­ma­tisch een TXT-re­cord aan­ma­ken bij de na­me­ser­ver als die op de­zelf­de com­pu­ter draait of als de hos­ter daar­voor een API aan­biedt. Dat is he­laas maar bij een paar hos­ters het ge­val, zo­dat je als be­heer­der meest­al het TXT-re­cord hand­ma­tig via een we­bin­ter­fa­ce moet in­voe­ren. Om­dat Let's-En­crypt-cer­ti­fi­ca­ten al na maxi­maal drie maan­den ver­lo­pen en Let's En­crypt bij el­ke aan­vraag of ver­len­ging een va­li­de­ring ver­eist, kan dat veel werk op­le­ve­ren.

Uni­ver­se­ler

Voor de on­der­steu­ning van wild­cards zou ei­gen­lijk geen nieu­we ACME-ver­sie no­dig zijn ge­weest. Ook in de ou­de ver­sie zou je pro­bleem­loos wild­cards in de Cer­ti­fi­ca­te Sig­ning Re­quests (CSR's) kun­nen in­te­gre­ren. Bij ACME 2.0 gaat het er dan ook veel meer om het pro­to­col on­af­han­ke­lijk te ma­ken van de spe­ci­a­le wen­sen van Let's En­crypt. De nieu­we stan­daard ge­bruikt daar­om ook geen hard ge­co­deer­de url's, maar laat het aan de CA over hoe de eind­pun­ten voor de re­quests he­ten.

Net als de eer­de­re ver­sies ge­bruikt ACME 2.0 ge­brui­kers­ac­counts be­staan­de uit RSA- of ECDSA-sleu­tel­pa­ren. Bij het aan­ma­ken van de ac­counts ver­stuurt de client zijn open­ba­re sleu­tel vol­gens de RFC-stan­daard 'JSON Web Key' (zie de link on­der­aan dit ar­ti­kel) naar de ser­ver. De client on­der­te­kent zijn be­rich­ten met de bij­be­ho­ren­de pri­vé­sleu­tel als 'JSON Web Sig­na­tu­re'. De ser­ver kan daar­door on­af­han­ke­lijk van de TLS-ver­bin­ding con­tro­le­ren dat re­quests bij het­zelf­de ge­brui­kers­ac­count ho­ren. Dat maakt het mak­ke­lij­ker CA's op te zet­ten die TLS en het ma­ken van cer­ti­fi­ca­ten ver­de­len over meer­de­re ma­chi­nes. Om­dat op dit mo­ment nog geen en­ke­le CA naast Let's En­crypt ACME aan­biedt, ver­an­dert er door de nieu­we stan­daard niets voor de mees­te be­heer­ders. Als je van Let's En­crypt cer­ti­fi­ca­ten wilt heb­ben met wild­cards, moet je een van de wei­ni­ge ACME-clients ge­brui­ken die de nieu­we pro­to­col­ver­sie al on­der­steu­nen. Hoe meer clients ACME 2.0 im­ple­men­te­ren, des te aan­trek­ke­lij­ker het ook voor an­de­re CA's wordt om ACME aan te bie­den. (nkr)

ww.ct.nl/soft­link/1804118

Let's En­crypt geeft al­leen wild­card-cer­ti­fi­ca­ten uit als de CA het do­mein via DNS

kan va­li­de­ren.

Newspapers in Dutch

Newspapers from Netherlands

© PressReader. All rights reserved.