Let's En­crypt-mo­du­le in Apa­che

Let's-En­crypt-mo­du­le bij Apa­che

C’t Magazine - - Inhoud - Ste­fan Eis­sing

Een vol­gen­de re­lea­se van de Apa­che-web­ser­ver krijgt een mo­du­le die zon­der hulp van bui­ten­af voor SSL/TLS-cer­ti­fi­ca­ten kan zor­gen en de­ze kan ver­nieu­wen. Daar hoef je niet veel voor te con­fi­gu­re­ren.

Van­af re­lea­se 2.5.0 moet de mo­du­le ‘mod_md' toe­ge­voegd zijn, die het au­to­ma­tisch ver­krij­gen van cer­ti­fi­ca­ten voor Apa­che-web­si­tes een stuk mak­ke­lij­ker maakt. Dan ver­dwij­nen de be­per­kin­gen van de tot nu toe gang­ba­re tools zo­als de ‘Cert­bot' van de EFF (Elec­tro­nic Fron­tier Foun­da­ti­on). Die heb­ben geen toe­gang tot de web­ser­ver-pro­ces­sen. Daar­om le­zen ze de con­fi­gu­ra­tie van een Apa­che-ser­ver, pro­be­ren die te be­grij­pen en op de juis­te ma­nier te her­schrij­ven – een niet-tri­vi­a­le ac­tie om­dat die con­fi­gu­ra­ties aar­dig com­plex kun­nen zijn.

Het kan nog een tijd­je du­ren voor­dat de gang­ba­re dis­tri­bu­ties een Apa­che-web­ser­ver met de mo­du­le mod_md aan­bie­den. Het vol­staat he­laas niet om die mo­du­le aan een be­staan­de Apa­che-in­stal­la­tie toe te voe­gen. Om er­voor te zor­gen dat hij zijn werk kan doen moet ook de mo­du­le ‘mod_s­sl' aan­ge­past wor­den, die voor de SSL/TLS-ver­bin­din­gen ver­ant­woor­de­lijk is. Als je niet wilt wach­ten, is er een Ubunt­uPPA met een al aan­ge­past Apa­che-pak­ket, waar­voor je al­leen mod_md op de juis­te ma­nier hoeft te com­pi­le­ren. De be­no­dig­de stap­pen daar­voor staan in de mod_md-wi­ki op GitHub (zie de link on­der aan dit ar­ti­kel).

Wat is nieuw?

Een voor­beeld­con­fi­gu­ra­tie laat zien hoe mod_md werkt. Een HTT­PS-web­si­te in Apa­che ziet er sterk ver­een­vou­digd zo uit:

<Vir­tu­alHost *:443>

Ser­verNa­me example.com

SSLEn­gi­ne on

SSLCer­ti­fi­ca­teFi­le /etc/my­certs ... SSLCer­ti­fi­ca­teKeyFi­le /etc/ ...

...

</Vir­tu­alHost>

De be­stan­den waar de SSLCer­ti­fi­ca­te-op­ties naar ver­wij­zen, moest je als ser­ver­be­heer­der tot nu toe zelf bij een cer­ti­fi­ce­rings­in­stan­tie aan­dra­gen. Met mod_md doe je daar­en­te­gen:

MDo­main example.com <Vir­tu­alHost *:443> Ser­verNa­me example.com SSLEn­gi­ne on

...

</Vir­tu­alHost>

en dan neemt Apa­che zelf con­tact op met de Let's-En­crypt-ser­ver, vraagt om een cer­ti­fi­caat voor example.com en geeft ant­woord op de vra­gen die moe­ten ga­ran­de­ren dat je ser­ver het do­mein ook echt mag be­he­ren. Daar­na wordt het cer­ti­fi­caat ge­down­load en na een re­load van de ser­ver heb je dan een web­si­te die door brow­sers met een groen slot­je weer­ge­ge­ven wordt.

Als de si­te on­der een an­de­re naam be­reik­baar moet zijn, vol­staat het het vol­gen­de toe te voe­gen:

MDo­main example.com

<Vir­tu­alHost *:443>

Ser­verNa­me example.com Ser­verA­li­as www.example.com SSLEn­gi­ne on

...

</Vir­tu­alHost>

Dan her­kent mod_md dat het cer­ti­fi­caat niet meer al­le be­no­dig­de na­men af­dekt en wordt een nieuw aan­ge­vraagd.

Voor meer­de­re van der­ge­lij­ke si­tes kun je nog meer MDo­main-re­gels toe­voe­gen

of een do­mein uit­brei­den naar meer­de­re web­si­tes door de naam aan een be­staan­de MDo­main-re­gel te han­gen:

MDo­main example.com example.net <Vir­tu­alHost *:443>

Ser­verNa­me example.com

...

</Vir­tu­alHost>

<Vir­tu­alHost *:443> Ser­verNa­me example.net ...

</Vir­tu­alHost>

Op die ma­nier ge­ne­reert de mo­du­le een en­kel cer­ti­fi­caat dat voor bei­de geldt. Het voor­deel is dat brow­sers bij HTTP/2-ser­vers dan de­zelf­de ver­bin­ding ge­brui­ken. Een voor­deel van af­zon­der­lij­ke MDo­main-re­gels is dat de cer­ti­fi­ca­ten niet on­no­dig groot wor­den, want de ser­ver stuurt die bij el­ke ver­bin­dings­op­bouw naar de client.

Op­start­pro­ble­men?

Apa­che is een zeer krach­ti­ge ser­ver. Het aan­tal ver­schil­len­de con­fi­gu­ra­tie- en ge­bruiks­mo­ge­lijk­he­den is groot. Het kan dus ze­ker ge­beu­ren dat er iets over het hoofd ge­zien wordt. De mo­du­le is nog nieuw, maar er is al wel het no­di­ge be­kend over wat er aan moet ge­beu­ren om het aan de praat te krij­gen.

Om te be­gin­nen: om Let's En­crypt te ge­brui­ken, moet je het eens zijn met de ‘Terms of Ser­vi­ce'. Dat doe je door in de con­fi­gu­ra­tie de vol­gen­de re­gel te zet­ten:

MDCer­ti­fi­ca­teA­gree­ment htt­ps:// .let­sen­crypt.org/do­cu­ments/LE-SA- .v1.2-No­vem­ber-15-2017.pdf

Zon­der dat werkt het niet. De exac­te url kan wel­licht nog wij­zi­gen, maar die hoeft al­leen bij de eer­ste aan­mel­ding te klop­pen. Als Let's En­crypt de agree­ment niet goed­keurt of als die ont­breekt, komt er een over­een­kom­sti­ge ERROR in de ser­ver­log te staan. Bo­ven­dien moet de op­tie Ser­verAd­min naar een gel­dig e-mail­adres ver­wij­zen waar Let's En­crypt de sta­tus­be­rich­ten naar­toe kan stu­ren.

De Apa­che-ser­ver kan pas be­gin­nen met het aan­vra­gen van cer­ti­fi­ca­ten als hij ge­start is. Ma­na­ged-do­mains die nog geen ‘goed' cer­ti­fi­caat heb­ben, ge­brui­ken daar­om eerst een dum­my-cer­ti­fi­caat. Veel ser­vers be­die­nen een veel­voud aan ma­na­ged-do­mains en de wen­sen van één do­mein mo­gen de toe­gang tot al­le an­de­re niet blok­ke­ren. Een door Let's En­crypt ge­va­li­deer­de goed­keu­ring die met­een zicht­baar is na de eer­ste keer star­ten van de ser­ver is wat te­veel ge­vraagd.

Om er­voor te zor­gen dat een ser­ver de nieuw op­ge­haal­de cer­ti­fi­ca­ten ook uit­le­vert, heeft hij een ‘gra­ce­full restart' no­dig – ook wel een ‘re­load' ge­noemd. Een in­di­ca­tie dat dit no­dig is, staat als NOTICE in de ser­ver­log. Heeft een ad­min dan ook een nieuw do­mein als ‘ma­na­ged' ge­con­fi­gu­reerd, dan kan hij in de log le­zen wan­neer een re­load zin­vol is. Meest­al duurt dat een paar se­con­den.

Tot het zo­ver is, la­ten nieu­we do­mei­nen al­leen een zelf-on­der­te­kend cer­ti­fi­caat zien dat brow­sers niet ver­trou­wen. Ont­van­gen re­quests wor­den door de ser­ver al­leen met de sta­tus 503 be­ant­woord, of­te­wel ser­vi­ce niet be­schik­baar.

De mo­du­le be­kom­mert zich al we­ken voor de ver­loop­da­tum om het ver­nieu­wen van de be­staan­de cer­ti­fi­ca­ten. Het pre­cie­ze tijd­stip van het ac­ti­ve­ren van de nieu­we cer­ti­fi­ca­ten is dan ook min­der kri­tisch. Het is aan te ra­den een­maal per week een re­load uit te voe­ren, bij­voor­beeld met een cron-job. Een re­load heeft geen ge­vol­gen voor lo­pen­de re­quests. De af­zon­der­lij­ke Apa­che-pro­ces­sen star­ten pas op­nieuw op als ze al­le ver­bin­din­gen net­jes af­ge­slo­ten heb­ben.

Als het niet soe­pel loopt

Al­le ac­ti­vi­tei­ten van mod_md ko­men in de ser­ver­log te staan. Op le­vel IN­FO staan daar mel­din­gen over nor­ma­le din­gen. Be­lang­rij­ke­re mel­din­gen ko­men te staan als NOTICE en bij fou­ten als WARNING of ERROR.

De mo­du­le con­tro­leert twee­maal per dag of al­le cer­ti­fi­ca­ten nog lang ge­noeg gel­dig zijn. Cer­ti­fi­ca­ten van Let's En­cryt heb­ben een gel­dig­heids­duur van 90 da­gen. Na twee der­de van die ter­mijn pro­beert de mo­du­le een nieu­we aan te vra­gen, dus 30 da­gen voor de ver­loop­da­tum. Bij een fout wordt een paar se­con­den la­ter een twee­de po­ging ge­daan. Als het fout blijft gaan, maakt de mo­du­le de tus­sen­tijd lan­ger, tot aan en­ke­le uren. Als het wel lukt, wordt dat weer ver­kort.

Se­cu­ri­ty

De Apa­che-dae­mon draait bij de gang­ba­re in­stal­la­ties on­der Unix-ach­ti­ge be­stu­rings­sys­te­men on­der een ge­brui­ker met be­perk­te rech­ten (vaak www-da­ta). Al­le Apa­che-pro­ces­sen die re­quests van bui­ten­af ver­wer­ken, ge­brui­ken dat ac­count. Daar­mee heb je nor­maal ge­spro­ken geen schrijf­rech­ten voor het be­stands­sys­teem, zo­dat een kwaad­wil­lend Apa­che-pro­ces zich niet op de har­de schijf kan nes­te­len.

De ser­ver kan een der­ge­lijk pro­ces niet stop­pen of her­star­ten – daar heeft hij de rech­ten niet voor. Het­zelf­de geldt voor mod_md, dat al­tijd in een van die pro­ces­sen zijn werk doet. El­ke com­mu­ni­ca­tie met de ser­vers van Let's En­crypt vindt ook daar plaats. Dat ver­klaart de nood­zaak van een re­load door de ad­min of via een cron-job.

Nieu­we cer­ti­fi­ca­ten, die bij een re­load ge­ac­ti­veerd wor­den, krij­gen au­to­ma­tisch toe­gangs­rech­ten die al­leen de root­ge­brui­ker (of wie de ser­ver start) toe­staan ze te le­zen en schrij­ven. Pri­vé­sleu­tels, die de mo­du­le bij het aan­vra­gen aan­maakt en in het be­stands­sys­teem neer­zet, wor­den door een wil­le­keu­rig ge­ko­zen wacht­woord af­ge­schermd.

In het be­stands­sys­teem staan al de­ze be­stan­den in de di­rec­to­ry md. Stan­daard be­vindt die zich in de Ser­verRoot van de Apa­che-ser­ver. MDSto­reDir kan hem ver­an­de­ren. Be­schrij­vin­gen van de lay-out en de op­ge­sla­gen be­stan­den staan voor ge­ïn­te­res­seer­den in de GitHub-wi­ki van mod_md en in de Apa­che-do­cu­men­ta­tie (zie de link hier­on­der).

TLS-SNI-pro­to­col

Op dit mo­ment ge­bruikt de mo­du­le poort 80 voor het aan­vra­gen en ver­nieu­wen van cer­ti­fi­ca­ten. Het is licht iro­nisch dat voor een vei­li­ge HTT­PS-ver­bin­ding op dit mo­ment eerst nog HTTP no­dig is. Ei­gen­lijk is ook een me­tho­de ge­de­fi­ni­eerd, na­me­lijk TLS-SNI-01, die poort 443 ge­bruikt – die de ser­ver voor HTT­PS so­wie­so al no­dig heeft.

He­laas kwam Let's En­crypt er be­gin 2018 ach­ter dat bij be­paal­de set-ups bij gro­te hos­ters ie­mand de me­tho­de via poort 443 ge­brui­ken kan om een cer­ti­fi­caat voor een do­mein van een an­de­re ge­brui­ker te krij­gen. TLS-SNI-01 werd daar­op met­een uit­ge­zet. Er werd ter plek­ke mel­ding ge­maakt van die mo­ge­lijk­heid.

Er wordt op dit mo­ment over ge­dis­cus­si­eerd hoe en on­der wel­ke om­stan­dig­he­den TLS-SNI-01 weer ge­ac­ti­veerd kan wor­den en of er een nieu­we me­tho­de ont­wik­keld moet wor­den. Voor ge­brui­kers van mod_md is dat ver­der niet van be­lang. Apa­che en Let's En­crypt on­der­han­de­len bij el­ke aan­vraag over de te ge­brui­ken me­tho­de. Als Let's En­crypt TLSSNI-01 weer vrij­geeft, zal Apa­che dat ook ge­brui­ken. (nkr)

Newspapers in Dutch

Newspapers from Netherlands

© PressReader. All rights reserved.