Automatická aktualizácia Let's Encrypt certifikátov

13.12.2015 09:48 | Přečteno: 2900× | Web |

Certifikáty Let's Encrypt sú vydávané s dobou platnosti 90 dní. Dokumentácia toho o aktualizácii moc nepíše, takže som si vymyslel takú malú blbú utilitku, ktorá aktualizuje certifikáty.

Sekcia Renewal v oficiálnej dokumentácii je pomerne strohá. Odporúča nastaviť v crone čas aktualizácie kratší než 90 dní (napríklad 1 mesiac).

V prípade zlyhania (pokaziť sa môže všeličo od pripojenia až po reštart servera v nevhodný čas) nedôjde k aktualizácii certifikátu. Preto zrejme dokumentácia odporúča mesiac (k zlyhaniu môže dôjsť maximálne 2x).

Ja som sa rozhodol kým nie je krajšie oficiálne riešenie (napr. systemd-letsencryptd ) napísať malý skript, ktorý sa bude spúšťať každý deň (alebo každú hodinu, to je jedno) a obnoví certifikáty až keď sú 10 dní pred vypršaním platnosti.

Upozorňujem, že nie som dobrý v písaní bash skriptov, takže neručím za funkčnosť (po prípadných pripomienkach v komentároch upravím). Začnem nastavením konfiguračného súboru /etc/letsencrypt/cli.ini nech neotravuje s licenčnými podmienkami:

agree-tos
email = vas@email.com

A teraz celá tá nechutnosť, ktorá kontroluje platnosť:

#!/bin/bash
   
BEFORE_EXPIRE=`find /etc/letsencrypt/live -type l -mtime +80`

if [ ! -z "$BEFORE_EXPIRE" ]; then
  /cesta/k/letsencrypt/letsencrypt-auto certonly \
    --config /etc/letsencrypt/cli.ini \
    --renew-by-default --webroot \
    -w /var/www/root1 -d root1.domain.org \
    -w /var/www/root2 -d root2.domain.org;
  /etc/init.d/nginx reload
fi

Symbolické odkazy na certifikáty sa ukladajú do /etc/letsencrypt/live/domena/. Príkaz find vyhľadá symbolické odkazy staršie než 80 dní (Let's Encrypt ponecháva staré certifikáty a mení cieľ symbolického odkazu). Ak v /etc/letsencrypt/live zostali mŕtve domény skript sa bude pokúšať pri každom spustení aktualizovať certifikáty, takže pozor na to.

Ešte upozonenie na koniec: celý skript je len núdzové riešenie. Spolieha sa na implementačné detaily, čo nie je dobré.

       

Komentáře

[Bystroushaak]

Nice. Já bych to asi napsal v pythonu, v četně třeba alertu, že se nepodařilo obnovit, když se nepodaří obnovit. Může se změnit API, nebo co já vím a pak bys mohl mít skrytý problém, o kterém se nějakou dobu nedozvíš.

[xkucf03]

Na kontrolu návratového kódu procesu snad není potřeba Python, ne?

Co se týče dohledu, ten je ideální mít nezávislý na tom, jestli se skript pro obnovu pustil nebo ne. Prostě systém, který hlídá tvoje služby, kontroluje dostupnost a dá ti mj. vědět, když se datum expirace nějakého certifikátu nebezpečně přiblíží.

[Bystroushaak]

Šlo mi spíš o

Upozorňujem, že nie som dobrý v písaní bash skriptov, takže neručím za funkčnosť (po prípadných pripomienkach v komentároch upravím).

[Acci]

Spíš bych kontroloval reálný datum vypršení certifikátu než poslední změnu souboru s certifikátem.

[mirec]

To je síce fajn, ale nechce sa mi s tým babrať Je to len dočasné riešenie:

Let’s Encrypt is working hard on automating the renewal process. Until the tool is ready, we are sorry for the inconvenience!

[johniez]

A pritom je na to utilita: ssl-cert-check

[mirec]

Ako sa to skriptuje? Nech s tým skúšam čokoľvek vracia mi 0.

[a1bert]

for a in $(cat seznam_certifikatu.txt) ; do
if [ -f $a ] ; then
 if ! openssl x509 -in $a -checkend $INTERVAL > /dev/null ; then
  notify
 fi
fi
done

[Radek Hladik]

ja to mam cca takhle:

#!/bin/bash
cd /root/letsencrypt/letsencrypt


domain=www.example.com
webroot=/data/www/www.example1.com/html/letsencrypt/www.example.com/
days=65
certfile=/etc/letsencrypt/live/www.example.com/cert.pem
email=mail@example.com

./letsencrypt-auto --email $email  --agree-dev-preview --server https://acme-v01.api.letsencrypt.org/directory -v -t   -a webroot    --webroot-path $webroot  -d $domain  auth >>/var/log/letsencrypt/console.l

firstline="Script $0 at "`hostname`" designed to renew letsencrypt certificate"
subj='[letsencrypt]['"$domain"'] Certificate renewal'
if openssl x509 -checkend $(($days*86400)) -noout -in $certfile
then
  {
  echo $firstline
  echo "Renewed Certificate is valid for at least $days days!"
  openssl x509 -noout -text -in $certfile
  } | mail -s "$subj" $email
else
 {
  echo $firstline
  echo "Certificate has expired or will do so within $days days (or is invalid/not found)!"
  openssl x509 -noout -text -in $certfile
  } | mail -s "$subj FAILED - manual action required" $email
fi
#service httpd restart

Je to zatím taky jen prototyp, ale mělo by to fungovat. Chybí tomu zatím nějaké zhezčení a nějaký lepší management těch certifikátů, protože plánuju mít na jednom serveru hromadný management všech certifikátů ze strojů, kde nebudu chtít instalovat tu jejich utilitu.

I proto je ta cesta k tomu webu trochu složitější, protože se počítá s tím, že webserver běží na jiném stroji a má nějakou takovouto sekci:

        location /.well-known/acme-challenge/ {
            return 301 $scheme://www.example1.com/letsencrypt/www.example.com$request_uri;
        }

T.j. letsencrypt-auto běží na stroji www.example1.com, obnovuje doménu example.com, na jejímž serveru je jen přesměrování a vlastní ověření tak ve skutečnosti proběhne na www.exmaple1.com. Toto funguje bez problému, zatím jsem to zkoušel jen na stejném stroji, takže proto je tam zaremovaný ten restart toho webserveru, ale počítám s tím, že se to přes SSH nacpe kam potřebuje a tam zrestartuje...

V principu mi jde o to, abych nemusel tu jejich utilitu instalovat na všech strojích a abych měl všechny certifikáty na jednom místě. Půjdo pak snadněji spravovat a ideálně i výše uvedený skript bude jen zárodkem pro komplexnější management - třeba že všechny obnovené domény z jednoho stroje nahraje na ten server najednou a udělá jen jeden restart nebo bude posílat pravidelně přehled certifikátů....

[mirec]

Hmm, to je zaujímavé, nečakal by som, že budú podporovať presmerovanie v acme-challenge. Asi by som sa na to vôbec nespoliehal a nastavil tam proxy_pass keby to v budúcnosti zmenili.

[Radek Hladik]

Tak ono celé to Domain Validation je právě největší slabinou celého Let's Encrypt. Osobně očekávám, že to povede k tomu, že brwosery a spol začnou ukazovat nějaké upzornění, že se jedná o certifikáty "druhé kategorie", něco jako buďte rádi, že se to šifruje, ale peníze přes to neposílejte

Speciálně jsem právě zkoušel, jestli jim redirect bude nebo nebude vadit, ale přesně podle očekávání nevadí. Ono je to logické, protože oni v principu ověřují, že člověk má nějaký přístup k / toho webu a právě proto, že existují triviální řešení, jak ten redirect nasimulovat, tak asi nemá smysl ho nepodporovat. Například ten proxy_pass nebo případně mám v záloze připravený jednoduchý php skript, který udělá něco podobného, atd...

Osobně si myslím, že největší přínos celého Let's Encrypt bude právě v tom, že se začnou víc řešit právě takovéto otázky. Například na https://community.letsencrypt.org/t/how-do-you-confirm-the-person-asking-for-the-certificate-actually-owns-the-domain/30/14 se trošku řešilo, jak se pozná, že člověk má přístup k cílovému serveru a ne jen k nějakému routeru cestou:

I'm not sure whether we'll publish a list of hosts that may perform validations. One security challenge for DV validation is that an attacker might be able to manipulate the network path between the host that performs the validation and the host that responds. To address this, we might in the future perform validations from several different locations on the Internet. We might not want to let prospective attackers know all of the network paths or locations that they'd have to manipulate in order to interfere with the validation for a particular name or server.

Docela mě polil pot, když jsem si uvědomil, že člověk mluvící za CA, která může vydávat uznavané certifikáty, vůbec přemyšlí o řešení, které je založené na nějakém utajování IP adres, ze kterých se bude dělat domain validation...

[mirec]

Ja som v bezpečnosti trochu blbec (programátor, admin len z donútenia).

Ak sa niekto zmocní routra na ktorom mám pripojený server môže si kedykoľvek sám vygenerovať certifikát na danú doménu (opravte ma ak sa mýlim). Ktorýkoľvek klient, ktorý sa bude pripájať k serveru môže potom dostať na prvý pohľad korektne podpísaný certifikát vydaný na správnu doménu ale dáta môžu byť smerované na útočníkov server. Dá sa tomu zábrániť?

Je možné podvrhnúť DNS tak aby pri overení bolo možné získať certifikát aj bez nutnosti prístupu k routru?

A nakoniec asi najzaujímavejšia otázka: prináša Let's Encrypt väčšie zabezpečenie než na dlhú dobu vydaný certifikát podpísaný sám sebou (ak beriem do úvahy, že som na slovensku, teda nemôžem mať dnssec, v prípade vydania certifikátu pre moju doménu a podvrhnutia DNS bude používateľ vidieť stále bezpečné spojenie zatiaľ čo pri certifikáte podpísanom samým sebou by bol okamžite upozornený, že sa zmenil certifikát)?

[R]

Neprinasa. Jedina vyhoda Let's Encrypt je v tom, ze browser nepinda ako pri self-signed certifikate.

[Radek Hladik]

Což podle mně za chvílí pomocí nějakých doplňků browsery začnou, protože pokud se vydalo 100k certifikátů během 14 dnů, tak si nedovedu představit, že z toho nebude nějakej průser t.j. očekávám, že brzy vznikne nějaký doplňek, který bude říkat něco ve stylu, jak jsem psal výše: "spojení je šifrováno, doména je pouze základně ověřena, takže tomu moc nevěřte"

[xkucf03]

Rozdíl je v tom, že u Let's Encrypt se zkontroluje otisk/certifikát z více různých míst, takže MITM útočník by musel být hned před serverem. Kdežto u samopodepsaných certifikátů mu stačí, když bude kdekoli mezi tebou a serverem, klidně těsně před tebou (tvoje místní síť). Kromě toho, že je takový útok snáze proveditelný, dá se i lépe cílit a utajit – nedozví se o něm ostatní, protože ti dostávají správný certifikát.

[R]

Ked ma klient raz ten self-signed certifikat ulozeny, tak utocnikovi nepomoze nic. Nosil som ho napriklad na USB kluci - musel som ho importovat rucne, kedze niektore programy ho nevedeli ulozit zo servera.

Naopak pri Let's Encrypt je mozne vygenerovat falosny certifikat (ked bude utocnik pred serverom), ktory bude rovnako doveryhodny ako pravy.

[Dušan]

Podvrhnutí certifikátu můžeš zabránit nastavením HPKP, ale je to TOFU (pokud fingerprint nepřidáš na seznam distribuovaný s browserem). A je dobry nastavit i HSTS.

[Radek Hladik]

Ano, pokud se někdo dostane k routeru kdekoliv cestou, může podvrhnout cokoliv. Veškeré Domain validated certifikáty jsou k tomuto náchylné a není snadná cesta, jak z toho ven. Proto si myslím, že Let's Encrypt prostě povede k tomu, že se tento problém dostatečně zvýrazní... Samozřejmě ideální je DNSSEC, ale musí být na ověřovacím stroji dobře naimplementován, aby se mu nedaly podsunout záznamy, které by tvrdily, že DNSSEC není.

Proto existují EV certifikáty, kde se už vlastnictví domény ověřuje lidmi a výrazně více do hloubky (včetně například zaslání dokumentů jako je výpis z obchodního rejstříku), ale teoreticky je možné obejít i tento proces.

Takže úroveň zabezpečení je de facto stejná, jen teoreticky vlastnictví domény trochu ověřil někdo třetí, ale ověřil úplně stejným způsobem, jaký uživatelé používají (podíval se na stránky). T.j. hlavní smysl celého projektu má být zvýšit počet šifrovaných spojení, tedy podpořit HTTPS na úkor HTTP...

[MP]

Existuje acme script.

[mirec]

Wow vedel som, že niečo musí existovať. No mohli dať aspoň odkaz do dokumentácie ;)

[Hanna]

Very nice post. I just stumbled upon your blog and wanted to say that I have really enjoyed browsing your blog posts 192.168.1.1 192.168.1.1 192.168.1.1 192.168.1.1