Certificati TLS in Webship: L'ACME CA Integrato

# Certificati TLS in Webship: L'ACME CA Integrato

Un certificato TLS svolge due funzioni: aiuta a crittografare una connessione e indica al client quale identità sta contattando. La crittografia può essere forte mentre la decisione di fiducia è sbagliata per il pubblico. Ecco perché l'automazione dei certificati deve iniziare con una domanda: chi deve fidarsi di questo sito?

Webship 1.4.0 prende quella decisione in modo indipendente per ogni sito configurato. Un sito web pubblico può utilizzare un certificato ACME riconosciuto dai browser, un servizio interno può utilizzare l'autorità di certificazione privata incorporata di Webship, e un sito con una PKI esistente può mantenere file di certificati gestiti dall'operatore. Tutti possono condividere un unico processo Webship senza condividere una chiave privata o un confine di fiducia.

Quattro modalità di certificato automatico, selezionate per sito

Il campo certificate_mode appartiene a ciascuna voce [[sites]]. Non è un interruttore globale.

| Modalità | Fonte attendibile | Migliore adattamento | Percorso di convalida | | --- | --- | --- | --- | | per_site | Archivi di fiducia del browser e del sistema operativo pubblici | Un sito pubblico con un nome host esatto | ACME pubblico con TLS-ALPN-01 | | flotta | Archivi pubblici dei browser e dei sistemi operativi | Grandi insiemi di nomi di terzo e quarto livello sotto domini registrati esplicitamente | ACME pubblico con DNS-01 e frammenti di certificato stabili | | incorporato | Una radice Webship privata installata dall'operatore | Servizi interni, dispositivi gestiti, flotte private e ambienti di test | Emissione in corso; nessuna sfida esterna | | condiviso | Archivi di fiducia pubblici del browser e del sistema operativo | Implementazioni legacy che utilizzano intenzionalmente un singolo gruppo multi-SAN pubblico | ACME pubblico con TLS-ALPN-01 |

Il valore predefinito è per_site. Ordina un certificato pubblico per il nome esatto del sito. La modalità Fleet è l'opzione pubblica scalabile per molti sottodomini profondi. La modalità Embedded utilizza la CA privata in-process di Webship. La modalità Shared rimane disponibile per compatibilità, ma non è quella predefinita.

Un certificato e una chiave completi sotto [sites.tls] hanno sempre la precedenza sull'emissione automatica per quel sito.

Cosa significa “ACME CA incorporato”

La sezione di configurazione è denominata [acme_ca], ma la CA incorporata non è un servizio ACME pubblico o accessibile in rete. Non espone alcun endpoint di directory, non accetta iscrizioni remote, non chiama alcuna API di registrar e non esegue alcuna challenge di verifica del controllo.

Invece, Webship mantiene l'intero percorso di emissione privata in un unico processo:

1. Il sito seleziona certificate_mode = "embedded".
2. Webship carica o crea l'identità radice privata nella directory di stato configurata.
3. Webship genera una nuova chiave privata per il sito.
4. Il root incorporato firma un certificato leaf per quel nome esatto.
5. Webship convalida l'identità completata prima di installarla nel risolutore TLS live.
6. Il certificato è quindi disponibile per ogni protocollo abilitato per quel sito.

Una sfida di rete in stile ACME servirebbe solo a dimostrare Webship a se stesso, quindi il percorso incorporato non ha intenzionalmente alcun protocollo di rete. La sezione [acme_ca] è lo stato PKI privato: definisce dove risiede la root e quanto tempo i certificati leaf emessi rimangono validi.

Configura un certificato incorporato per un sito

Questa è la forma minima per un sito privato:

~~~toml listen = "0.0.0.0:443"

[tls] unknown_sni = "reject"

[tls_automatico] abilitato = vero cache_dir = "/var/lib/webship/acme"

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

[[siti]] dominio = "service.internal.example" root = "/srv/service" certificate_mode = "embedded"

[siti.protocolli] h1 = vero h2 = vero h3 = vero ~~~

L'identità radice viene creata pigramente quando un sito incorporato ne ha bisogno per la prima volta. Webship conserva la chiave radice con permessi restrittivi in state_dir. Il certificato radice ha una durata di dieci anni; la durata della foglia è controllata da leaf_validity_days.

Tratta entrambe le posizioni di archiviazione come stato di produzione:

• La cache ACME contiene identità del sito gestite automaticamente.
• La directory dello stato della CA incorporata contiene l'identità privata della root.
• L'account di servizio ha bisogno di accesso, ma gli utenti dell'applicazione no.
• I backup devono preservare la riservatezza e i permessi dei file.
• Produzione, sviluppo e test dovrebbero utilizzare radici separate e directory separate.

Eliminare la directory radice non "reimposta TLS". Crea un nuovo punto di fiducia. I client che si fidano della vecchia radice rifiuteranno i certificati emessi dalla sostituzione fino a quando i loro archivi di fiducia non saranno aggiornati.

Il trust privato è intenzionale

I certificati della CA incorporata non sono automaticamente considerati attendibili dai browser pubblici o dai sistemi operativi. Diventano attendibili solo dopo che l'operatore ha installato il certificato root Webship esportato nell'archivio di fiducia del client.

Questo rende la modalità incorporata adatta a:

• laptop e telefoni gestiti dall'azienda iscritti tramite la gestione dei dispositivi;
• traffico interno da servizio a servizio con un pacchetto CA esplicito;
• apparecchiature private e flotte di bordo controllate;
• ambienti di sviluppo e test che devono esercitare il comportamento reale di TLS;
• reti disconnesse che non possono dipendere da una CA pubblica.

Non è la modalità giusta per un sito web pubblico ordinario i cui visitatori usano browser non gestiti. Utilizzare l'emissione per sito pubblico per un nome pubblico preciso, l'emissione di flotta per grandi insiemi di sottodomini pubblici, solo condivisa per un'implementazione multi-SAN legacy intenzionale, oppure file manuali da un PKI già affidabile.

Distribuire solo il certificato root ai client. Non distribuire mai la chiave privata root. Il possesso di quella chiave conferisce al suo detentore l'autorità di emettere identità fidate da ogni client registrato.

I certificati pubblici e privati possono coesistere

Webship 1.4.0 può mescolare le strategie dei certificati sullo stesso listener:

~~~toml listen = "0.0.0.0:443"

[tls] unknown_sni = "reject"

[tls_automatico] abilitato = vero directory_url = "https://acme-v02.api.letsencrypt.org/directory" cache_dir = "/var/lib/webship/acme" contatti = ["mailto:ops@example.com"] accetta_termini_di_servizio = true

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

[[siti]] dominio = "www.example.com" root = "/srv/public" certificate_mode = "per_site"

[[siti]] dominio = "control.internal.example" root = "/srv/control" certificate_mode = "embedded"

[[siti]] dominio = "payments.example.com" root = "/srv/payments"

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

Qui, www.example.com riceve il proprio certificato ACME pubblico. control.internal.example riceve un certificato privato dalla CA incorporata. payments.example.com rimane sotto la PKI esterna dell’operatore perché i suoi file espliciti hanno la precedenza.

La directory pubblica ACME è ignorata dai siti incorporati. La root incorporata non firma mai il sito pubblico. Il sito manuale non viene mai iscritto silenziosamente in nessuno dei flussi di lavoro automatici.

Un risolutore di certificati per H1, H2, H3 e WebTransport

La selezione del certificato avviene durante il handshake TLS, prima che esista una richiesta HTTP. Webship utilizza il nome del server ClientHello per selezionare l'identità del sito e quindi negozia il protocollo applicativo.

• HTTP/1.1 e HTTP/2 utilizzano TLS su TCP.
• HTTP/3 e WebTransport usano TLS all'interno di QUIC su UDP.
• Un'identità del sito valida può servire per ogni protocollo abilitato.
• HTTP/3 richiede anche la raggiungibilità UDP; H1 e H2 utilizzano il percorso TCP.
• Alt-Svc può pubblicizzare H3 preservando un fallback TCP.

TCP, TLS e QUIC utilizzano lo stesso modello di identità consapevole del sito. I nomi esatti hanno la precedenza, vince il jolly valido più lungo dove sono configurati i certificati jolly, e un SNI con nome sconosciuto può essere rifiutato invece di ricevere un certificato predefinito non correlato.

Usa unknown_sni = "reject" su un listener multi-sito quando un hostname non riconosciuto deve fallire chiudendo. Testa i nomi riconosciuti, i nomi non riconosciuti e il tuo comportamento previsto senza SNI prima del rilascio in produzione.

Ruotare le identità incorporate senza un intervallo di servizio

Webship espone lo stato del certificato e le mutazioni controllate attraverso il suo server MCP autenticato, legato al loopback:

• webship.tls.get_status segnala il risolutore del certificato attivo e lo stato del rinnovo.
• webship.tls.reissue_certificate riesegue immediatamente un sito gestito automaticamente solo quando quel sito utilizza la modalità incorporata.
• webship.tls.reload ricarica lo stato del certificato attraverso il normale percorso TLS protetto.
• webship.acme_ca.status segnala se la CA privata è selezionata, la sua directory di stato, la durata del certificato leaf, il numero di emissioni, il numero di revoche e un campione recente di domini.
• webship.sites.apply aggiunge o rimuove siti rispetto a una versione di configurazione fissata.

Per una riemissione incorporata, Webship crea e convalida la sostituzione prima di inserirla in servizio. L'identità valida attuale continua a servire fino a quando la nuova identità non è pronta. L'identità ritirata viene registrata solo dopo che la sostituzione è stata installata.

L'operazione di riesecuzione immediata rifiuta intenzionalmente i certificati per_site pubblici. Il rinnovo pubblico deve rimanere all'interno del ciclo di vita pubblico ACME piuttosto che essere confuso con la firma privata in corso. Anche l'appartenenza in modalità condivisa è bloccata durante il riavvio perché modificare un gruppo multi-SAN ricostruisce il confine dell'identità.

MCP è una superficie di controllo privilegiata. Mantienila in loopback, richiedi TLS e un token bearer forte, usa un tunnel autenticato per l'amministrazione remota e verifica ogni mutazione.

Confini del fallimento che contano

Un sistema di certificati sicuro deve fallire nella direzione corretta.

• Un sito incorporato appena configurato non riceve l'identità di un altro sito mentre l'emissione è in sospeso.
• Una sostituzione non valida non viene installata su un certificato funzionante.
• I file manuali espliciti impediscono la proprietà automatica di quel sito.
• Un SNI con nome sconosciuto può essere rifiutato prima del routing HTTP.
• La CA incorporata rimane privata e non ha un endpoint di registrazione remoto.
• Le identità pubbliche e incorporate utilizzano percorsi di cache separati all'interno dello stato TLS automatico.

Un avviso che la CA incorporata non è inizializzata significa che Webship non è stato in grado di armare la directory di stato configurata. Correggere proprietà, permessi, persistenza o disponibilità di archiviazione prima di inviare traffico al sito interessato. Non aggirare l'errore copiando la chiave root di un altro ambiente.

Lista di controllo della produzione

Prima di abilitare la modalità incorporata:

1. Identifica ogni popolazione di clienti che deve fidarsi del sito.
2. Crea un processo controllato per esportare e installare il certificato radice.
3. Usa uno stato radice separato per produzione, sviluppo e test.
4. Persisti e proteggi la directory di stato della CA incorporata e la cache TLS automatica.
5. Esegui Webship sotto un account di servizio dedicato con accesso solo al materiale chiave necessario.
6. Seleziona certificate_mode su ogni sito il cui confine di fiducia deve essere esplicito.
7. Imposta e testa la politica SNI sconosciuta.
8. Abilita H1, H2 e H3 deliberatamente e verifica sia i percorsi TCP che UDP.
9. Esercizio di riautorizzazione, riavvio, backup, ripristino e convalida della fiducia del cliente fuori produzione.
10. Esegui webship --check-config prima del rilascio, poi verifica emittente, nomi, validità, catena e protocolli negoziati da un client reale.

Scegli prima la fiducia, poi l'automazione

La CA incorporata rimuove una dipendenza da un servizio di certificati esterno per l'infrastruttura privata. Non rende una root privata riconosciuta globalmente e non rimuove le responsabilità PKI dell'operatore.

Webship automatizza la generazione delle chiavi, la firma, la convalida, l'installazione, la rotazione e la selezione dei certificati a livello di protocollo. L'operatore mantiene comunque la custodia della root, l'iscrizione dei client, la separazione degli ambienti, il backup, il ripristino e la decisione di utilizzare un percorso di fiducia pubblico o privato.

Quella separazione è la caratteristica. Un server autonomo può automatizzare TLS privato senza fingere di essere una CA pubblica—e i siti pubblici possono comunque usare l'emissione per sito o per flotta affidabile dal browser nello stesso processo.

Leggi la documentazione versionata Webship 1.4.0 prima del rilascio. RFC 5280 definisce i profili e la convalida dei certificati, RFC 6066 definisce la segnalazione del nome del server TLS, RFC 8446 definisce TLS 1.3, RFC 8555 definisce ACME pubblico, e RFC 9525 definisce la verifica dell'identità del servizio.