Nginx s acme.sh na Arch

Moderný internet je plný šifrovania. V mnohých ohľadoch je šifrovanie stále voliteľné, hoci nešifrovaná komunikácia akéhokoľvek druhu je každým dňom vzácnejšia. Existujú faktory, ktoré prispievajú k tomuto trendu. Ako konkrétny príklad, niektoré domény najvyššej úrovne, ako .app alebo .dev, majú v mainstreamových prehliadačoch napevno zakódovaný vynútený režim HTTPS pre tieto vybrané TLD.

Aby HTTPS fungovalo, prehliadač a webserver musia najprv vykonať výmenu kľúčov. Táto výmena sa označuje ako TLS handshake. Po úspešnom handshake môžu prehliadač a webserver komunikovať bezpečne, čo znamená, že ktokoľvek, kto odpočúva komunikáciu, vidí len nezmysel, pokiaľ komunikáciu nedokáže skutočne dešifrovať.

Aby webserver mohol vykonať TLS handshake, potrebuje certifikát, ktorý sa používa na šifrovanie verejným kľúčom. Certifikát sa tradične kupoval od Certifikačnej autority (CA), kým nezisková CA s názvom LetsEncrypt nezačala poskytovať certifikáty zadarmo, takže môžeme mať všetci pekné veci (bezpečnú komunikáciu s webserverom).

ACME a Certbot #

ACME je skratka pre Automated Certificate Management Environment a poskytuje protokol umožňujúci akémukoľvek webserveru sediaciemu pod skutočným doménovým menom získať certifikát od LetsEncrypt zadarmo.

Oficiálny klient implementujúci protokol ACME sa volá Certbot a je napísaný v Pythone. Je to výkonný klient, ale má tiež svoje problémy. Pretože je to akýsi švajčiarsky nôž, snaží sa zvládnuť mnoho úloh. Svojou povahou je trochu ťažší na závislostiach. Konkrétne sa mi nepáči, že predvolene pridáva riadky do konfiguračných súborov Nginx. Ďalší problém som mal na Ubuntu stroji. Keď vyšiel 20.04, repozitáre boli pomalšie s aktualizáciou a musel som manuálne záplatovať kód certbotu, čo nie je príjemná skúsenosť. To je tiež dôvod, prečo experimentujem s Arch ako serverom.

Certbot nie je jediný dostupný klient hovoriaci protokolom ACME. Protokol ACME je dostupný ako RFC8555 a certifikát od LetsEncrypt môže ktokoľvek získať dokonca manuálne podľa neho. Existuje tiež mnoho klientov tretích strán, ktoré tento proces automatizujú.

Vstupuje acme.sh #

Jedným z takýchto klientov je acme.sh a ako napovedá jeho názov, je to Shell skript s (takmer) žiadnymi závislosťami. Táto skutočnosť zmierňuje problém pomalej aktualizácie repozitárov takmer úplne, pretože vždy stačí použiť git na získanie najnovšej verzie, bez ohľadu na to, kde sú repozitáre hostiteľského operačného systému. Stránka Acme.sh uvádza:

Je to pravdepodobne najjednoduchší a najinteligentnejší shell skript na automatické vydávanie a obnovu bezplatných certifikátov od Let’s Encrypt.

Pozrime sa, či toto tvrdenie obstojí.

Nastavenie #

Začnite nastavením DNS záznamu typu A alebo CNAME pre sub.example.com smerujúceho na verejnú IP adresu hostiteľa, kde budú tieto kroky aplikované. DNS záznamy je možné nastaviť kedykoľvek, ale môže trvať nejaký čas, kým nameservery šíria zmeny, preto je lepšie to urobiť ako prvé.

Tento návod predpokladá stať sa superužívateľom:

su -

Nainštalujte acme.sh a Nginx, prípadne nginx-mainline:

pacman -S --needed acme.sh nginx

Uistite sa, že na porte 443 používanom pre HTTPS nič nepočúva:

ss -tuna | grep :443

Ak tam niečo beží, zastavte to.

Vydanie certifikátu #

Ďalší krok využíva Application-Layer Protocol Negotiation (ALPN), čo je počiatočná časť TLS handshake spomínaná vyššie. Acme.sh je schopný vydať certifikát pomocou ALPN režimu. Certifikáty sa inštalujú do /root/.acme.sh/sub.example.com/:

acme.sh --issue --alpn -d sub.example.com

Teraz vyberte umiestnenie, kde uložíte certifikáty, príklady:

/etc/ssl/certs používa OpenSSL
/etc/letsencrypt/live používa Certbot
/etc/nginx/ssl preferujú niektorí používatelia

Ak certifikáty používa výlučne Nginx, /etc/nginx/ssl je dobrá voľba:

mkdir /etc/nginx/ssl

Je dôležité nastaviť správne oprávnenia pre túto zložku na ochranu súkromného kľúča:

chmod 700 /etc/nginx/ssl

Zložka musí byť vo vlastníctve používateľa root.

Konfigurácia Nginx #

Teraz skopírujte vygenerované certifikáty tam, venujte pozornosť reloadcmd:

acme.sh --install-cert -d sub.example.com  \
  --key-file '/etc/nginx/ssl/sub.example.com.key' \
  --fullchain-file '/etc/nginx/ssl/sub.example.com.cer' \
  --reloadcmd "systemctl force-reload nginx"

Dôležité: skontrolujte oprávnenia. Zložka /etc/nginx/ssl by mala mať 700, .cer súbory by mali mať 644 a .key súbor by mal mať 600. Všetko by malo byť vo vlastníctve roota. Upozorňujeme, že vlastníctvo a oprávnenia sa zachovávajú automaticky pri obnove certifikátov.

find /etc/nginx/ssl -printf "%m %f\n"

700 ssl
600 sub.example.com.key
644 sub.example.com.cer

Pridajte relevantné údaje do bloku server v konfigurácii Nginx. Nie všetky konfiguračné direktívy sú ponúknuté v príklade nižšie, len tie najrelevantnejšie. Zvážte konzultáciu dokumentácie Nginx o HTTPS.

server {
    listen 443 ssl;
    server_name sub.example.com;
    ssl_certificate     /etc/nginx/ssl/sub.example.com.cer;
    ssl_certificate_key /etc/nginx/ssl/sub.example.com.key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;
}

Nakoniec spustite a povoľte službu Nginx:

systemctl enable nginx.service --now

Teraz otvorte stránku v prehliadači a skontrolujte, či HTTPS funguje.

Poznámka: keď HTTPS cez Nginx funguje, zvážte prepnutie na získanie certifikátu cez Nginx režim, pretože obnova certifikátu cez ALPN už nebude fungovať, keďže Nginx už počúva na porte 433. Dôvod, prečo bol ALPN použitý na začiatku, je, že nevyžaduje žiadne závislostiach na rozdiel od standalone režimu vyžadujúceho socat. Druhý dôvod je, že Nginx validačný režim môže na začiatku vyžadovať funkčnú konfiguráciu Nginx, takže je lepšie začať bezpečne.

acme.sh --issue --nginx -d sub.example.com

Toto je 41. príspevok série #100daystooffload.