TLS-tanúsítványok a Webshipben: A beágyazott ACME CA

# TLS-tanúsítványok a Webshipben: A beágyazott ACME CA

A TLS tanúsítvány két feladatot lát el: segít titkosítani a kapcsolatot és megmondja az ügyfélnek, hogy milyen identitással beszél. A titkosítás lehet erős, miközben a bizalmi döntés rossz a közönség számára. Ezért a tanúsítvány automatizálásának egy kérdéssel kell kezdődnie: kinek kell megbíznia ebben az oldalban?

A Webship 1.4.0 minden konfigurált webhely esetében önállóan hozza meg ezt a döntést. Egy nyilvános weboldal böngésző által megbízhatónak tartott ACME tanúsítványt használhat, egy belső szolgáltatás a Webship beágyazott privát tanúsítványkezelő hatóságát használhatja, és egy meglévő PKI-val rendelkező webhely megtarthatja az üzemeltető által kezelt tanúsítványfájlokat. Mindannyian megoszthatnak egy Webship folyamatot anélkül, hogy megosztanának egy privát kulcsot vagy egy megbízhatósági határvonalat.

Négy automatikus tanúsítvány mód, amelyet oldalanként lehet kiválasztani

A certificate_mode mező minden [[sites]] bejegyzéshez tartozik. Ez nem egy globális kapcsoló.

| Mód | Megbízható forrás | Legjobb illeszkedés | Ellenőrzési útvonal | | --- | --- | --- | --- | | per_site | Nyilvános böngésző- és operációs rendszer megbízhatósági tárolói | Egy nyilvános oldal egy pontos hosztnévvel | Nyilvános ACME TLS-ALPN-01-gyel | | flottilla | Nyilvános böngésző- és operációs rendszer megbízhatósági tárolók | Nagy készletek harmad- és negyedosztályú nevekből, explicit regisztrált domainek alatt | Nyilvános ACME DNS-01-gyel és stabil tanúsítvány-szeletekkel | | beágyazott | Egy privát Webship root, amelyet az üzemeltető telepített | Belső szolgáltatások, kezelt eszközök, privát flották és tesztkörnyezetek | Folyamatban lévő kibocsátás; nincs külső kihívás | | megosztott | Nyilvános böngésző- és operációs rendszer bizalmi tárak | Régi telepítések, amelyek szándékosan egy nyilvános multi-SAN csoportot használnak | Nyilvános ACME TLS-ALPN-01-gyel |

Az alapértelmezett a per_site. Ez egy nyilvános tanúsítványt rendel a webhely pontos nevéhez. A Fleet mód a skálázható nyilvános lehetőség sok mély aldomainhez. Beágyazott módban a Webship privát, folyamatban lévő CA-ját használja. A Shared mód továbbra is elérhető a kompatibilitás érdekében, de nem ez az alapértelmezett.

A teljes tanúsítvány és kulcs a [sites.tls] alatt mindig elsőbbséget élvez az adott oldal automatikus kibocsátásával szemben.

Mit jelent az „beágyazott ACME CA”

A konfigurációs szakasz neve [acme_ca], de a beágyazott CA nem nyilvános vagy hálózaton elérhető ACME szolgáltatás. Nem tesz közzé könyvtár végpontot, nem fogad távoli regisztrációt, nem hívja a regisztrátor API-ját, és nem végez semmilyen ellenőrzési igazolásos kihívást.

Ehelyett a Webship az egész privát kibocsátási folyamatot egyetlen folyamatban tartja:

1. Az oldal a certificate_mode = "embedded" beállítást választja.
2. A Webship betölti vagy létrehozza a privát gyökérazonosságot a konfigurált állapotkönyvtárban.
3. A Webship új privát kulcsot generál a webhelyhez.
4. A beágyazott gyökér aláír egy tanúsítványt az adott névhez.
5. A Webship érvényesíti a befejezett azonosítót, mielőtt telepítené azt az élő TLS-felbontóba.
6. A tanúsítvány ezután elérhető az adott webhely minden engedélyezett protokollja számára.

Egy ACME-stílusú hálózati kihívás csak a Webship számára bizonyítaná magát, ezért a beágyazott útvonal szándékosan nem tartalmaz hálózati protokollt. Az [acme_ca] szakasz privát PKI állapot: meghatározza, hol található a gyökér, és mennyi ideig érvényesek a kiadott levél tanúsítványok.

Állítson be egy beágyazott tanúsítványt egy webhelyhez

Ez a minimális forma egy privát webhelyhez:

~~~toml listen = "0.0.0.0:443"

[tls] unknown_sni = "elutasít"

[automatikus_tls] engedélyezve = igaz cache_dir = "/var/lib/webship/acme"

[acme_ca] state_dir = "/var/lib/webship/acme-ca" levél_érvényességi_napok = 90

[[helyek]] domain = "service.internal.example" root = "/srv/service" certificate_mode = "beágyazott"

[helyek.protokollok] h1 = igaz h2 = igaz h3 = igaz ~~~

A gyökérazonosság lustán jön létre, amikor egy beágyazott oldal először igényli. A Webship a gyökérkulcsot korlátozó engedélyekkel tárolja a state_dir-ban. A gyökértanúsítvány tíz éves élettartamú; a levél élettartamát a leaf_validity_days szabályozza.

Mindkét tárolóhelyet kezeljük gyártási állapotként:

• Az ACME gyorsítótár automatikusan kezelt webhelyazonosságokat tárol.
• A beágyazott CA állapotkönyvtára tartalmazza a privát gyökérazonosságot.
• A szolgáltatási fióknak szüksége van hozzáférésre, de az alkalmazás felhasználóinak nem.
• A biztonsági mentéseknek meg kell őrizniük a bizalmasságot és a fájlengedélyeket.
• A gyártás, a fejlesztés és a tesztelés külön gyökérkönyvtárakat és külön mappákat kell, hogy használjon.

A gyökérkönyvtár törlése nem „állítja vissza a TLS-t”. Új megbízhatósági horgonyt hoz létre. Azok az ügyfelek, amelyek az régi gyökeret bízzák, elutasítják a cserével kiadott tanúsítványokat, amíg a megbízhatósági tárolóik nincs frissítve.

A magánbizalom szándékos

A beágyazott CA által kibocsátott tanúsítványokat a nyilvános böngészők vagy operációs rendszerek nem bízzák meg automatikusan. Csak ezután válnak megbízhatóvá, miután az üzemeltető telepítette az exportált Webship gyökér tanúsítványt az ügyfél megbízhatósági tárolójába.

Ez az beágyazott módot alkalmassá teszi a következőkre:

• vállalat által kezelt laptopok és telefonok, amelyek eszközkezelésen keresztül vannak regisztrálva;
• belső szolgáltatás-kiszolgáló közötti forgalom egy explicit CA-csomaggal;
• magán készülékek és szabályozott peremhálózati flották;
• fejlesztési és tesztkörnyezetek, amelyeknek a valódi TLS viselkedést kell gyakorolniuk;
• szétkapcsolt hálózatok, amelyek nem támaszkodhatnak nyilvános CA-ra.

Ez nem a megfelelő mód egy hétköznapi nyilvános weboldal számára, amelynek látogatói nem kezelt böngészőket használnak. Használjon nyilvános per_site kibocsátást egy pontos nyilvános névhez, fleet kibocsátást nagy nyilvános aldomain készletekhez, csak megosztottat szándékos régi több-SAN telepítéshez, vagy manuális fájlokat egy már megbízható PKI-ból.

Csak a gyökértanúsítványt ossza szét az ügyfelek között. Soha ne ossza szét a gyökér privát kulcsot. Ennek a kulcsnak a birtoklása annak a személynek a hatalmát adja meg, hogy olyan azonosítókat bocsásson ki, amelyeket minden beiratkozott ügyfél megbízhatónak tekint.

A nyilvános és a privát tanúsítványok együtt is létezhetnek

A Webship 1.4.0 képes keverni a tanúsítványstratégiákat ugyanazon a hallgatón:

~~~toml listen = "0.0.0.0:443"

[tls] unknown_sni = "elutasít"

[automatikus_tls] engedélyezve = igaz directory_url = "https://acme-v02.api.letsencrypt.org/directory" cache_dir = "/var/lib/webship/acme" contacts = ["mailto:ops@example.com"] feldolgozni_a_szolgáltatási_feltételeket = igaz

[acme_ca] state_dir = "/var/lib/webship/acme-ca" levél_érvényességi_napok = 90

[[helyek]] domain = "www.example.com" root = "/srv/public" certificate_mode = "helyszínenként"

[[helyek]] domain = "control.internal.example" root = "/srv/control" certificate_mode = "beágyazott"

[[helyek]] domain = "payments.example.com" root = "/srv/payments"

[helyek.tls] cert = "/etc/webship/payments-fullchain.pem" kulcs = "/etc/webship/payments-private-key.pem" ~~~

Itt a www.example.com megkapja a saját nyilvános ACME tanúsítványát. A control.internal.example egy privát tanúsítványt kap a beágyazott CA-tól. A payments.example.com továbbra is az üzemeltető külső PKI-je alatt marad, mert a kifejezett fájljai elsőbbséget élveznek.

A nyilvános ACME könyvtárat a beágyazott oldalak figyelmen kívül hagyják. A beágyazott gyökér soha nem írja alá a nyilvános oldalt. A kézi oldal soha nem kerül csendben egyik automatikus munkafolyamatba sem.

Egy tanúsítványfeloldó az H1, H2, H3 és a WebTransport számára

A tanúsítvány kiválasztása a TLS kézfogás során történik, mielőtt egy HTTP kérés létezne. A Webship a ClientHello szervernevet használja az oldalazonosság kiválasztására, majd tárgyalja az alkalmazásprotokollt.

• A HTTP/1.1 és a HTTP/2 TLS-t használnak TCP fölött.
• A HTTP/3 és a WebTransport a TLS-t használja a QUIC-en belül, UDP-n keresztül.
• Egy érvényes webhelyazonosság szolgálhat minden engedélyezett protokollhoz.
• A HTTP/3 szintén megköveteli az UDP elérhetőséget; a H1 és H2 a TCP útvonalat használja.
• Az Alt-Svc hirdetheti a H3-at, miközben megőrzi a TCP visszaesést.

A TCP, a TLS és a QUIC ugyanazt a webhelyekhez kötött identitásmodellt használják. A pontos nevek elsőbbséget élveznek, a leghosszabb érvényes helyettesítő karakter (wildcard) érvényes, ha helyettesítő karakteres tanúsítványok vannak konfigurálva, és az ismeretlen nevű SNI elutasítható ahelyett, hogy egy nem kapcsolódó alapértelmezett tanúsítványt kapna.

Használja az unknown_sni = "reject" beállítást egy többhelyszínes hallgatónál, amikor egy ismeretlen hosztnévnek zártnak kell lennie. Tesztelje a felismert neveket, a fel nem ismert neveket, és a várt no-SNI viselkedést a termelésbe történő bevezetés előtt.

Forgassa el a beágyazott identitásokat megszakítás nélkül

A Webship a tanúsítvány állapotát és a vezérelt módosításokat a hitelesített, loopback-hez kötött MCP szerverén keresztül teszi elérhetővé:

• A webship.tls.get_status jelentést ad az aktív tanúsítványfeloldóról és a megújítás állapotáról.
• A webship.tls.reissue_certificate az automatikusan kezelt webhelyet azonnal újra kibocsátja, csak akkor, ha az a webhely beágyazott módban van.
• A webship.tls.reload a tanúsítvány állapotát a normál, védett TLS útvonalon keresztül tölti újra.
• A webship.acme_ca.status jelzi, hogy a privát CA ki van-e választva, annak állapotkönyvtárát, a levél élettartamát, kibocsátási számát, visszavonási számát és a legutóbbi domain mintát.
• A webship.sites.apply hozzáad vagy eltávolít oldalakat egy rögzített konfigurációs verzióval szemben.

Beágyazott újra kiadás esetén a Webship létrehozza és érvényesíti a cserét, mielőtt azt szolgáltatásba helyezné. A jelenlegi érvényes azonosító továbbra is szolgál, amíg az új azonosító készen áll. A nyugdíjazott azonosítót csak a csere telepítése után rögzítik.

Az azonnali újrakibocsátási művelet szándékosan elutasítja a nyilvános per_site tanúsítványokat. A nyilvános megújításnak a nyilvános ACME életcikluson belül kell maradnia, ahelyett, hogy összetévesztenénk a privát folyamatban lévő aláírással. A megosztott üzemmódú tagság is újraindítás-mentesített, mivel egy több-SAN csoport megváltoztatása újraépíti az identitáshatárt.

Az MCP egy privilegizált vezérlőfelület. Tartsd loopbacken, igényelj TLS-t és erős hordozótokent, használj hitelesített tunnelt távoli adminisztrációhoz, és auditálj minden változtatást.

Fontos hibahatárok

Egy biztonságos tanúsítványrendszernek a helyes irányba kell meghibásodnia.

• Egy újonnan konfigurált beágyazott webhely nem kapja meg egy másik webhely azonosítóját, amíg a kibocsátás folyamatban van.
• Egy érvénytelen csere nem kerül telepítésre egy működő tanúsítvány fölé.
• A kifejezett kézi fájlok megakadályozzák a webhely automatikus tulajdonjogát.
• Az ismeretlen nevű SNI elutasítható az HTTP-útválasztás előtt.
• A beágyazott CA privát marad, és nincs távoli regisztrációs végpontja.
• A nyilvános és beágyazott identitások külön gyorsítótár-útvonalakat használnak az automatikus TLS állapotán belül.

Az a figyelmeztetés, hogy a beágyazott CA nincs inicializálva, azt jelenti, hogy a Webship nem tudta aktiválni a konfigurált állapotkönyvtárat. Javítsa a tulajdonjogot, a jogosultságokat, a perzisztenciát vagy a tárhely elérhetőségét, mielőtt forgalmat küldene az érintett oldalra. Ne próbálja meg kijátszani a hibát egy másik környezet gyökérkulcsának másolásával.

Gyártási ellenőrzőlista

Beágyazott mód engedélyezése előtt:

1. Azonosítsa minden ügyfélcsoportot, amelynek bizalmat kell szavaznia az oldalnak.
2. Hozzon létre egy szabályozott folyamatot a gyökértanúsítvány exportálásához és telepítéséhez.
3. Használjon külön gyökérállapotot a termeléshez, a fejlesztéshez és a teszteléshez.
4. Őrizze meg és védje a beágyazott CA állapotkönyvtárát és az automatikus TLS gyorsítótárat.
5. Futtassa a Webshipet egy dedikált szolgáltatási fiók alatt, amely csak a szükséges kulcsmateriálhoz fér hozzá.
6. Válassza ki a certificate_mode-t minden olyan webhelyen, ahol a bizalmi határ explicitnek kell lennie.
7. Állítsa be és tesztelje az ismeretlen SNI házirendjét.
8. Kapcsold be szándékosan a H1, H2 és H3-at, és ellenőrizd mind a TCP, mind az UDP útvonalakat.
9. Gyakorlat a kiadás újraindítására, újraindítására, biztonsági mentésre, visszaállításra és ügyfél-megbízhatóság ellenőrzésére a termeléstől elkülönítve.
10. Futtassa a webship --check-config parancsot a kockázatmentes bevezetés előtt, majd ellenőrizze az kibocsátót, neveket, érvényességet, láncot és a tárgyalt protokollokat egy valódi kliensből.

Először a bizalmat válassza, másodszor az automatizálást

A beágyazott CA megszünteti a külső tanúsítvány-szolgáltatás iránti függőséget a privát infrastruktúrában. Nem teszi a privát gyökér tanúsítványt globálisan megbízhatóvá, és nem szünteti meg az üzemeltető PKI felelősségeit.

A Webship automatizálja a kulcsgenerálást, aláírást, érvényesítést, telepítést, forgatást és a protokollszintű tanúsítványkiválasztást. Az üzemeltető továbbra is birtokolja a gyökérfelügyeletet, az ügyfélregisztrációt, a környezetek elkülönítését, a biztonsági mentést, a helyreállítást, valamint a döntést arról, hogy nyilvános vagy privát megbízhatósági útvonalat használjon.

Ez a szeparáció a jellemző. Egy önálló szerver képes automatizálni a privát TLS-t anélkül, hogy nyilvános CA-nak tűnne — és a nyilvános webhelyek még mindig használhatják a böngésző által megbízható per-site vagy flottaszintű kiadást ugyanabban a folyamatban.

Olvassa el a verziózott Webship 1.4.0 dokumentációt a bevezetés előtt. Az RFC 5280 határozza meg a tanúsítványprofilokat és érvényesítést, az RFC 6066 a TLS szervernév-jelzést, az RFC 8446 a TLS 1.3-at, az RFC 8555 a nyilvános ACME-t, és az RFC 9525 a szolgáltatásazonosító ellenőrzését.