# Mga Sertipiko ng TLS sa Webship: Ang Naka-embed na ACME CA
Ang isang TLS na sertipiko ay gumagawa ng dalawang gawain: tinutulungan nito na i-encrypt ang isang koneksyon at sinasabi sa kliyente kung aling identidad ang kausap nito. Maaaring malakas ang encryption habang mali ang desisyon sa tiwala para sa audience. Iyon ang dahilan kung bakit ang awtomasyon ng sertipiko ay dapat magsimula sa isang tanong: sino ang dapat magtiwala sa site na ito?
Ang Webship 1.4.0 ay gumagawa ng pagpipiliang iyon nang independyente para sa bawat nakatakdang site. Ang isang pampublikong website ay maaaring gumamit ng browser-trusted ACME certificate, ang isang internal na serbisyo ay maaaring gumamit ng embedded private certificate authority ng Webship, at ang isang site na may umiiral nang PKI ay maaaring panatilihin ang operator-managed certificate files. Maaari silang lahat magbahagi ng isang Webship process nang hindi nagbabahagi ng isang pribadong key o isang trust boundary.
Apat na awtomatikong mode ng sertipiko, pinipili kada site
Ang field na certificate_mode ay kabilang sa bawat entry ng [[sites]]. Ito ay hindi isang pangkalahatang switch.
| Paraan | Pinagmulan ng tiwala | Pinakamainam na akma | Landas ng pagpapatunay | | --- | --- | --- | --- | | bawat_site | Pampublikong browser at mga tindahan ng tiwala sa operating system | Isang pampublikong site na may eksaktong hostname | Pampublikong ACME na may TLS-ALPN-01 | | fleet | Pampublikong browser at mga tindahan ng tiwala sa operating system | Malalaking set ng mga pangalan sa ikatlo at ikaapat na antas sa ilalim ng tahasang nakarehistrong mga domain | Pampublikong ACME na may DNS-01 at matatag na mga piraso ng sertipiko | | naka-embed | Isang pribadong Webship root na ini-install ng operator | Panloob na serbisyo, pinamamahalaang mga kagamitan, pribadong fleet, at mga test environment | Pagbibigay sa proseso; walang panlabas na hamon | | ibinahagi | Pampublikong browser at operating-system trust stores | Mga lumang deployment na sadyang gumagamit ng isang pampublikong multi-SAN group | Pampublikong ACME na may TLS-ALPN-01 |
Ang default ay per_site. Nagsusumite ito ng isang pampublikong sertipiko para sa eksaktong pangalan ng site. Ang fleet mode ay ang scalable na pampublikong opsyon para sa maraming malalim na subdomain. Ginagamit ng embedded mode ang pribadong in-process CA ng Webship. Ang shared mode ay nananatiling available para sa compatibility, ngunit hindi ito ang default.
Ang kumpletong sertipiko at susi sa ilalim ng [sites.tls] ay laging inuuna kaysa sa awtomatikong pag-isyu para sa site na iyon.
Ano ang ibig sabihin ng “embedded ACME CA”
Ang seksyon ng configuration ay pinangalanang [acme_ca], ngunit ang naka-embed na CA ay hindi isang pampubliko o network-accessible na serbisyo ng ACME. Hindi ito naglalantad ng anumang directory endpoint, hindi tumatanggap ng remote enrollment, hindi tumatawag ng registrar API, at hindi nagsasagawa ng proof-of-control challenge.
Sa halip, pinananatili ng Webship ang buong pribadong landas ng pagpapalabas sa isang proseso:
- Pinipili ng site ang certificate_mode = "embedded".
- Ina-load o nililikha ng Webship ang pribadong root na pagkakakilanlan sa na-configure na direktoryo ng estado.
- Ang Webship ay bumubuo ng bagong pribadong susi para sa site.
- Ang nakapaloob na root ay lumalagda ng isang leaf certificate para sa eksaktong pangalang iyon.
- Pinapatunayan ng Webship ang kumpletong pagkakakilanlan bago ito i-install sa live na TLS resolver.
- Ang sertipiko ay magagamit na sa bawat pinapahintulutang protocol para sa site na iyon.
Ang isang hamon sa network na estilo ng ACME ay magpapatunay lamang ng Webship sa kanyang sarili, kaya't ang nakapaloob na path ay sadyang walang network protocol. Ang seksyon na [acme_ca] ay pribadong estado ng PKI: tinutukoy nito kung saan matatagpuan ang root at gaano katagal mananatiling balido ang mga inilabas na leaf certificate.
I-configure ang isang naka-embed na sertipiko para sa isang site
Ito ang pinakamaliit na anyo para sa isang pribadong site:
~~~toml makinig = "0.0.0.0:443"
[tls] unknown_sni = "tanggihan"
[awtomatikong_tls] pinagana = totoo cache_dir = "/var/lib/webship/acme"
[acme_ca] state_dir = "/var/lib/webship/acme-ca" leaf_validity_days = 90
[[mga site]] domain = "service.internal.example" ugat = "/srv/service" certificate_mode = "nakalagay"
[mga.site.protocol] h1 = totoo h2 = totoo h3 = totoo ~~~
Ang pangunahing pagkakakilanlan ay nililikha nang tamad kapag unang kailangan ito ng isang nakapaloob na site. Pinananatili ng Webship ang pangunahing susi na may mga limitadong permiso sa state_dir. Ang pangunahing sertipiko ay may sampung taong bisa; ang bisa ng leaf ay kinokontrol ng leaf_validity_days.
Ituring ang parehong lugar ng imbakan bilang estado ng produksyon:
- Ang ACME cache ay naglalaman ng mga awtomatikong pinamamahalaang pagkakakilanlan ng site.
- Ang embedded-CA state directory ay naglalaman ng pribadong root identity.
- Kailangan ng account ng serbisyo ng access, ngunit hindi ng mga gumagamit ng aplikasyon.
- Dapat mapanatili ng mga backup ang pagiging kumpidensyal at ang mga pahintulot sa file.
- Dapat gumamit ng magkahiwalay na ugat at magkahiwalay na mga direktoryo ang produksyon, pag-unlad, at pagsubok.
Ang pagtanggal ng root directory ay hindi nag-"reset" ng TLS. Lumilikha ito ng bagong trust anchor. Tatanggihan ng mga kliyente na nagtitiwala sa lumang root ang mga sertipikong inilabas ng kapalit hanggang sa ma-update ang kanilang mga trust store.
Ang pribadong pagtitiwala ay sinasadya
Ang mga sertipiko mula sa naka-embed na CA ay hindi awtomatikong pinagkakatiwalaan ng mga pampublikong browser o operating system. Nagiging pinagkakatiwalaan lamang sila pagkatapos i-install ng operator ang na-export na Webship root certificate sa trust store ng kliyente.
Ginagawa nitong angkop ang embedded mode para sa:
- mga laptop at telepono na pinamamahalaan ng kumpanya na nakarehistro sa pamamagitan ng pamamahala ng aparato;
- panloob na trapiko mula serbisyo-patungo-serbisyo na may malinaw na CA bundle;
- mga pribadong kagamitan at kinokontrol na mga fleet sa gilid;
- mga kapaligiran ng pag-develop at pagsusuri na dapat magsanay ng totoong pag-uugali ng TLS;
- mga hindi konektadong network na hindi maaaring umasa sa isang pampublikong CA.
Ito ay hindi ang tamang mode para sa isang ordinaryong pampublikong website na ang mga bisita ay gumagamit ng hindi pinamamahalaang mga browser. Gamitin ang public per_site issuance para sa eksaktong pampublikong pangalan, fleet issuance para sa malalaking set ng pampublikong subdomain, shared lamang para sa sinadyang legacy na multi-SAN deployment, o mga manual na file mula sa isang Pinagkakatiwalaang PKI na.
Ipamahagi lamang ang root certificate sa mga kliyente. Huwag kailanman ipamahagi ang root private key. Ang pagmamay-ari ng key na iyon ay nagbibigay sa may hawak nito ng awtoridad na mag-isyu ng mga pagkakakilanlan na pinagtitiwalaan ng bawat nakarehistrong kliyente.
Maaaring sabay na umiiral ang pampubliko at pribadong mga sertipiko
Maaaring pagsamahin ng Webship 1.4.0 ang mga estratehiya ng sertipiko sa parehong tagapakinig:
~~~toml makinig = "0.0.0.0:443"
[tls] unknown_sni = "tanggihan"
[awtomatikong_tls] pinagana = totoo directory_url = "https://acme-v02.api.letsencrypt.org/directory" cache_dir = "/var/lib/webship/acme" mga_kontak = ["mailto:ops@example.com"] tanggapin_ang_mga_tuntunin_ng_serbisyo = true
[acme_ca] state_dir = "/var/lib/webship/acme-ca" leaf_validity_days = 90
[[mga site]] domain = "www.example.com" ugat = "/srv/public" certificate_mode = "bawat_site"
[[mga site]] domain = "control.internal.example" ugat = "/srv/control" certificate_mode = "nakalagay"
[[mga site]] domain = "payments.example.com" ugat = "/srv/payments"
[mga.site.tls] cert = "/etc/webship/payments-fullchain.pem" key = "/etc/webship/payments-private-key.pem" ~~~
Dito, ang www.example.com ay tumatanggap ng sarili nitong pampublikong sertipiko ng ACME. Ang control.internal.example ay tumatanggap ng pribadong sertipiko mula sa naka-embed na CA. Ang payments.example.com ay nananatili sa ilalim ng panlabas na PKI ng operator dahil inuuna ang mga tahasang file nito.
Ang pampublikong direktoryo ng ACME ay hindi pinapansin ng mga naka-embed na site. Ang naka-embed na ugat ay hindi kailanman pumipirma sa pampublikong site. Ang manu-manong site ay hindi kailanman tahimik na ini-enroll sa alinmang awtomatikong workflow.
Isang tagapag-resolba ng sertipiko para sa H1, H2, H3, at WebTransport
Ang pagpili ng sertipiko ay nagaganap sa panahon ng TLS handshake, bago pa man magkaroon ng HTTP request. Ginagamit ng Webship ang ClientHello server name upang piliin ang identidad ng site at pagkatapos ay pinapalitan ang protocol ng aplikasyon.
- Gumagamit ang HTTP/1.1 at HTTP/2 ng TLS sa ibabaw ng TCP.
- Gumagamit ang HTTP/3 at WebTransport ng TLS sa loob ng QUIC sa ibabaw ng UDP.
- Isang wastong pagkakakilanlan ng site ang maaaring magsilbi sa bawat pinapahintulutang protocol.
- Kinakailangan din ng HTTP/3 ang abot ng UDP; ginagamit ng H1 at H2 ang landas ng TCP.
- Maaaring i-advertise ng Alt-Svc ang H3 habang pinapanatili ang TCP fallback.
Gumagamit ang TCP, TLS, at QUIC ng parehong site-aware na modelo ng pagkakakilanlan. Ang eksaktong mga pangalan ay inuuna, ang pinakamahabang wastong wildcard ang nananalo kapag naka-configure ang mga wildcard na sertipiko, at ang hindi kilalang SNI na may pangalan ay maaaring tanggihan sa halip na tumanggap ng isang hindi kaugnay na default na sertipiko.
Gamitin ang unknown_sni = "reject" sa isang multi-site na tagapakinig kapag ang hindi kilalang hostname ay dapat mabigo nang sarado. Subukan ang mga kilalang pangalan, hindi kilalang pangalan, at ang iyong inaasahang no-SNI na pag-uugali bago ilunsad sa produksyon.
I-rotate ang mga naka-embed na pagkakakilanlan nang walang puwang sa paghahain
Ipinapakita ng Webship ang estado ng sertipiko at mga kontroladong pagbabago sa pamamagitan ng kanyang na-authenticate, loopback-bound na MCP server:
- Iniulat ng webship.tls.get_status ang aktibong tagapag-ayos ng sertipiko at estado ng pagpapalawig.
- Ang webship.tls.reissue_certificate ay agad na muling nag-iisyu ng isang awtomatikong pinamamahalaang site lamang kapag ang site na iyon ay gumagamit ng embedded mode.
- Ang webship.tls.reload ay nagre-reload ng estado ng sertipiko sa pamamagitan ng normal na ligtas na TLS na daan.
- Inaulat ng webship.acme_ca.status kung ang pribadong CA ay napili, ang direktoryo ng estado nito, haba ng buhay ng leaf, bilang ng pag-isyu, bilang ng pagrerebisa, at kamakailang halimbawa ng domain.
- Ang webship.sites.apply ay nagdadagdag o nagtatanggal ng mga site laban sa isang naka-pin na bersyon ng configuration.
Para sa isang naka-embed na muling isyu, ang Webship ay lumilikha at nag-validate ng kapalit bago ito ipasok sa serbisyo. Patuloy na naglilingkod ang kasalukuyang valid na pagkakakilanlan hanggang sa maging handa ang bagong pagkakakilanlan. Ang na-retire na pagkakakilanlan ay naitatala lamang pagkatapos ma-install ang kapalit.
Ang agarang operasyon ng muling pagpapalabas ay sinasadya na tinatanggihan ang pampublikong per_site na mga sertipiko. Ang pampublikong pag-renew ay dapat manatili sa loob ng pampublikong ACME lifecycle sa halip na malito sa pribadong nagpapatuloy na paglagda. Ang shared-mode membership ay naka-restart din na naka-freeze dahil ang pagbabago ng multi-SAN group ay muling bumubuo ng hangganan ng pagkakakilanlan.
Ang MCP ay isang pribilehiyadong control surface. Panatilihin ito sa loopback, kailangan ang TLS at isang malakas na bearer token, gumamit ng isang authenticated tunnel para sa remote na pamamahala, at suriin ang bawat pagbabago.
Mga hangganan ng kabiguan na mahalaga
Ang isang secure na sistema ng sertipiko ay dapat mabigo sa tamang direksyon.
- Ang bagong naka-configure na embedded na site ay hindi tumatanggap ng pagkakakilanlan ng ibang site habang nakabinbin ang pag-isyu.
- Ang hindi wastong kapalit ay hindi ini-install sa ibabaw ng gumaganang sertipiko.
- Ang malinaw na mga manwal na file ay pumipigil sa awtomatikong pagmamay-ari ng site na iyon.
- Ang hindi kilalang pangalan ng SNI ay maaaring tanggihan bago ang HTTP routing.
- Ang nakapaloob na CA ay nananatiling pribado at walang malayuang endpoint para sa pag-enroll.
- Ang mga pampubliko at naka-embed na pagkakakilanlan ay gumagamit ng magkahiwalay na mga path ng cache sa loob ng estado ng automatic-TLS.
Ang babala na ang naka-embed na CA ay hindi na-initialize ay nangangahulugang hindi ma-arm ng Webship ang naka-configure na state directory. Ayusin ang pagmamay-ari, mga permiso, pagpapanatili, o kakayahang mag-imbak bago magpadala ng trapiko sa apektadong site. Huwag laktawan ang error sa pamamagitan ng pagkopya ng root key ng ibang environment.
Tseklis ng produksyon
Bago paganahin ang naka-embed na mode:
- Tukuyin ang bawat populasyon ng kliyente na kailangang magtiwala sa site.
- Lumikha ng isang kontroladong proseso para sa pag-export at pag-install ng root certificate.
- Gumamit ng hiwalay na pangunahing estado para sa produksyon, pag-unlad, at pagsubok.
- Magpatuloy at protektahan ang naka-embed na CA state directory at awtomatikong TLS cache.
- Patakbuhin ang Webship sa ilalim ng isang dedikadong account ng serbisyo na may access lamang sa kinakailangang key material.
- Piliin ang certificate_mode sa bawat site na ang hangganan ng tiwala ay dapat maging malinaw.
- Itakda at subukan ang patakaran para sa unknown-SNI.
- Paganahin nang sinasadya ang H1, H2, at H3 at tiyaking suriin ang parehong TCP at UDP na mga landas.
- Magsanay ng muling pag-isyu, muling pagsisimula, backup, pagbawi, at pagpapatunay ng tiwala ng kliyente sa labas ng produksyon.
- Patakbuhin ang webship --check-config bago ilunsad, pagkatapos ay i-verify ang issuer, mga pangalan, bisa, chain, at mga napag-usapang protocol mula sa isang tunay na kliyente.
Piliin muna ang tiwala, susunod ang awtomasyon
Ang nakapaloob na CA ay nag-aalis ng pangangailangan para sa isang panlabas na serbisyo ng sertipiko para sa pribadong imprastruktura. Hindi nito ginagawang global na pinagkakatiwalaan ang pribadong root, at hindi rin nito inaalis ang mga responsibilidad ng operator sa PKI.
Awtomatikong ginagampanan ng Webship ang pagbuo ng susi, pagpirma, beripikasyon, pag-install, pag-ikot, at pagpili ng sertipiko sa buong protocol. Ang operator pa rin ang may pagmamay-ari ng root custody, pagrerehistro ng kliyente, paghihiwalay ng kapaligiran, backup, pagbawi, at ang desisyon kung gagamit ng pampubliko o pribadong landas ng tiwala.
Ang paghihiwalay na iyon ang tampok. Ang isang self-contained na server ay maaaring i-automate ang pribadong TLS nang hindi nagpapanggap na isang pampublikong CA—at ang mga pampublikong site ay maaari pa ring gumamit ng browser-trusted na per-site o fleet issuance sa parehong proseso.
Basahin ang versioned na Webship 1.4.0 documentation bago ang rollout. Inaakda ng RFC 5280 ang certificate profiles at validation, inaakda ng RFC 6066 ang TLS server-name signaling, inaakda ng RFC 8446 ang TLS 1.3, inaakda ng RFC 8555 ang public ACME, at inaakda ng RFC 9525 ang service identity verification.