Certificate TLS în Webship: CA ACME Încorporat

# Certificate TLS în Webship: CA ACME Încorporat

Un certificat TLS are două roluri: ajută la criptarea unei conexiuni și îi spune clientului cu ce identitate vorbește. Criptarea poate fi puternică în timp ce decizia de încredere este greșită pentru public. De aceea, automatizarea certificatelor trebuie să înceapă cu o întrebare: cine trebuie să aibă încredere în acest site?

Webship 1.4.0 face acea alegere în mod independent pentru fiecare site configurat. Un site public poate folosi un certificat ACME de încredere pentru browser, un serviciu intern poate folosi autoritatea de certificare privată încorporată a Webship, iar un site cu PKI existent poate păstra fișierele de certificat administrate de operator. Toate acestea pot împărți un singur proces Webship fără a partaja o cheie privată sau o limită de încredere.

Patru moduri automate de certificate, selectate pe site

Câmpul certificate_mode aparține fiecărei intrări [[sites]]. Nu este un comutator global.

| Mod | Sursă de încredere | Cea mai potrivită | Cale de validare | | --- | --- | --- | --- | | per_site | Magazine publice de încredere ale browserului și sistemului de operare | Un site public cu un nume de gazdă exact | ACME public cu TLS-ALPN-01 | | flotă | Magazine de încredere publice pentru browser și sistem de operare | Seturi mari de nume de nivel trei și patru sub domenii înregistrate explicit | ACME public cu DNS-01 și fragmente de certificate stabile | | integrat | Un root Webship privat instalat de operator | Servicii interne, dispozitive gestionate, flote private și medii de test | Emitere în curs de desfășurare; fără provocare externă | | partajat | Depozite de încredere publice ale browserului și sistemului de operare | Implementări vechi care folosesc intenționat un grup public multi-SAN | ACME public cu TLS-ALPN-01 |

Implicit este per_site. Acesta comandă un certificat public pentru numele exact al site-ului. Modul Fleet este opțiunea publică scalabilă pentru multe subdomenii adânci. Modul Embedded utilizează CA-ul privat în proces al Webship. Modul Shared rămâne disponibil pentru compatibilitate, dar nu este implicit.

Un certificat și o cheie complete sub [sites.tls] au întotdeauna prioritate față de emiterea automată pentru acel site.

Ce înseamnă „ACME CA integrat”

Secțiunea de configurare se numește [acme_ca], dar CA încorporat nu este un serviciu ACME public sau accesibil prin rețea. Nu expune niciun punct final de director, nu acceptă înregistrare de la distanță, nu apelează API-ul registrarului și nu efectuează nicio provocare de dovadă a controlului.

În schimb, Webship păstrează întregul traseu de emisiune privată într-un singur proces:

1. Site-ul selectează certificate_mode = "embedded".
2. Webship încarcă sau creează identitatea rădăcină privată în directorul de stare configurat.
3. Webship generează o nouă cheie privată pentru site.
4. Semnele radacinii încorporate un certificat de frunză pentru acel nume exact.
5. Webship validează identitatea completă înainte de a o instala în rezolvatorul TLS activ.
6. Certificatul este apoi disponibil pentru fiecare protocol activat pentru acel site.

O provocare de rețea în stil ACME ar demonstra doar Webship lui însuși, astfel că calea încorporată nu are intenționat niciun protocol de rețea. Secțiunea [acme_ca] este starea privată PKI: definește unde se află rădăcina și cât timp rămân valabile certificatele de tip leaf emise.

Configurează un certificat încorporat pentru un site

Aceasta este forma minimă pentru un site privat:

~~~toml ascultă = "0.0.0.0:443"

[tls] unknown_sni = "respinge"

[tls_automat] activat = adevărat cache_dir = "/var/lib/webship/acme"

[acme_ca] state_dir = "/var/lib/webship/acme-ca" zile_validitate_frunza = 90

[[site-uri]] domeniu = "service.internal.example" root = "/srv/service" certificate_mode = "înglobat"

[site.protocoale] h1 = adevărat h2 = adevărat h3 = adevărat ~~~

Identitatea rădăcină este creată leneș atunci când un site încorporat are nevoie de ea pentru prima dată. Webship păstrează cheia rădăcină cu permisiuni restrictive în state_dir. Certificatul rădăcină are o durată de viață de zece ani; durata de viață a frunzei este controlată de leaf_validity_days.

Tratați ambele locații de stocare ca stare de producție:

• Cache-ul ACME deține identități de site gestionate automat.
• Directorul de stare embedded-CA conține identitatea rădăcinii private.
• Contul de serviciu are nevoie de acces, dar utilizatorii aplicației nu au.
• Backup-urile trebuie să păstreze confidențialitatea și permisiunile fișierelor.
• Producția, dezvoltarea și testarea ar trebui să utilizeze rădăcini separate și directoare separate.

Ștergerea directorului rădăcină nu „resetează TLS.” Creează un nou punct de încredere. Clienții care au încredere în vechea rădăcină vor respinge certificatele emise de înlocuitor până când magazinele lor de încredere sunt actualizate.

Încrederea privată este intenționată

Certificatele de la CA încorporată nu sunt automat de încredere în browserele publice sau în sistemele de operare. Ele devin de încredere doar după ce operatorul instalează certificatul rădăcină Webship exportat în magazinul de încredere al clientului.

Asta face ca modul încorporat să fie potrivit pentru:

• laptopuri și telefoane gestionate de companie înscrise prin managementul dispozitivului;
• trafic intern între servicii cu un pachet CA explicit;
• aplicații private și flote de margine controlate;
• medii de dezvoltare și testare care trebuie să exercite comportamentul real TLS;
• rețele deconectate care nu se pot baza pe o autoritate de certificare publică.

Nu este modul potrivit pentru un site web public obișnuit ale cărui vizitatori folosesc browsere nesupravegheate. Folosiți emiterea publică per_site pentru un nume public exact, emiterea pe flotă pentru seturi mari de subdomenii publice, shared doar pentru o implementare deliberată moștenită multi-SAN, sau fișiere manuale dintr-un PKI deja de încredere.

Distribuiți numai certificatul rădăcină către clienți. Nu distribuiți niciodată cheia privată a rădăcinii. Deținerea acelei chei îi conferă posesorului autoritatea de a emite identități de încredere pentru fiecare client înregistrat.

Certificatele publice și private pot coexista

Webship 1.4.0 poate combina strategiile de certificate pe același ascultător:

~~~toml ascultă = "0.0.0.0:443"

[tls] unknown_sni = "respinge"

[tls_automat] activat = adevărat directory_url = "https://acme-v02.api.letsencrypt.org/directory" cache_dir = "/var/lib/webship/acme" contacts = ["mailto:ops@example.com"] accepta_termenii_de_serviciu = adevărat

[acme_ca] state_dir = "/var/lib/webship/acme-ca" zile_validitate_frunza = 90

[[site-uri]] domeniu = "www.example.com" root = "/srv/public" certificate_mode = "per_site"

[[site-uri]] domeniu = "control.internal.example" root = "/srv/control" certificate_mode = "înglobat"

[[site-uri]] domeniu = "payments.example.com" root = "/srv/plăți"

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

Aici, www.example.com primește propriul certificat public ACME. control.internal.example primește un certificat privat de la CA încorporată. payments.example.com rămâne sub PKI-ul extern al operatorului deoarece fișierele sale explicite au prioritate.

Directorul public ACME este ignorat de site-urile încorporate. Rădăcina încorporată nu semnează niciodată site-ul public. Site-ul manual nu este niciodată înscris silențios în niciunul dintre fluxurile de lucru automate.

Un rezolvator de certificate pentru H1, H2, H3 și WebTransport

Selectarea certificatului se întâmplă în timpul strângerii de mână TLS, înainte ca o cerere HTTP să existe. Webship folosește numele serverului din ClientHello pentru a selecta identitatea site-ului și apoi negociază protocolul aplicației.

• HTTP/1.1 și HTTP/2 folosesc TLS peste TCP.
• HTTP/3 și WebTransport folosesc TLS în interiorul QUIC peste UDP.
• O identitate de site validă poate servi fiecărui protocol activat.
• HTTP/3 necesită de asemenea accesibilitate UDP; H1 și H2 folosesc calea TCP.
• Alt-Svc poate să promoveze H3 în timp ce păstrează o revenire la TCP.

TCP, TLS și QUIC folosesc același model de identitate conștient de site. Numele exacte au prioritate, cel mai lung wildcard valid câștigă acolo unde sunt configurate certificate wildcard, iar SNI cu nume necunoscut poate fi respins în loc să primească un certificat implicit nerelevant.

Utilizați unknown_sni = "reject" pe un ascultător multi-site atunci când un nume de gazdă nerecunoscut trebuie să eșueze închis. Testați numele recunoscute, numele nerecunoscute și comportamentul așteptat fără SNI înainte de implementarea în producție.

Rotește identitățile încorporate fără o perioadă de întrerupere

Webship expune starea certificatului și mutațiile controlate prin intermediul serverului său MCP autenticat, legat de loopback:

• webship.tls.get_status raportează rezolvatorul de certificate activ și starea reînnoirii.
• webship.tls.reissue_certificate reemite imediat un site gestionat automat doar atunci când acel site folosește modul încorporat.
• webship.tls.reload reîncarcă starea certificatului prin calea TLS protejată normal.
• webship.acme_ca.status raportează dacă CA-ul privat este selectat, directorul său de stare, durata de viață a certificatului final, numărul de emisii, numărul de revocări și un eșantion recent de domenii.
• webship.sites.apply adaugă sau elimină site-uri în raport cu o versiune de configurație fixată.

Pentru o reemitere integrată, Webship creează și validează înlocuirea înainte de a o introduce în serviciu. Identitatea validă curentă continuă să funcționeze până când noua identitate este gata. Identitatea retrasă este înregistrată numai după ce înlocuirea este instalată.

Operațiunea de reemisiune imediată respinge intenționat certificatele publice per_site. Reînnoirea publică trebuie să rămână în cadrul ciclului de viață ACME public, mai degrabă decât să fie confundată cu semnarea privată în curs de procesare. Participarea în modul partajat este, de asemenea, blocată la repornire, deoarece schimbarea unui grup multi-SAN reconstruiește limita de identitate.

MCP este o suprafață de control privilegiată. Păstreaz-o în modul loopback, cere TLS și un token de acces puternic, folosește un tunel autentificat pentru administrarea la distanță și auditează fiecare modificare.

Granițele eșecului care contează

Un sistem de certificate securizat trebuie să eșueze în direcția corectă.

• Un site încorporat configurat recent nu primește identitatea altui site în timp ce emiterea este în așteptare.
• O înlocuire nevalidă nu este instalată peste un certificat funcțional.
• Fișierele manuale explicite împiedică deținerea automată a acelui site.
• SNI cu nume necunoscut poate fi respins înainte de rutarea HTTP.
• CA-ul încorporat rămâne privat și nu are un punct final de înscriere la distanță.
• Identitățile publice și încorporate folosesc căi de cache separate în interiorul stării TLS automate.

Un avertisment că CA-ul încorporat nu este inițializat înseamnă că Webship nu a putut activa directorul de stare configurat. Remediați proprietatea, permisiunile, persistența sau disponibilitatea stocării înainte de a trimite trafic către site-ul afectat. Nu încercați să ocoliți eroarea prin copierea cheii rădăcină a altei medii.

Lista de verificare a producției

Înainte de a activa modul încorporat:

1. Identificați fiecare populație de clienți care trebuie să aibă încredere în site.
2. Creați un proces controlat pentru exportarea și instalarea certificatului rădăcină.
3. Folosește un stat root separat pentru producție, dezvoltare și testare.
4. Persistă și protejează directorul de stare embedded-CA și cache-ul automatic-TLS.
5. Rulați Webship sub un cont de serviciu dedicat cu acces doar la materialul cheie necesar.
6. Selectați certificate_mode pe fiecare site al cărui frontieră de încredere trebuie să fie explicită.
7. Setați și testați politica SNI necunoscut.
8. Activează H1, H2 și H3 în mod deliberat și verifică atât căile TCP cât și UDP.
9. Exersați reemiterea, repornirea, backup-ul, restaurarea și validarea încrederii clientului în afara producției.
10. Rulează webship --check-config înainte de lansare, apoi verifică emitentul, numele, valabilitatea, lanțul și protocoalele negociate de la un client real.

Alege mai întâi încrederea, automatizarea pe urmă

CA-ul încorporat elimină o dependență de serviciu de certificate extern pentru infrastructura privată. Nu face ca o rădăcină privată să fie acceptată la nivel global și nu elimină responsabilitățile PKI ale operatorului.

Webship automatizează generarea cheilor, semnarea, validarea, instalarea, rotația și selecția certificatelor la nivel de protocol. Operatorul deține în continuare custodia rădăcină, înscrierea clienților, separarea mediului, backup-ul, recuperarea și decizia de a utiliza o cale de încredere publică sau privată.

Acea separare este caracteristica. Un server independent poate automatiza TLS privat fără a pretinde că este o CA publică—și site-urile publice pot folosi în continuare emiterea pe site sau pe grup de site-uri de încredere în browser în același proces.

Citește documentația versionată Webship 1.4.0 înainte de implementare. RFC 5280 definește profilurile și validarea certificatelor, RFC 6066 definește semnalizarea numelui serverului TLS, RFC 8446 definește TLS 1.3, RFC 8555 definește ACME public și RFC 9525 definește verificarea identității serviciului.