Navigare nel “VIP Club” di HTTPS: come gestire i certificati privati
Se hai mai sviluppato un’applicazione distribuita sicura, conosci già la situazione: i moderni servizi di autenticazione richiedono HTTPS. Prova a utilizzare token OpenID o Keycloak tramite semplice HTTP e il sistema, giustamente, rifiuterà di funzionare.
Quando si verificano errori HTTPS, una risposta comune è: “Il certificato non è valido”. Di solito, però, non è esattamente così. Il certificato potrebbe essere perfettamente valido. Il vero problema potrebbe essere che il client non si fida della Certificate Authority (CA) che lo ha emesso.
Ma come fa realmente il tuo dispositivo — Windows, Android, iOS o persino un container Docker — a sapere se la CA e la connessione HTTPS sono affidabili?
Ogni connessione HTTPS si basa su due proprietà distinte:
Trust (fiducia) — il client si fida della CA che ha firmato il certificato del server?
Identity (identità) — il certificato del server è valido per l’hostname che il client sta effettivamente utilizzando?
Sulla maggior parte dei dispositivi, i produttori dei sistemi operativi forniscono e mantengono un insieme predefinito di CA considerate attendibili. È, a tutti gli effetti, un esclusivo “VIP Club” delle Certificate Authority (CA).
Quando il certificato di un server deriva, tramite la propria catena di certificazione, da una di queste root CA appartenenti al “VIP Club”, HTTPS funziona senza configurazioni aggiuntive. Se vuoi evitare completamente i problemi di configurazione, ti basta utilizzare un certificato di una CA che appartiene al Club.
Ma questo modello non è sempre adatto agli ambienti privati.
Quando le CA pubbliche non sono un’opzione
Immagina una rete interna oppure un’infrastruttura che per motivi di stretta riservatezza o privacy non vengono intenzionalmente esposte su Internet e utilizzano hostname privati, ad esempio .internal o .local, o indirizzi IP privati non instradabili.
In questi casi, la soluzione consiste spesso nell’utilizzare una CA privata con certificati self-signed: sei costretto a diventare tu stesso la tua Certificate Authority.Sebbene configurare una CA locale privata sia relativamente semplice, è nella gestione della “catena di fiducia” tra microservizi containerizzati che le cose spesso iniziano a complicarsi.
Approfondisci alcuni scenari reali sul nostro sito.
Lo scenario dell’Edge Node
Se un server interno è firmato dalla tua CA privata, ogni client che deve comunicare con quel server deve a sua volta fidarsi di quella CA. Questo include anche i container.
Un container Docker non è semplicemente “l’host, ma più piccolo”. Può avere il proprio filesystem, il proprio archivio delle CA attendibili e una propria vista della rete. Il sistema host potrebbe fidarsi della CA privata mentre il container che esegue la tua applicazione non la considera attendibile. Quindi può verificarsi questa situazione:
Browser sull’host → HTTPS funziona
Applicazione all’interno di Docker → la verifica del certificato fallisce
La soluzione è concettualmente semplice: rendere disponibile la CA privata al container e installarla nel suo archivio delle CA attendibili. Ma c’è una seconda insidia: la fiducia della CA non è sufficiente.
Supponiamo che il certificato sia stato emesso per: reserved-host.local-net.internal.
La connessione a: https://reserved-host.local-net.internal potrebbe funzionare.
La connessione a: https://127.0.0.1 invece potrebbe fallire.
Perché? Perché TLS non verifica soltanto chi ha firmato il certificato. Verifica anche a chi appartiene il certificato, ovvero per quale identità è stato emesso. Un indirizzo IP, localhost e un hostname DNS sono identità differenti.
Questo aspetto diventa particolarmente importante per i sistemi di autenticazione come OpenID Connect e Keycloak. L’URL dell’emittente, l’endpoint di autorizzazione, il token endpoint, gli URL di redirect e la configurazione dell’applicazione devono fare riferimento in modo coerente alla stessa identità HTTPS valida.
HTTPS privato: la regola generale
La regola generale, quindi, è: L’HTTPS privato richiede sia una catena di autorità affidabile sia un modello di denominazione coerente.
E infine, un’accorgimento importante nella costruzione del software:
Non bloccare nel codice CA specifiche dell’ambiente, percorsi dei certificati, hostname o URL nella tua immagine applicativa.
I certificati e gli elementi di trust appartengono alla configurazione del deployment. Gli hostname appartengono all’ambiente. L’applicazione dovrebbe essere portabile tra diverse installazioni senza doverla rigenerare in relazione a uno specifico ambiente di produzione.
Spesso gli errori HTTPS vengono frettolosamente identificati come “problemi con il certificato”. In realtà, nella maggior parte dei casi si tratta di problemi di fiducia e di identità. E nei sistemi distribuiti, entrambe queste proprietà devono essere ovunque coerenti.