# TLS certifikáty ve Webshipu: Vestavěná ACME CA
TLS certifikát plní dvě funkce: pomáhá šifrovat připojení a sděluje klientovi, s jakou identitou komunikuje. Šifrování může být silné, zatímco rozhodnutí o důvěře může být pro publikum nesprávné. Proto musí automatizace certifikátů začít jednou otázkou: kdo musí této webové stránce důvěřovat?
Webship 1.4.0 provádí tuto volbu nezávisle pro každou nakonfigurovanou stránku. Veřejná webová stránka může používat ACME certifikát důvěryhodný prohlížečem, interní služba může používat vestavěnou soukromou certifikační autoritu Webshipu a stránka s existující PKI může zachovat soubory certifikátů spravované operátorem. Všechny mohou sdílet jeden proces Webshipu, aniž by sdílely jeden soukromý klíč nebo jednu hranici důvěry.
Čtyři automatické režimy certifikátů, vybírané podle webu
Pole certificate_mode patří ke každému záznamu [[sites]]. Není to globální přepínač.
| Režim | Důvěryhodný zdroj | Nejvhodnější shoda | Ověřovací cesta | | --- | --- | --- | --- | | per_site | Veřejné úložiště důvěry pro prohlížeče a operační systémy | Veřejná stránka s jedním přesným názvem hostitele | Veřejné ACME s TLS-ALPN-01 | | flotila | Veřejné prohlížeče a úložiště důvěryhodných systémů | Velké sady třetích a čtvrtých úrovní názvů pod explicitně registrovanými doménami | Veřejné ACME s DNS-01 a stabilními certifikátovými segmenty | | vestavěný | Soukromý kořen Webship nainstalovaný operátorem | Interní služby, spravovaná zařízení, soukromé flotily a testovací prostředí | Vydávání v procesu; žádná externí výzva | | sdílené | Veřejné úložiště důvěry pro prohlížeče a operační systémy | Starší nasazení, která úmyslně používají jednu veřejnou skupinu multi-SAN | Veřejné ACME s TLS-ALPN-01 |
Výchozí hodnota je per_site. Objedná jeden veřejný certifikát pro přesný název webu. Režim Fleet je škálovatelná veřejná možnost pro mnoho hlubokých subdomén. Režim Embedded používá soukromou interní certifikační autoritu Webshipu. Režim Shared zůstává dostupný pro kompatibilitu, ale není výchozí.
Úplný certifikát a klíč v rámci [sites.tls] mají vždy přednost před automatickým vydáváním pro danou stránku.
Co znamená „vestavěná ACME CA“
Konfigurační sekce se jmenuje [acme_ca], ale vložený CA není veřejná ani síťově přístupná služba ACME. Nezveřejňuje žádný adresářový endpoint, nepřijímá žádnou vzdálenou registraci, nevolá žádné API registrátora a nevykonává žádnou výzvu k prokázání kontroly.
Místo toho Webship uchovává celou cestu soukromé emise v jednom procesu:
- Stránka vybírá certificate_mode = "embedded".
- Webship načte nebo vytvoří soukromou kořenovou identitu v nakonfigurovaném adresáři stavu.
- Webship generuje pro web nový soukromý klíč.
- Vložený kořen podepisuje listinový certifikát pro právě toto jméno.
- Webship ověřuje dokončenou identitu před jejím instalováním do živého TLS resolveru.
- Certifikát je pak k dispozici pro každý povolený protokol na této stránce.
Síťová výzva ve stylu ACME by dokázala Webshipu pouze něco samotnému, takže zabudovaná cesta záměrně nemá žádný síťový protokol. Sekce [acme_ca] je soukromý stav PKI: určuje, kde se nachází kořen a jak dlouho zůstávají vydané listové certifikáty platné.
Nakonfigurujte vložený certifikát pro jednu stránku
Toto je minimální podoba pro soukromou stránku:
~~~toml listen = "0.0.0.0:443"
[tls] unknown_sni = "odmítnout"
[automatické_tls] povoleno = pravda cache_dir = "/var/lib/webship/acme"
[acme_ca] state_dir = "/var/lib/webship/acme-ca" platnost_listu_dny = 90
[[stránky]] doména = "service.internal.example" root = "/srv/service" certificate_mode = "embedded"
[sites.protokoly] h1 = pravda h2 = pravda h3 = pravda ~~~
Kořenová identita je vytvořena líně, když ji vestavěný web poprvé potřebuje. Webship uchovává kořenový klíč s restriktivními oprávněními ve složce state_dir. Kořenový certifikát má desetiletou dobu platnosti; doba platnosti listu je řízena parametrem leaf_validity_days.
Nakládejte s oběma úložišti jako s produkčním stavem:
- Cache ACME automaticky spravuje identity webových stránek.
- Adresář stavu zabudovaného CA obsahuje soukromou kořenovou identitu.
- K účtu služby je potřeba přístup, ale uživatelé aplikace ne.
- Zálohy musí zachovat důvěrnost a oprávnění souborů.
- Produkce, vývoj a testování by měly používat samostatné kořenové adresáře a samostatné složky.
Smazání kořenového adresáře „nezruší TLS“. Vytvoří novou důvěryhodnou kotvu. Klienti, kteří důvěřují starému kořeni, odmítnou certifikáty vydané náhradním kořenem, dokud nebudou aktualizovány jejich úložiště důvěry.
Soukromá důvěra je záměrná
Certifikáty z vestavěné CA nejsou automaticky důvěryhodné veřejnými prohlížeči ani operačními systémy. Stávají se důvěryhodnými až poté, co operátor nainstaluje exportovaný kořenový certifikát Webship do důvěryhodného úložiště klienta.
To činí režim vložený vhodným pro:
- firemní notebooky a telefony spravované společností a zaregistrované prostřednictvím správy zařízení;
- interní komunikace mezi službami s explicitním balíčkem CA;
- soukromé spotřebiče a řízené okrajové flotily;
- vývojová a testovací prostředí, která musí simulovat skutečné chování TLS;
- odpojené sítě, které se nemohou spolehnout na veřejnou CA.
Není to správný režim pro běžnou veřejnou webovou stránku, jejíž návštěvníci používají neregulované prohlížeče. Použijte veřejné vydávání per_site pro přesný veřejný název, vydávání pro velké sady veřejných subdomén, sdílené pouze pro záměrné starší nasazení s více SAN, nebo manuální soubory z již důvěryhodného PKI.
Distribuujte klientům pouze kořenový certifikát. Nikdy nesdílejte kořenový soukromý klíč. Vlastnictví tohoto klíče dává jeho držiteli pravomoc vydávat identity, kterým důvěřuje každý registrovaný klient.
Veřejné a soukromé certifikáty mohou koexistovat
Webship 1.4.0 může kombinovat strategie certifikátů na stejném posluchači:
~~~toml listen = "0.0.0.0:443"
[tls] unknown_sni = "odmítnout"
[automatické_tls] povoleno = pravda directory_url = "https://acme-v02.api.letsencrypt.org/directory" cache_dir = "/var/lib/webship/acme" kontakty = ["mailto:ops@example.com"] akceptovat_podmínky_služby = pravda
[acme_ca] state_dir = "/var/lib/webship/acme-ca" platnost_listu_dny = 90
[[stránky]] doména = "www.example.com" root = "/srv/public" certificate_mode = "per_site"
[[stránky]] doména = "control.internal.example" root = "/srv/control" certificate_mode = "embedded"
[[stránky]] doména = "payments.example.com" root = "/srv/payments"
[sites.tls] cert = "/etc/webship/payments-fullchain.pem" key = "/etc/webship/payments-private-key.pem" ~~~
Zde www.example.com získává svůj vlastní veřejný certifikát ACME. control.internal.example získává soukromý certifikát od zabudované CA. payments.example.com zůstává pod externí PKI operátora, protože jeho explicitní soubory mají přednost.
Veřejný adresář ACME je ignorován vloženými stránkami. Vložený kořen nikdy nepodepisuje veřejnou stránku. Ruční stránka není nikdy tiše zapsána do žádného automatického pracovního postupu.
Jeden řešič certifikátů pro H1, H2, H3 a WebTransport
Výběr certifikátu probíhá během TLS handshake, ještě předtím, než existuje HTTP požadavek. Webship používá název serveru z ClientHello k výběru identity webu a poté sjednává aplikační protokol.
- HTTP/1.1 a HTTP/2 používají TLS přes TCP.
- HTTP/3 a WebTransport používají TLS uvnitř QUIC přes UDP.
- Jedna platná identita webu může sloužit pro každý povolený protokol.
- HTTP/3 také vyžaduje dostupnost přes UDP; H1 a H2 používají TCP cestu.
- Alt-Svc může inzerovat H3 a zároveň zachovat TCP zálohu.
TCP, TLS a QUIC používají stejný model identity uvědomělý o stránce. Přesné názvy mají přednost, nejdelší platná zástupná hodnota vyhrává tam, kde jsou nakonfigurovány certifikáty se zástupnými znaky, a neznámé pojmenované SNI může být odmítnuto místo přijetí nesouvisejícího výchozího certifikátu.
Použijte unknown_sni = "reject" na multi-site posluchači, když musí neznámé jméno hostitele selhat zavřeně. Otestujte rozpoznaná jména, nerozpoznaná jména a očekávané chování bez SNI před nasazením do produkce.
Otočit vložené identity bez servisní mezery
Webship zpřístupňuje stav certifikátu a řízené mutace prostřednictvím svého autentizovaného MCP serveru vázaného na loopback:
- webship.tls.get_status uvádí aktivní řešič certifikátů a stav obnovy.
- webship.tls.reissue_certificate okamžitě znovu vydá automaticky spravovaný web pouze tehdy, když tento web používá režim vložený.
- webship.tls.reload znovu načte stav certifikátu přes běžnou chráněnou cestu TLS.
- webship.acme_ca.status hlásí, zda je vybrána privátní CA, její adresář stavu, životnost certifikátu leaf, počet vydání, počet odvolání a nedávný vzorek domény.
- webship.sites.apply přidává nebo odstraňuje stránky podle připnuté verze konfigurace.
Pro zabudované pře-vydání Webship vytvoří a ověří náhradu, než ji nasadí do služby. Současná platná identita slouží až do doby, než je nová identita připravena. Vyřazená identita je zaznamenána až poté, co je náhrada nainstalována.
Operace okamžitého převydání záměrně odmítá veřejné certifikáty per_site. Veřejné obnovení musí zůstat v rámci veřejného životního cyklu ACME, a nemělo by být zaměňováno s privátním probíhajícím podpisem. Sdílené členství v režimu je také restartem zmrazeno, protože změna skupiny s více SAN přestavuje hranici identity.
MCP je privilegovaná řídicí plocha. Držte ji v režimu loopback, vyžadujte TLS a silný nosičový token, používejte autentizovaný tunel pro vzdálenou správu a auditujte každou změnu.
Hranice selhání, na kterých záleží
Bezpečný certifikační systém musí selhat správným směrem.
- Nově nakonfigurované zabudované místo nepřijímá identitu jiného místa, dokud je vydávání v procesu.
- Neplatná náhrada není nainstalována přes funkční certifikát.
- Explicitní ruční soubory zabraňují automatickému vlastnictví tohoto webu.
- Neznámé pojmenované SNI může být odmítnuto před směrováním HTTP.
- Vložená CA zůstává soukromá a nemá žádný vzdálený bod pro registraci.
- Veřejné a zabudované identity používají samostatné cesty ke cache uvnitř stavu automatického TLS.
Varování, že vestavěný CA není inicializován, znamená, že Webship nemohl připravit nakonfigurovaný stavový adresář. Opravte vlastnictví, oprávnění, trvalost nebo dostupnost úložiště před odesláním provozu na ovlivněný web. Neobcházejte chybu kopírováním kořenového klíče jiného prostředí.
Kontrolní seznam výroby
Před povolením režimu vložení:
- Určete všechny skupiny klientů, které musí důvěřovat webu.
- Vytvořte kontrolovaný proces pro export a instalaci kořenového certifikátu.
- Použijte samostatný kořenový stav pro produkci, vývoj a testování.
- Zachovejte a chraňte adresář stavu vložené CA a automatickou mezipaměť TLS.
- Spusťte Webship pod vyhrazeným uživatelským účtem služby s přístupem pouze k požadovanému klíčovému materiálu.
- Vyberte certificate_mode na každém webu, jehož hranice důvěry musí být explicitní.
- Nastavte a otestujte zásadu neznámého SNI.
- Úmyslně povolte H1, H2 a H3 a ověřte cesty pro TCP i UDP.
- Cvičení opětovného vydání, restartu, zálohování, obnovení a ověření důvěryhodnosti klienta mimo produkci.
- Spusťte webship --check-config před nasazením, poté ověřte vydavatele, jména, platnost, řetězec a dohodnuté protokoly z reálného klienta.
Nejprve zvolte důvěru, druhotně automatizaci
Vložená CA odstraňuje závislost na externí certifikační službě pro soukromou infrastrukturu. Nedělá soukromý kořen globálně důvěryhodným a neodstraňuje odpovědnosti provozovatele v oblasti PKI.
Webship automatizuje generování klíčů, podepisování, ověřování, instalaci, rotaci a výběr certifikátů v celém protokolu. Operátor však stále vlastním způsobem spravuje hlavní kořen, registraci klienta, oddělení prostředí, zálohování, obnovu a rozhodnutí o použití veřejné nebo soukromé důvěryhodné cesty.
Toto oddělení je vlastnost. Samostatný server může automatizovat soukromý TLS, aniž by se snažil předstírat veřejnou certifikační autoritu – a veřejné stránky mohou stále používat prohlížečem důvěryhodné vydávání certifikátů pro jednotlivé stránky nebo celou flotilu ve stejném procesu.
Přečtěte si verzovanou dokumentaci Webship 1.4.0 před nasazením. RFC 5280 definuje profily a ověřování certifikátů, RFC 6066 definuje signalizaci názvu serveru TLS, RFC 8446 definuje TLS 1.3, RFC 8555 definuje veřejné ACME a RFC 9525 definuje ověřování identity služby.