TLS-certificaten in Webship: de ingesloten ACME CA

# TLS-certificaten in Webship: de ingesloten ACME CA

Een TLS-certificaat vervult twee taken: het helpt een verbinding te versleutelen en vertelt de cliënt met welke identiteit het praat. Versleuteling kan sterk zijn terwijl de vertrouwensbeslissing voor het publiek verkeerd is. Daarom moet certificeringsautomatisering beginnen met één vraag: wie moet deze site vertrouwen?

Webship 1.4.0 maakt die keuze onafhankelijk voor elke geconfigureerde site. Een openbare website kan een door de browser vertrouwd ACME-certificaat gebruiken, een interne dienst kan de ingebouwde particuliere certificaatautoriteit van Webship gebruiken, en een site met een bestaande PKI kan door de operator beheerde certificaatbestanden behouden. Ze kunnen allemaal één Webship-proces delen zonder één privésleutel of één vertrouwensgrens te delen.

Vier automatische certificaatmodi, per site te selecteren

Het certificate_mode-veld behoort tot elke [[sites]]-vermelding. Het is geen globale schakelaar.

| Modus | Vertrouwde bron | Beste pasvorm | Validatiepad | | --- | --- | --- | --- | | per_site | Openbare browser- en besturingssysteem-truststores | Een openbare site met één exacte hostnaam | Openbare ACME met TLS-ALPN-01 | | vloot | Openbare browser- en besturingssysteem-truststores | Grote sets van derde- en vierde-niveau namen onder expliciet geregistreerde domeinen | Openbare ACME met DNS-01 en stabiele certificaat-shards | | ingebed | Een privaat Webship-root geïnstalleerd door de operator | Interne diensten, beheerde apparaten, privévloten en testomgevingen | Uitgifte in het proces; geen externe uitdaging | | gedeeld | Publieke browser- en besturingssysteemvertrouwensopslag | Legacy-implementaties die opzettelijk één publieke multi-SAN-groep gebruiken | Publieke ACME met TLS-ALPN-01 |

De standaard is per_site. Het bestelt één openbaar certificaat voor de exacte naam van de site. Fleet-modus is de schaalbare openbare optie voor veel diepe subdomeinen. Embedded-modus gebruikt de privé in-process CA van Webship. Gedeelde modus blijft beschikbaar voor compatibiliteit, maar het is niet de standaard.

Een volledig certificaat en sleutel onder [sites.tls] hebben altijd voorrang boven automatische uitgifte voor die site.

Wat "embedded ACME CA" betekent

De configuratiesectie heet [acme_ca], maar de ingebedde CA is geen openbare of netwerktoegankelijke ACME-service. Het biedt geen directory-eindpunt, accepteert geen externe registratie, roept geen registrar-API aan en voert geen bewijs-van-controle-uitdaging uit.

In plaats daarvan houdt Webship het hele privé-uitgiftepayload in één proces:

1. De site selecteert certificate_mode = "embedded".
2. Webship laadt of maakt de private root-identiteit in de geconfigureerde staatmap.
3. Webship genereert een nieuwe privésleutel voor de site.
4. De ingebedde root ondertekent een leaf-certificaat voor die exacte naam.
5. Webship valideert de voltooide identiteit voordat deze wordt geïnstalleerd in de live TLS-resolver.
6. Het certificaat is dan beschikbaar voor elk ingeschakeld protocol voor die site.

Een ACME-stijl netwerkuitdaging zou Webship alleen aan zichzelf bewijzen, dus het ingebedde pad heeft opzettelijk geen netwerkprotocol. De [acme_ca]-sectie is privé PKI-toestand: het definieert waar de root zich bevindt en hoe lang uitgegeven leaf-certificaten geldig blijven.

Stel een ingebouwd certificaat in voor één site

Dit is de minimale vorm voor een privésite:

~~~toml luister = "0.0.0.0:443"

[tls] unknown_sni = "afwijzen"

[automatische_tls] ingeschakeld = waar cache_dir = "/var/lib/webship/acme"

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

[[sites]] domein = "service.internal.example" root = "/srv/service" certificate_mode = "ingebed"

[sites.protocols] h1 = waar h2 = waar h3 = waar ~~~

De rootidentiteit wordt lazy aangemaakt wanneer een ingebedde site deze voor het eerst nodig heeft. Webship bewaart de rootkey met beperkende permissies in state_dir. Het rootcertificaat heeft een levensduur van tien jaar; de levensduur van een leaf wordt bepaald door leaf_validity_days.

Behandel beide opslaglocaties als productiestand:

• De ACME-cache bevat automatisch beheerde site-identiteiten.
• De embedded-CA statusmap bevat de privé root-identiteit.
• Het serviceaccount heeft toegang nodig, maar applicatiegebruikers niet.
• Back-ups moeten vertrouwelijkheid en bestandsrechten behouden.
• Productie, ontwikkeling en testen moeten aparte roots en aparte mappen gebruiken.

Het verwijderen van de rootdirectory 'reset' TLS niet. Het creëert een nieuw trustanker. Clients die de oude root vertrouwen, zullen certificaten die door de vervanger zijn uitgegeven afwijzen totdat hun truststores zijn bijgewerkt.

Privétrust is opzettelijk

Certificaten van de ingebedde CA worden niet automatisch vertrouwd door openbare browsers of besturingssystemen. Ze worden pas vertrouwd nadat de operator het geëxporteerde Webship-rootcertificaat in de vertrouwensopslag van de cliënt heeft geïnstalleerd.

Dat maakt de embedded-modus geschikt voor:

• door het bedrijf beheerde laptops en telefoons die via apparaatbeheer zijn geregistreerd;
• intern verkeer tussen services met een expliciete CA-bundel;
• privé-apparaten en gecontroleerde randvloten;
• ontwikkelings- en testomgevingen die echt TLS-gedrag moeten uitvoeren;
• losgekoppelde netwerken die niet op een openbare CA kunnen vertrouwen.

Het is niet de juiste modus voor een gewone publieke website waarvan de bezoekers ongebruikte browsers gebruiken. Gebruik openbare per_site-uitgifte voor een exacte openbare naam, fleet-uitgifte voor grote openbare subdomeinsets, alleen gedeeld voor een opzettelijke legacy multi-SAN-implementatie, of handmatige bestanden van een reeds vertrouwde PKI.

Distribueer alleen het rootcertificaat aan cliënten. Verspreid nooit de root private key. Het bezit van die sleutel geeft de houder de bevoegdheid om identiteiten uit te geven die door elke ingeschreven cliënt worden vertrouwd.

Openbare en private certificaten kunnen naast elkaar bestaan

Webship 1.4.0 kan certificaatstrategieën op dezelfde luisteraar mixen:

~~~toml luister = "0.0.0.0:443"

[tls] unknown_sni = "weiger"

[automatische_tls] ingeschakeld = waar directory_url = "https://acme-v02.api.letsencrypt.org/directory" cache_dir = "/var/lib/webship/acme" contacts = ["mailto:ops@example.com"] accepteer_voorwaarden_van_dienst = waar

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

[[sites]] domein = "www.example.com" root = "/srv/public" certificate_mode = "per_site"

[[sites]] domein = "control.internal.example" root = "/srv/control" certificate_mode = "ingebed"

[[sites]] domein = "payments.example.com" root = "/srv/betalingen"

[sites.tls] cert = "/etc/webship/payments-fullchain.pem" sleutel = "/etc/webship/betalingen-private-sleutel.pem" ~~~

Hier ontvangt www.example.com zijn eigen openbare ACME-certificaat. control.internal.example ontvangt een privécertificaat van de ingebouwde CA. payments.example.com blijft onder de externe PKI van de operator omdat de expliciete bestanden voorrang hebben.

De openbare ACME-directory wordt genegeerd door ingebedde sites. De ingebedde root ondertekent nooit de openbare site. De handmatige site wordt nooit stilletjes ingeschreven in een van beide automatische workflows.

Één certificaatresolutie voor H1, H2, H3 en WebTransport

Certificaatselectie gebeurt tijdens de TLS-handshake, voordat er een HTTP-aanvraag bestaat. Webship gebruikt de ClientHello-servernaam om de site-identiteit te selecteren en onderhandelt vervolgens over het toepassingsprotocol.

• HTTP/1.1 en HTTP/2 gebruiken TLS over TCP.
• HTTP/3 en WebTransport gebruiken TLS binnen QUIC over UDP.
• Één geldige site-identiteit kan voor elk ingeschakeld protocol dienen.
• HTTP/3 vereist ook UDP-bereikbaarheid; H1 en H2 gebruiken het TCP-pad.
• Alt-Svc kan H3 adverteren terwijl een TCP-terugval behouden blijft.

TCP, TLS en QUIC gebruiken hetzelfde site-bewuste identiteitsmodel. Exacte namen hebben voorrang, de langste geldige wildcard wint waar wildcardcertificaten zijn geconfigureerd, en onbekende SNI-namen kunnen worden geweigerd in plaats van een niet-gerelateerd standaardcertificaat te ontvangen.

Gebruik unknown_sni = "reject" op een multi-site listener wanneer een niet-herkende hostnaam gesloten moet falen. Test herkende namen, niet-herkende namen en je verwachte geen-SNI gedrag voordat je het in productie uitrolt.

Draai ingebedde identiteiten zonder een bedieningskloof

Webship geeft de certificaatstaat en gecontroleerde mutaties bloot via zijn geverifieerde, loopback-gebonden MCP-server:

• webship.tls.get_status geeft de actieve certificaatoplosser en de vernieuwingsstatus weer.
• webship.tls.reissue_certificate geeft onmiddellijk een automatisch beheerde site opnieuw uit, alleen wanneer die site de ingesloten modus gebruikt.
• webship.tls.reload laadt de certificaatstaat opnieuw via het normale beveiligde TLS-pad.
• webship.acme_ca.status geeft aan of de private CA is geselecteerd, de directory van de status, de levensduur van het blad, het aantal uitgiften, het aantal intrekkingen en een recente domeinmonster.
• webship.sites.apply voegt sites toe of verwijdert sites tegen een vastgepinde configuratieversie.

Voor een ingebedde heruitgave maakt en valideert Webship de vervanging voordat deze in gebruik wordt genomen. De huidige geldige identiteit blijft dienen totdat de nieuwe identiteit klaar is. De gepensioneerde identiteit wordt pas geregistreerd nadat de vervanging is geïnstalleerd.

De onmiddellijke heruitgifte-operatie wijst opzettelijk publieke per_site-certificaten af. Publieke vernieuwing moet binnen de publieke ACME-cyclus blijven in plaats van verward te worden met privé ondertekening in uitvoering. Lidmaatschap in gedeelde modus is ook opnieuw gestart-bevroren omdat het wijzigen van een multi-SAN-groep de identiteitsgrens herbouwt.

MCP is een geprivilegieerd besturingspaneel. Houd het in loopback, vereis TLS en een sterk draagtoken, gebruik een geauthenticeerde tunnel voor externe administratie, en controleer iedere wijziging.

Faalgrenzen die ertoe doen

Een veilig certificaatsysteem moet in de juiste richting falen.

• Een nieuw geconfigureerde ingebedde site ontvangt de identiteit van een andere site niet terwijl de uitgifte in behandeling is.
• Een ongeldig vervangingscertificaat wordt niet geïnstalleerd over een werkend certificaat.
• Expliciete handmatige bestanden voorkomen automatisch eigendom van die site.
• Onbekende genoemde SNI kan worden geweigerd voordat HTTP-routering plaatsvindt.
• De ingebedde CA blijft privé en heeft geen externe inschrijvingsendpoint.
• Publieke en ingebedde identiteiten gebruiken afzonderlijke cachepaden binnen de automatische-TLS-status.

Een waarschuwing dat de ingebedde CA niet is geïnitialiseerd betekent dat Webship de geconfigureerde statusdirectory niet kon inschakelen. Los eigendom, machtigingen, persistentie of beschikbaarheid van opslag op voordat u verkeer naar de getroffen site stuurt. Probeer de fout niet te omzeilen door de root-sleutel van een andere omgeving te kopiëren.

Productiecontrolelijst

Voordat de ingesloten modus wordt ingeschakeld:

1. Identificeer elke klantengroep die het vertrouwen van de site moet hebben.
2. Creëer een gecontroleerd proces voor het exporteren en installeren van het rootcertificaat.
3. Gebruik een aparte hoofdstatus voor productie, ontwikkeling en testen.
4. Behoud en bescherm de ingesloten-CA-statendirectory en de automatische-TLS-cache.
5. Draai Webship onder een dedicated serviceaccount met toegang alleen tot het vereiste sleutelmateriaal.
6. Selecteer certificate_mode op elke site waarvan de vertrouwensgrens expliciet moet zijn.
7. Stel het onbekende-SNI-beleid in en test het.
8. Schakel H1, H2 en H3 bewust in en controleer zowel TCP- als UDP-paden.
9. Oefen het opnieuw uitgeven, opnieuw starten, back-up maken, herstellen en valideren van klantvertrouwen buiten productie.
10. Voer webship --check-config uit voordat u uitrolt, en controleer vervolgens de uitgever, namen, geldigheid, keten en onderhandelde protocollen van een echte client.

Kies eerst vertrouwen, daarna automatisering

De ingebedde CA verwijdert een externe certificaatsdienstafhankelijkheid voor private infrastructuur. Het maakt een privéracine niet wereldwijd vertrouwd en het verwijdert de PKI-verantwoordelijkheden van de beheerder niet.

Webship automatiseert sleutelgeneratie, ondertekening, validatie, installatie, rotatie en protocol-brede certificaatselectie. De operator behoudt nog steeds het beheer over root, cliëntinschrijving, scheiding van omgevingen, back-up, herstel en de beslissing om een openbaar of privévertrouwenspad te gebruiken.

Die scheiding is de eigenschap. Een zelfstandige server kan privé-TLS automatiseren zonder zich voor te doen als een openbare CA—en openbare sites kunnen nog steeds browser-vertrouwde per-site of groepsuitgifte in hetzelfde proces gebruiken.

Lees de gedocumenteerde versie Webship 1.4.0 documentatie vóór uitrol. RFC 5280 definieert certificaatprofielen en validatie, RFC 6066 definieert TLS server-naam signalering, RFC 8446 definieert TLS 1.3, RFC 8555 definieert publieke ACME, en RFC 9525 definieert verificatie van service-identiteit.