Poměrně často musíme pracovat s SSL certifikáty. Pojďme si připomenout proces vytváření a instalace certifikátu (obecně pro většinu).
- Najít poskytovatele (web, na kterém můžeme koupit SSL).
- Vygenerovat CSR.
- Odeslat ho poskytovateli.
- Ověřit vlastnictví domény.
- Získat certifikát.
- Přeformátovat certifikát do potřebného formátu (volitelně). Například z pem do PKCS #12.
- Nainstalovat certifikát na webový server.
Relativně rychlé, není to složité a je to jasné. Tato varianta je zcela dostačující, pokud máme maximálně desítku projektů. A co když jich je více, a každý má minimálně tři prostředí? Klasické dev — staging — production. V tomto případě je vhodné uvažovat o automatizaci tohoto procesu. Navrhuji se hlouběji zamyslet nad problémem a najít řešení, které v budoucnu minimalizuje časové náklady na vytváření a údržbu certifikátů. Článek bude obsahovat analýzu problému a krátký průvodce pro opakování.
Už předem podotýkám: hlavní specializací naší společnosti je .net, a tedy IIS a další související věci pro Windows. Proto bude klient ACME a všechny jeho akce rovněž popsány z pohledu využívání Windows.
Pro koho je to aktuální a některé základní údaje
Společnost K v osobě autora. URL (pro příklad): company.tld
Projekt X — jeden z našich projektů, jehož zpracováním jsem došel k závěru, že je opravdu potřeba směřovat k maximální úspoře času při práci s certifikáty. Tento projekt má čtyři prostředí: dev, test, staging a production. Dev a test jsou na naší straně, staging a production na straně klienta.
Specifikou projektu je, že má velké množství modulů, které jsou dostupné jako subdomény.
Máme tedy následující obraz:
Dev
Test
Staging
Production
projectX.dev.company.tld
projectX.test.company.tld
staging.projectX.tld
projectX.tld
module1.projectX.dev.company.tld
module1.projectX.test.company.tld
module1.staging.projectX.tld
module1.projectX.tld
module2.projectX.dev.company.tld
module2.projectX.test.company.tld
module2.staging.projectX.tld
module2.projectX.tld
…
…
…
…
moduleN.projectX.dev.company.tld
moduleN.projectX.test.company.tld
moduleN.staging.projectX.tld
moduleN.projectX.tld
Pro produkci se používá zakoupený wildcard certifikát, zde nejsou žádné otázky. Pokrývá však pouze první úroveň subdomény. Pokud tedy máte certifikát pro *.projectX.tld — pak pro staging.projectX.tld bude fungovat, ale pro module1.staging.projectX.tld už ne. A kupovat samostatný se nějak nechce.
A to je jen na příkladu jednoho projektu jedné společnosti. A projektů samozřejmě není jen jeden.
Obecné důvody pro řešení této otázky vypadají přibližně takto:
- Relativně nedávno Google navrhl zkrátit maximální dobu platnosti SSL certifikátů. Se všemi důsledky.
- Usnadnit proces vydávání a údržby SSL pro interní potřeby projektů a společnosti jako celku.
- Centralizované uchovávání záznamů o certifikátech, které částečně řeší problém potvrzení domény pomocí DNS a následného automatického obnovení, a také řeší otázku důvěry zákazníka. Že by to, vypadá důvěryhodněji na CNAME na server společnosti partnera/vykonatele, než na externí zdroj.
- No a nakonec, v tomto případě fráze „lépe mít než nemít“ padne výborně.
Výběr poskytovatele SSL a přípravné kroky
Z dostupných možností bezplatných SSL certifikátů byly zvažovány cloudflare a letsencrypt. DNS pro to (a některé další projekty) je umístěno na cloudflare, ale nejsem příznivcem používání jejich certifikátů. Proto bylo rozhodnuto použít letsencrypt.
Pro vytvoření wildcard SSL certifikátu je potřeba potvrdit vlastnictví domény. Tento proces zahrnuje vytvoření určitého DNS záznamu (TXT nebo CNAME), s následnou kontrolou při vydávání certifikátu. V Linuxu existuje utilita — certbot, která umožňuje částečnou (nebo úplnou pro některé poskytovatele DNS) automatizaci tohoto procesu. Pro Windows z nalezených a ověřených možností ACME klientů jsem se zastavil na WinACME.
A záznam pro doménu je vytvořen, přejděme k vytvoření certifikátu:
Nás zajímá poslední výstup, a to — dostupné možnosti potvrzení vlastnictví domény pro vydání wildcard certifikátu:
- Vytvoření DNS záznamů ručně (automatické obnovení není podporováno)
- Vytvoření DNS záznamů pomocí acme-dns serveru (podrobnosti si můžete přečíst tady.
- Vytvoření DNS záznamů pomocí vlastního skriptu (analog pluginu cloudflare pro certbot).
Na první pohled se třetí bod zdá být vhodný, ale co když DNS poskytovatel tuto funkci nepodporuje? A my potřebujeme obecný případ. A obecný případ jsou CNAME záznamy, ty podporují všichni. Proto se zastavíme u bodu 2 a pustíme se do nastavování svého ACME-DNS serveru.
Nastavení ACME-DNS serveru a proces vydání certifikátu
Pro příklad jsem vytvořil doménu 2nd.pp.ua a budu ji dále používat.
Povinným požadavkem pro správnou funkci serveru je vytvoření NS a A záznamu pro jeho doménu. A první nepříjemnost, se kterou jsem se setkal, je, že cloudflare (alespoň v režimu bezplatného použití) neumožňuje současně vytvořit NS a A záznam pro stejný host. Není to, že by to bylo problémem, ale v bind to lze. Podpora odpověděla, že to jejich panel nedovoluje. To nevadí, vytvoříme dva záznamy:
acmens.2nd.pp.ua. IN A 35.237.128.147
acme.2nd.pp.ua. IN NS acmens.2nd.pp.ua.
V této fázi by měl být host acmens.2nd.pp.ua.
$ ping acmens.2nd.pp.ua
PING acmens.2nd.pp.ua (35.237.128.147) 56(84) bytes of data
Ale acme.2nd.pp.ua se nebude resolvovat, protože DNS server, který ho obsluhuje, ještě nebyl spuštěn.
Záznamy byly vytvořeny, přecházíme tedy k nastavení a spuštění ACME-DNS serveru. Bude běžet u mě na ubuntu serveru v docker kontejneru, ale spustit ho lze kdekoli, kde je golang. Windows je také docela možné, ale já raději používám Linux server.
Vytváříme potřebné adresáře a soubory:
$ mkdir config
$ mkdir data
$ touch config/config.cfg
Využijeme vim, váš oblíbený textový editor, a vložíme do config.cfg vzor konfigurace.
Pro úspěšnou funkci stačí upravit sekce general a api:
[general]
listen = "0.0.0.0:53"
protocol = "both"
domain = "acme.2nd.pp.ua"
nsname = "acmens.2nd.pp.ua"
nsadmin = "admin.2nd.pp.ua"
records =
"acme.2nd.pp.ua. A 35.237.128.147",
"acme.2nd.pp.ua. NS acmens.2nd.pp.ua.\n...\n[api]\n...\ntls = "letsencrypt"\n…
Také, pokud chcete, vytvoříme docker-compose soubor v hlavním adresáři služby:
version: '3.7'
services:
acmedns:
image: joohoi/acme-dns:latest
ports:
- "443:443"
- "53:53"
- "53:53/udp"
- "80:80"
volumes:
- ./config:/etc/acme-dns:ro
- ./data:/var/lib/acme-dns
Hotovo. Můžete spustit.
$ docker-compose up -d
V této fázi by se měl začít resolvovat host acme.2nd.pp.ua, a objevit 404 na https://acme.2nd.pp.ua
$ ping acme.2nd.pp.ua
PING acme.2nd.pp.ua (35.237.128.147) 56(84) bytes of data.
$ curl https://acme.2nd.pp.ua
404 stránka nenalezena
Pokud se toto nezobrazilo — docker logs -f Pomoc, dobro, logy jsou snadno čitelné.
Můžeme začít vytvářet certifikát. Otevřeme PowerShell jako správce a spustíme winacme. Zajímají nás volby:
- M: Vytvořit nový certifikát (plné možnosti)
- 2: Ruční vstup
- 2: [dns-01] Vytvořit ověřovací záznamy pomocí acme-dns (https://github.com/joohoi/acme-dns)
- Na otázku o odkazu na server ACME-DNS zadáváme URL vytvořeného serveru (https). URL serveru acme-dns: https://acme.2nd.pp.ua
Klient vydá záznam, který je třeba přidat k existujícímu DNS serveru (procedura je jednorázová):
[INFO] Vytváření nového registru acme-dns pro doménu 1nd.pp.ua
Doména: 1nd.pp.ua
Záznam: _acme-challenge.1nd.pp.ua
Typ: CNAME
Obsah: c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Poznámka: Některé DNS kontrolní panely přidají závěrečnou tečku automaticky.
Pouze jedna je požadována.
Vytvoříme požadovaný záznam a ujistíme se, že byl vytvořen správně:
$ dig CNAME _acme-challenge.1nd.pp.ua +short
c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Potvrďte, že jsme vytvořili požadovaný záznam ve winacme, a pokračujte v procesu vytváření certifikátu:
Jak používat certbot jako klienta, je popsáno tady.
Na tomto procesu vytváření certifikátu je hotovo, nyní ho lze nainstalovat na webový server a používat. Pokud při vytváření certifikátu nastavíte také úkol v plánovači, proces obnovy certifikátu se bude od té doby provádět automaticky.
Zdroj: habr.com
