Certificati e TLS

Il vincolo di partenza

Un hostname sotto un TLD privato — .loc, .local, .internal — non può essere certificato da una CA pubblica. Nessuna CA pubblica emetterà mai un certificato per portale.corellix.loc, perché quel nome non è di nessuno in particolare.

Questo non è un limite di Corellix: è come funziona la PKI pubblica. La conseguenza è che il certificato deve venire da una CA privata, e che i client devono essere messi in condizione di fidarsi di quella CA.

La CA interna

Al bootstrap, Warden crea una CA interna ed emette i certificati dei servizi e quello dell’ingress. Funziona subito e non richiede nulla da voi.

I client che non conoscono quella CA reagiscono così:

Client	Comportamento
Browser	Mostra un avviso, permette di procedere
Client .NET, Java, Go (agent, integrazioni)	Rifiutano la connessione, senza possibilità di procedere
`curl`, `wget`	Falliscono, salvo opzioni esplicite

La seconda riga è quella che conta. Un browser vi lascia proseguire; un agent no. È il motivo per cui distribuire la radice della CA — o usare la vostra PKI — non è opzionale appena qualcosa che non sia un browser deve connettersi.

Le due strade

Distribuire la radice della CA interna

Scaricate il certificato radice da Citadel (Rete e certificati) o:

core cert ca export --output /tmp/corellix-ca.crt

e distribuitelo:

Windows: per GPO, nell’archivio “Autorità di certificazione radice attendibili”.
Linux: in /etc/pki/ca-trust/source/anchors/ seguito da update-ca-trust, oppure /usr/local/share/ca-certificates/ e update-ca-certificates.
macOS: nel portachiavi di sistema, marcato come attendibile.

Usare la vostra PKI

Se avete una CA aziendale già distribuita su tutte le postazioni, è la strada migliore: non aggiungete una seconda radice da gestire.

Emettete un certificato che copra tutti gli hostname della piattaforma e caricatelo da Citadel, o:

core cert import --cert /path/certificato.pem --key /path/chiave.pem

Quali nomi deve coprire il certificato

Tutti quelli che la piattaforma pubblica. L’elenco è calcolato dalla piattaforma, non configurato a mano:

SAN	Serve a
`<slug>.services.<dominio>`	Il portale
`api.<dominio>`	L’API Gateway
`agents.<dominio>`	L’ingest degli agent
`docs.<dominio>`	Il portale documentazione
`beaconstudio.<dominio>`	Beacon Studio
`*.console.<dominio>`	Le console web incorporate

Un nome mancante non degrada l’esperienza: la interrompe. Un agent che non può validare agents.<dominio> non riporta e basta — non c’è un avviso da ignorare. Una console incorporata in un frame con un errore di certificato fallisce senza poter chiedere conferma all’utente.

Verificate con:

core cert list
core cert show --name ingress

Scadenze

I certificati emessi dalla CA interna sono rinnovati automaticamente da Warden prima della scadenza. Quelli caricati da voi no: la piattaforma vi avvisa con anticipo, ma il rinnovo è vostro.

Le scadenze sono in Citadel sotto Rete e certificati, e in core cert list. I certificati in scadenza generano un allarme.

Certificato di Citadel

Citadel ha un proprio certificato, perché deve rispondere sulla 8443 anche prima che esista una CA. Al primo avvio ne genera uno auto-firmato; dopo il bootstrap viene sostituito da uno emesso dalla CA interna.

Certificati delle piattaforme sorgente

Corellix verifica i certificati delle piattaforme che interroga. Se una sorgente usa un certificato auto-firmato o emesso da una CA che l’appliance non conosce, la connessione fallisce.

La soluzione corretta è aggiungere quella CA fra quelle attendibili dell’appliance:

core cert trust add --file /path/ca-della-sorgente.crt

La verifica si può disattivare per singola connessione, ed è sconsigliato: vale solo come misura temporanea durante una diagnosi.

Verifiche rapide

# Che cosa presenta l'ingress
openssl s_client -connect portale.azienda.loc:443 -servername portale.azienda.loc \
  </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# Stato di tutti i certificati dell'appliance
core cert list

Corellix Platform 1.0.1