Let’s Encrypt – Gratis ssl certifikater

Min arbejdsgiver har i årevis postet penge ud på certifikater. Det er løbet op i et pænt beløb gennem tiden. Så da jeg blev opmærksom på Let’s Encrypt, var jeg til at starte med lidt skeptisk. Hvem er de? Og hvofor gratis… hvad er ulempen? For der må nødvendigvis være ulemper forbundet med noget der er gratis, ikke? Stol på ingen, stil spørgsmål ved alt. Der er også begrænsninger, men projektet er seriøst nok.

Hvem/hvad er Let’s Encrypt?

“Let’s Encrypt” er et projekt i regi af Internet Security Research Group (ISRG),  som blev grundlagt i 2013 med det formål at fremme offentligt tilgængelige projekter inden for digital infrastruktur. Gruppen blev fra starten sponsoreret af  Mozilla, Electronic Frontier Foundation, University of Michigan, Cisco og Akamai.

Det første projekt blev Let’s Encrypt certificate authority som er en CA (certificate authority) der udsteder certifikater helt gratis og med mulighed for at automatisere processen gennem klienten “Certbot”. Dette naturligvis med henblik på at højne sikkerheden og give alle mulighed for at kryptere deres internet services på en nem måde.

Hvad er begrænsningen?

Let’s Encrypt udsteder kun DV certifikater:

  • DV = Domain Validation. Et certifikat hvor domænet er valideret, dvs. at den der har fået certifikatet udstedt, har bevist sin kontrol over domænet
  • OV = Organisation Validation. Certifikatets indehaver har udover kontrol over domænet også bevist virksomhedens identitet
  • EV = Extended Validation. Udover DV og OV skal virksomheden bevise sin legale, fysiske og operationelle eksistens og sin eksklusive ret til domænet

Let’s Encrypt certifikater er gyldige i 3 måneder

  • Købte certifikater kan være gyldige i helt op til 3 år, hvorimod et Let’s Encrypt certifikat kun er gyldigt i 3 måneder. Denne begrænsning behøver dog ikke have nogen praktisk betydning, da certbot klienten hele tiden holder øje med certifikater der er ved at udløbe og automatisk fornyer dem.Let’s Encrypt skriver selv følgende om denne tidsbegræsning:
    • They limit damage from key compromise and mis-issuance. Stolen keys and mis-issued certificates are valid for a shorter period of time.
    • They encourage automation, which is absolutely essential for ease-of-use. If we’re going to move the entire Web to HTTPS, we can’t continue to expect system administrators to manually handle renewals. Once issuance and renewal are automated, shorter lifetimes won’t be any less convenient than longer ones.

Er et DV certifikat godt nok?

Det der er vigtigt er, at ingen kan se eller sniffe data der udveksles mellem en service og en klient. Hvis du benytter en hjemmeside uden kryptering (http) mens du er forbundet til en Wi-Fi f.eks. på en Cafe, kan andre på Cafeen følge med i og læse alle de data der sendes frem og tilbage mellem din enhed og hjemmesiden. Hvis hjemmesiden er sikret med SSL (https) er data krypteret og folk kan stadig se der flyver data frem og tilbage, men kan ikke læse det.

Uanset om du har et DV, OV eller EV certifikat, er data krypteret. Så hvad det angår er et DV certificat ganske udmærket. Hvorvidt certifikat-udstederen har valideret din organisation og kender din identitet, har intet at gøre med det vigtige: Krypteringen. Er det vigtigt for dine kunder at CA’en har tjekket at din identitet og den lovlige registrering af dit firma? Næppe. Ingen almindelige mennesker tjekker den slags. Deres tillid til en hjemmeside baserer sig på helt andre metoder.  De har måske fået en hjemmeside anbefalet eller har tjekket TrustPilot, eller har måske kommunikeret med med dig pr mail eller telefon inden købet. Langt de fleste gør absolut ingenting. Så nej, et OV eller EV certifikat er sjældent vigtigt for en helt almindelig online butik. Måske for en bank eller offentlig myndighed der ligger inde med mange følsomme data.

Men hvad med den grønne bar?

Der var en overgang meget hype om “den grønne bar” med firmanavn, som mange browsere viste på sider med EV certifikat. Det bevæger man sig væk fra nu. Google har f.eks. besluttet at deres Chrome browsere i fremtiden kun skal indikere hvis en side IKKE er sikker. Og hvis forskellen på de forskellige certifikater således udviskes, er der absolut intet der taler for at bruge penge på dem… medmindre man henvender sig til et publikum der rent faktisk tjekker den slags. Det gør 99,99% af befolkningen ikke.

Let’s Encrypt på Ubuntu 18

Installer Certbot

Først skal certbot klienten installeres:

Vælg mellem DNS eller HTTP challenge

For at kunne modtaget et certifikat, skal du bevise at du har kontrol over domænet. Det kan enten ske via DNS ved at tilføje en TXT record, eller ved at lade certbot placere en fil som Let’s Encrypt kan nå via det domæne der ønskes certifikat til.

Hvis du vælger DNS skal du have mulighed for at automatisere tilføjelsen af en TXT record, da du ellers skal ændre den manuelt hver 3 måned når et certifikat skal fornyes. Det er der ikke mange der har mulighed for. Jeg valgte da også en HTTP challenge. Her sørger certbot nemlig for at placere en fil og fjerne den igen, når certifikatet er udstedt. Og ja, du kan sagtens nøjes med en enkelt mappe dedikeret til formålet. Du behøver ikke en challenge mappe under hver enkelt domæne.

Den åbenlyse fordel ved brug af DNS metoden, er at den giver mulighed for wildcart certifikater.

Konfiguration af webserver

Når du genererer et certifikat med certbot vha en HTTP challenge, placerer certbot en fil i en angivet mappe, og den skal Let’s Encrypt serveren kunne tilgå via det domæne du ønsker certifikat til.

Lad os antage jeg har domænet eksempel.dk og jeg gerne vil udstede et certifikat til test.eksempel.dk. Let’s Encrypt vil nu tilgå challenge filen via test.eksempel.dk på port 80. Det betyder ikke noget om du har en SSL redirect eller andet halløj konfigureret. Det er Let’s Encrypt ligeglad med. Jeg har derfor lavet mit setup således at enhver forespørgsel på en challenge fil, gives til acme.eksempel.dk. På den måde slipper jeg for at lave en challenge konfiguration under alle virtuelle hosts jeg opretter i fremtiden.

Apache

Linierne herunder har jeg placeret i en *.conf fil under /etc/apache2/conf-available

Det næste jeg gør, er at oprette et dedikeret sted til challenge filen

Og så skal jeg tilføje min acme.eksempel.dk virtuelle host

/etc/apache2/sites-available/acme.eksempel.dk.conf

Og til sidst huske at aktivere om nødvendigt og genstarte Apache

Nginx

Der er nok en god grund, men i Nginx kan man ikke lave en global konfiguration med location der gælder alle virtuelle hosts. Så her har jeg lavet en fil som jeg inkluderer i konfigurationen for port 80.

/etc/nginx/acme.conf

Alternativ: I mit tilfælde er der både Nginx og Apache på samme server, og acme.eksempel.dk serveres fra Apache. Derfor laver jeg blot en rewrite:

Husk genstart af Nginx: service nginx restart

Test af webserver konfiguration

Når et certifikat oprettes vil certbot lave stien .well-known/acme-challenge/filnavn under /var/www/letsencrypt challenge. Let’s Encrypt vil herefter forsøge at tilgå ~.well-known/acme-challenge/filnavn for det domæne certifikatet skal gælde. For at teste at din webserver konfiguration virker, kan du derfor oprette den sti, og se om du kan tilgå den i din browser:

Smid evt lidt indhold i test.txt, som f.eks. “hello world” eller lign. Gå derefter til http://et-af-dine-domæner.dk/.well-known/acme-challenge/test.txt. Hvis du får en 404 fejl, må du tilbage til tegnebrættet…

Husk at slette mappen igen når du er færdig med at teste:

Oprettelse af certifikater

Nu har vi gjort alt det forarbejde der kun skal udføres een gang. Nu kan vi generere det første certifikat. Jeg har gjort brug af følgende parametre, afhængig af omstændighederne.

  • certonly  Certbot kan konfigurere din virtuelle host for dig, men det foretrækker jeg at gøre selv, da jeg allerede har virtuelle hosts med ssl. Og jeg vil helst ikke have at certbot laver rod i det.
  • –webroot Placer filer i en mappe til verifikation (challenge)
  • –webroot-path Sti til mappen som challenge filen skal placeres i
  • –email Email til registrering og anden kontakt. Flere adresser kan angives separeret med komma, eks: u1@eksempel.dk,u2@eksempel.dk.
  • –agree-tos Accepter ACME Subscriber Agreement
  • -d [domain] De domæner certifikatet skal gælde for
  • –no-eff-email Føj ikke email adressen til EFF maillisten
  • –preferred-challenges Kommasepareret liste med prioriterede challenge typer
  • –noninteractive Undlad at blokere skriptet ved at afvente brugerinput (praktisk vedr. cron)
  • Test parametre:
    • –debug-challenges Afvent bruger interaktion før challenges slettes
    • –dry-run Benyt “sandkasse” servere da dette er en test

De to sidste parametre, fjernes når du er klar til at lave et egentligt certifikat.

Jeg har lavet et lille shell script der husker parametrene for mig, så jeg nemt at kan oprettet et certifikat:

Det ser således ud:

Og her er indholdet af scriptet:

Fremover vil certbot automatisk (via cron) sørge for at forny certifikaterne når den detekterer at et certifikat udløber inden for de næste 30 dage. Dette kræver en genstart af webserveren, og det skal jeg derfor gøre selv. Men vi opdaterer og genstarter vores servere jævnligt, så det vil ske under alle omstændigheder.