14.4.4. Certificati firmati da CA (con fiducia pubblica)

I certificati self-signed funzionano quando controlli entrambi gli estremi. Se invece client arbitrari (browser, telefoni, software di terze parti) devono connettersi alla camera senza che venga loro indicato di fidarsi di un certificato personalizzato, il certificato deve essere firmato da una Certificate Authority (CA) pubblica di cui quei client si fidano già. Il codice TLS sulla camera è identico al caso self-signed – load_cert_chain con un certificato e una chiave in forma DER – cambia solo il modo in cui ottieni quel certificato.

Il punto più importante in assoluto: la chiave privata la generi tu stesso e non lascia mai la tua macchina. La CA non la vede mai. Ciò che invii alla CA è una richiesta di firma del certificato (CSR), un piccolo file che contiene la tua chiave pubblica e il tuo nome di dominio, e ciò che ricevi indietro è un certificato (la tua chiave pubblica e il tuo nome, firmati dalla CA). La chiave e il certificato sono due file distinti prodotti da due passaggi distinti; la CA gestisce sempre e solo la metà pubblica.

Il flusso generale, svolto interamente su una macchina normale (mai sulla camera):

  1. Ottieni un nome di dominio. Le CA pubbliche certificano un nome DNS che controlli (ad es. cam.example.com); non emettono certificati per un semplice indirizzo IP o per un nome solo locale come mycam.

  2. Genera una chiave e una CSR. Un singolo comando OpenSSL produce la chiave privata e la CSR corrispondente. Usa lo stesso tipo di chiave che useresti per un certificato self-signed (vedi Concetti: fiducia, chiavi e formato dei file); è consigliato ECDSA P-256.

    ECDSA P-256 – consigliato:

    openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"

    ECDSA P-384 – più robusto, ma più grande/lento:

    openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:secp384r1 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"

    RSA-2048 – massima compatibilità:

    openssl req -new -newkey rsa:2048 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"

    Mantieni segreta domain.key: è il file della chiave che alla fine metterai sulla camera. domain.csr è il file che consegni alla CA; non contiene alcun segreto.

  3. Invia la CSR e dimostra di controllare il dominio. È qui che le due strade comuni divergono:

    • Una CA ACME automatizzata come Let’s Encrypt, gestita da uno strumento come certbot o acme.sh, esegue per te i passaggi 2 e 3: genera la chiave, costruisce la CSR, risponde automaticamente alla challenge (HTTP-01: serve un token sulla porta 80 del dominio, oppure DNS-01: pubblica un record TXT nel suo DNS) e scrive i file finiti.

    • Una CA commerciale (acquistata direttamente o tramite un rivenditore di domini/hosting): incolli il testo di domain.csr in un modulo web, poi dimostri il controllo rispondendo a un’email di validazione, pubblicando un record DNS o collocando un file su un server web per quel dominio. Una volta validato, scarichi i file emessi.

  4. Raccogli i file emessi. Per capire ciò che ricevi, aiuta sapere che i certificati formano una catena di fiducia: il certificato del tuo dominio è firmato da una CA intermedia, che a sua volta è firmata da una CA root. Ogni anello garantisce per quello sottostante. Ti ritrovi con:

    • La tua chiave privata (dal passaggio 2). La CA non l’ha mai avuta; rimane sulla tua macchina ed è la chiave che alla fine metterai sulla camera.

    • Il certificato leaf – chiamato anche certificato end-entity o server. È il certificato per il tuo dominio specifico (cam.example.com): contiene la tua chiave pubblica e il tuo nome, ed è firmato dall’intermedio della CA. È il certificato che la camera presenta per identificarsi.

    • Uno o più certificati di CA intermedie (la «catena» o «CA bundle»). Una CA non firma il tuo leaf direttamente con la propria root – la chiave della root è tenuta offline e fortemente protetta – quindi firma con un intermedio, che a sua volta è firmato dalla root. L’intermedio è l’anello che collega il tuo leaf fino alla root.

    Il certificato root è l”ancora di fiducia: un certificato self-signed appartenente alla CA che si trova in cima alla catena. Non ti viene fornito e non lo distribuisci mai, perché ogni client lo possiede già: sistemi operativi, browser, telefoni e runtime dei linguaggi includono un «trust store» integrato di certificati root. Un client si fida del tuo leaf percorrendo la catena: si fida già della root, la root garantisce per l’intermedio e l’intermedio garantisce per il tuo leaf. (È esattamente il compito che il tuo singolo server.der / cafile svolge nel caso self-signed – lì tu sei la tua stessa root.)

    Un file fullchain è semplicemente il leaf e gli intermedi concatenati in un unico file, leaf per primo, deliberatamente senza la root (inviare la root è inutile – un client si fida solo delle root che possiede già). Un server normale presenta l’intero fullchain in modo che qualsiasi client possa percorrerlo. La camera non può farlo: carica e presenta un solo certificato – il leaf – e non può inviare anche i certificati intermedi che la CA ti ha dato.

    Nomi di file che vedrai realmente: uno strumento ACME come certbot scrive privkey.pem (la tua chiave), cert.pem (solo il leaf), chain.pem (solo gli intermedi) e fullchain.pem (leaf + intermedi). Una CA commerciale di solito ti dà un .crt per il leaf e un .ca-bundle per gli intermedi, mentre il .key è quello che hai generato tu stesso.

  5. Converti e copia. Converti la chiave privata e il certificato leaf in DER e copiali sulla camera esattamente come in Certificati autofirmati. La camera li presenta poi come proprio certificato server e i client standard accettano la connessione automaticamente, perché si fidano già della CA – non serve alcuna configurazione lato client.

Suggerimento

In pratica, il fatto che la camera presenti solo il leaf (e mai gli intermedi) si traduce così:

  • I client che hanno già in cache l’intermedio della CA – i browser e le librerie HTTPS più diffusi di solito ce l’hanno – completano da soli la catena e si connettono senza problemi.

  • I client che si affidano al server per fornire l’intermedio falliranno l’handshake con la camera.

Se ogni possibile client deve riuscire a connettersi, non terminare il TLS pubblico direttamente sulla camera. Metti davanti ad essa un gateway / reverse proxy che serva la catena completa al mondo esterno, e fa” che il proxy raggiunga la camera tramite il flusso self-signed descritto sopra.