# TLS-certifikat i Webship: Den inbäddade ACME-CA:n
Ett TLS-certifikat gör två saker: det hjälper till att kryptera en anslutning och talar om för klienten vilken identitet det kommunicerar med. Kryptering kan vara stark medan förtroendebeslutet är fel för målgruppen. Det är därför certificate automation måste börja med en fråga: vem måste lita på denna webbplats?
Webship 1.4.0 gör det valet oberoende för varje konfigurerad webbplats. En offentlig webbplats kan använda ett ACME-certifikat som är betrott av webbläsare, en intern tjänst kan använda Webships inbäddade privata certifikatmyndighet, och en webbplats med en befintlig PKI kan behålla operatörs-skötte certifikatfiler. De kan alla dela en Webship-process utan att dela en privat nyckel eller en betrodd gräns.
Fyra automatiska certifikatlägen, valda per plats
Fältet certificate_mode tillhör varje [[sites]]-post. Det är inte en global strömbrytare.
| Läge | Förtroendekälla | Bästa passform | Valideringsväg | | --- | --- | --- | --- | | per_site | Offentliga webbläsar- och operativsystemets betrodda lagringsplatser | En offentlig webbplats med ett exakt värdnamn | Offentlig ACME med TLS-ALPN-01 | | flotta | Offentliga webbläsar- och operativsystemets förtroendelager | Stora uppsättningar av tredje- och fjärde-nivånamn under uttryckligen registrerade domäner | Offentlig ACME med DNS-01 och stabila certifikatdelar | | inbäddad | En privat Webship-root installerad av operatören | Interna tjänster, hanterade enheter, privata flottor och testmiljöer | Utfärdande i processen; ingen extern utmaning | | delad | Offentliga webbläsar- och operativsystemets betrodda lagringsplatser | Legacy-distributioner som medvetet använder en offentlig multi-SAN-grupp | Offentlig ACME med TLS-ALPN-01 |
Standardinställningen är per_site. Den beställer ett offentligt certifikat för webbplatsens exakta namn. Fleet-läge är det skalbara offentliga alternativet för många djupa underdomäner. Inbäddat läge använder Webships privata CA i processen. Delat läge finns kvar för kompatibilitet, men det är inte standard.
Ett komplett certifikat och nyckel under [sites.tls] har alltid företräde framför automatisk utfärdande för den webbplatsen.
Vad “embedded ACME CA” betyder
Konfigurationssektionen heter [acme_ca], men den inbäddade CA är inte en offentlig eller nätverksåtkomlig ACME-tjänst. Den exponerar ingen katalogendpoint, accepterar ingen fjärrregistrering, anropar inget registrar-API och utför ingen kontroll av ägarskapsutmaning.
Istället håller Webship hela den privata utfärdningsvägen i en process:
- Webbplatsen väljer certificate_mode = "embedded".
- Webship laddar eller skapar den privata rotidentiteten i den konfigurerade statuskatalogen.
- Webship genererar en ny privat nyckel för webbplatsen.
- Den inbäddade rotcertifikatet undertecknar ett bladcertifikat för det exakta namnet.
- Webship validerar den färdiga identiteten innan den installeras i den aktiva TLS-upplösaren.
- Certifikatet är då tillgängligt för varje aktiverat protokoll för den webbplatsen.
En ACME-stil nätverksutmaning skulle bara bevisa Webship för sig själv, så den inbäddade vägen har medvetet inget nätverksprotokoll. Avsnittet [acme_ca] är privat PKI-tillstånd: det definierar var roten finns och hur länge utfärdade bladcertifikat förblir giltiga.
Konfigurera ett inbäddat certifikat för en webbplats
Detta är den minimala formen för en privat sida:
~~~toml lyssna = "0.0.0.0:443"
[tls] unknown_sni = "reject"
[automatisk_tls] aktiverad = sant cache_dir = "/var/lib/webship/acme"
[acme_ca] state_dir = "/var/lib/webship/acme-ca" blad_giltighet_dagar = 90
[[platser]] domän = "service.internal.example" root = "/srv/service" certificate_mode = "embedded"
[sites.protokoll] h1 = sant h2 = sant h3 = sant ~~~
Rotidentiteten skapas fördröjt när en inbäddad webbplats först behöver den. Webship sparar rotnyckeln med restriktiva behörigheter i state_dir. Rotcertifikatet har en livstid på tio år; bladets livstid styrs av leaf_validity_days.
Behandla båda lagringsplatserna som produktionsläge:
- ACME-cachen håller automatiskt hanterade webbplatsidentiteter.
- Katalogen för inbäddad CA-status innehåller den privata rotidentiteten.
- Tjänstekontot behöver åtkomst, men applikationsanvändare gör det inte.
- Säkerhetskopior måste bevara sekretess och filbehörigheter.
- Produktion, utveckling och testning bör använda separata rötter och separata kataloger.
Att ta bort rotenkatalogen återställer inte 'TLS'. Det skapar en ny förtroendepunkt. Klienter som litar på den gamla roten kommer att avvisa certifikat som utfärdats av ersättningen tills deras förtroendelager uppdateras.
Privat förtroende är avsiktligt
Certifikat från den inbäddade CA är inte automatiskt betrodda av publika webbläsare eller operativsystem. De blir betrodda först efter att operatören har installerat det exporterade Webship-rotcertifikatet i klientens betrodda lagringsutrymme.
Det gör inbäddat läge väl lämpat för:
- företagsanvända bärbara datorer och telefoner registrerade genom enhetsadministration;
- intern tjänst-till-tjänst-trafik med ett uttryckligt CA-bunt;
- privata apparater och kontrollerade kantflottor;
- utvecklings- och testmiljöer som måste utöva verkligt TLS-beteende;
- frånkopplade nätverk som inte kan lita på en offentlig CA.
Det är inte rätt läge för en vanlig offentlig webbplats vars besökare använder ohanterade webbläsare. Använd offentlig per_site-utfärdning för ett exakt offentligt namn, fleet-utfärdning för stora offentliga underdomänsset, endast delad för en avsiktlig äldre multi-SAN-distribution, eller manuella filer från en redan betrodd PKI.
Dela endast rotcertifikatet med klienter. Dela aldrig den privata rotnyckeln. Innehav av den nyckeln ger dess innehavare befogenhet att utfärda identiteter som är betrodda av varje registrerad klient.
Offentliga och privata certifikat kan samexistera
Webship 1.4.0 kan blanda certifikatstrategier på samma lyssnare:
~~~toml listen = "0.0.0.0:443"
[tls] unknown_sni = "reject"
[automatisk_tls] aktiverad = sant directory_url = "https://acme-v02.api.letsencrypt.org/directory" cache_dir = "/var/lib/webship/acme" kontakter = ["mailto:ops@example.com"] acceptera_användarvillkor = sant
[acme_ca] state_dir = "/var/lib/webship/acme-ca" blad_giltighet_dagar = 90
[[platser]] domän = "www.example.com" root = "/srv/public" certificate_mode = "per_site"
[[platser]] domän = "control.internal.example" root = "/srv/control" certificate_mode = "embedded"
[[platser]] domän = "payments.example.com" root = "/srv/payments"
[webbplatser.tls] cert = "/etc/webship/payments-fullchain.pem" nyckel = "/etc/webship/payments-private-key.pem" ~~~
Här får www.example.com sitt eget offentliga ACME-certifikat. control.internal.example får ett privat certifikat från den inbäddade CA. payments.example.com förblir under operatörens externa PKI eftersom dess explicita filer har företräde.
Den offentliga ACME-katalogen ignoreras av inbäddade sajter. Den inbäddade roten undertecknar aldrig den offentliga sajten. Den manuella sajten registreras aldrig tyst i någon av de automatiska arbetsflödena.
En certifikatresolving för H1, H2, H3 och WebTransport
Certifikatval sker under TLS-handshaken, innan en HTTP-förfrågan existerar. Webship använder ClientHello-servernamnet för att välja webbplatsidentiteten och förhandlar sedan om applikationsprotokollet.
- HTTP/1.1 och HTTP/2 använder TLS över TCP.
- HTTP/3 och WebTransport använder TLS inuti QUIC över UDP.
- En giltig webbplatsidentitet kan tjänstgöra för varje aktiverat protokoll.
- HTTP/3 kräver också UDP-tillgänglighet; H1 och H2 använder TCP-vägen.
- Alt-Svc kan annonsera H3 samtidigt som en TCP-fallback bevaras.
TCP, TLS och QUIC använder samma platsmedvetna identitetsmodell. Exakta namn har företräde, det längsta giltiga jokertecknet vinner där jokerteckenscertifikat är konfigurerade, och okända namngivna SNI kan avvisas istället för att ta emot ett orelaterat standardcertifikat.
Använd unknown_sni = "reject" på en multi-site-lyssnare när ett okänt värdnamn måste misslyckas med stängt läge. Testa igenkända namn, oigenkända namn och ditt förväntade no-SNI-beteende innan produktsättning.
Rotera inbäddade identiteter utan ett serveringsgap
Webship exponerar certifikatstatus och kontrollerade ändringar genom sin autentiserade MCP-server, bunden till loopback:
- webship.tls.get_status rapporterar den aktiva certifikatlösaren och förnyelsestatusen.
- webship.tls.reissue_certificate återutfärdar omedelbart ett automatiskt hanterat webbplats endast när den webbplatsen använder inbäddat läge.
- webship.tls.reload laddar om certifikatets status genom den vanliga skyddade TLS-vägen.
- webship.acme_ca.status rapporterar om den privata CA:n är vald, dess statskatalog, löptiden för bladcertifikat, utfärdandeloggningsantal, återkallningsantal och nyligen domänprov.
- webship.sites.apply lägger till eller tar bort sajter mot en fastställd konfigurationsversion.
För en inbäddad omutgivning skapar och validerar Webship ersättningen innan den tas i bruk. Den nuvarande giltiga identiteten fortsätter att användas tills den nya identiteten är klar. Den pensionerade identiteten registreras först efter att ersättningen har installerats.
Den omedelbara återutgivningsoperationen avvisar avsiktligt offentliga per_site-certifikat. Offentlig förnyelse måste förbli inom den offentliga ACME-livscykeln istället för att blandas ihop med privat pågående signering. Medlemskap i delat läge är också återstartfryst eftersom ändring av en multi-SAN-grupp återuppbygger identitetsgränsen.
MCP är en privilegierad kontrollyta. Håll den på loopback, kräva TLS och en stark bärartoken, använd en autentiserad tunnel för fjärradministration och granska varje förändring.
Misslyckandegränser som spelar roll
Ett säkert certifikatsystem måste misslyckas åt rätt håll.
- En nykonfigurerad inbäddad webbplats tar inte emot en annan webbplats identitet medan utfärdandet pågår.
- En ogiltig ersättning installeras inte över ett fungerande certifikat.
- Explicita manuella filer förhindrar automatisk ägande av den webbplatsen.
- Okänt namn SNI kan nekas före HTTP-routing.
- Den inbäddade CA:n förblir privat och har ingen fjärrregistreringspunkt.
- Offentliga och inbäddade identiteter använder separata cachevägar inne i det automatiska TLS-tillståndet.
En varning om att den inbäddade CA:n inte är initierad betyder att Webship inte kunde aktivera den konfigurerade statskatalogen. Åtgärda ägarskap, behörigheter, uthållighet eller lagringstillgänglighet innan du skickar trafik till den berörda webbplatsen. Försök inte kringgå felet genom att kopiera en annan miljös rotnyckel.
Produktionschecklista
Innan det inbäddade läget aktiveras:
- Identifiera varje kundgrupp som måste lita på webbplatsen.
- Skapa en kontrollerad process för att exportera och installera rotcertifikatet.
- Använd separat rot-tillstånd för produktion, utveckling och testning.
- Behåll och skydda den inbäddade CA-statusmappen och cache för automatisk TLS.
- Kör Webship under ett dedikerat tjänstekonto med åtkomst endast till nödvändigt nyckelmaterial.
- Välj certificate_mode på varje webbplats där förtroendegränsen måste vara tydlig.
- Ställ in och testa policyn för okänd SNI.
- Aktivera H1, H2 och H3 medvetet och verifiera både TCP- och UDP-vägar.
- Öva nyutgivning, omstart, säkerhetskopiering, återställning och klient-förtroendevalidering utanför produktion.
- Kör webship --check-config före utrullning, kontrollera sedan utfärdare, namn, giltighet, kedja och förhandlade protokoll från en riktig klient.
Välj förtroende först, automatisering andra
Den inbäddade CA tar bort ett externt certifikattjänstberoende för privat infrastruktur. Den gör inte en privat rot globalt betrodd, och den tar inte bort operatörens PKI-ansvar.
Webship automatiserar nyckelgenerering, signering, validering, installation, rotation och certifikatval över hela protokollet. Operatören behåller fortfarande ägandet av root-förvaring, klientregistrering, miljöseparation, säkerhetskopiering, återställning och beslutet att använda en offentlig eller privat betrodd väg.
Den separationen är funktionen. En självständig server kan automatisera privat TLS utan att låtsas vara en offentlig CA—och offentliga webbplatser kan fortfarande använda webbläsarbetrodda per-plats- eller fleet-utfärdanden i samma process.
Läs den versionerade Webship 1.4.0-dokumentationen innan utrullning. RFC 5280 definierar certifikatprofiler och validering, RFC 6066 definierar TLS-servernamnssignalering, RFC 8446 definierar TLS 1.3, RFC 8555 definierar offentlig ACME, och RFC 9525 definierar verifiering av serviceidentitet.