MAGGIO 2026
Dall’HTTPS al Trust tra macchine: l’ascesa dei certificati client mTLS
Negli ultimi anni abbiamo visto succedere una cosa curiosa: il certificato digitale, che molti associavano solo all'https, si sta prendendo un posto sempre più centrale nelle architetture moderne, questo perché è indubbio che le macchine parlino più degli esseri umani. E quando parlano tra loro – via API, microservizi, integrazioni cloud, scambi tra piattaforme fiduciarie – la domanda non è solo il canale è cifrato?, ma soprattutto: da chi arriva la chiamata? qual è la sua identità?
È qui che entra in gioco il mutual TLS, o mTLS. In un TLS “normale”, il server presenta il suo certificato e il client si fida (se tutto torna). Con mTLS viene aggiunto un passo in più: anche il client si autentica con un certificato X.509. Quindi entrambe le parti dimostrano la loro identità crittografica. Risultato? Non stiamo più solo proteggendo una comunicazione: stiamo costruendo una relazione di fiducia verificabile.
Per maggiore chiarezza: questa è una direzione tecnica e normativa che sta diventando strutturale.
Perché i certificati client contano sempre di più
Il punto è semplice: API key e token non sono identità, sono segreti condivisi. Funzionano finché non finiscono nel posto sbagliato: un file di configurazione copiato male, procedure di scambio non eseguite correttamente, un log troppo verboso, un repository pubblico “per prova”. E una volta che una chiave è rubata, l’attaccante diventa indistinguibile dal client legittimo.
Con i certificati client la musica cambia. Ogni applicazione, container, workload o gateway API ha una identità forte, ancorata a una chiave privata. Non stiamo più dicendo “conosco la password”, ma “sono questo soggetto e te lo dimostro”. Inoltre, questa identità è:
- non clonabile (senza la chiave privata non puoi fare nulla);
- tracciabile e auditabile (catena di fiducia, attributi, revoca);
- governabile via policy (chi può chiamare cosa, in base a CN/SAN/EKU e CA).
In altre parole l'mTLS è il modo naturale con cui si fa zero trust tra macchine.
Naturalmente, il certificato client dà il meglio di sé quando è inserito in una gestione corretta dell’identità e delle chiavi. La sua forza infatti si fonda sulla tutela della chiave privata: nel mondo machine-to-machine, conservarla in un keystore sicuro, un vault o un HSM significa portare l’autenticazione a un livello davvero robusto, riducendo drasticamente il rischio di uso improprio anche in presenza di configurazioni sbagliate o permessi troppo larghi. In pratica, con gli strumenti giusti, il certificato client diventa una delle difese più affidabili disponibili.
Allo stesso modo, è vero che un certificato ha una scadenza — ma questa non è un limite, è un meccanismo di sicurezza e di controllo. Quando la rotazione è gestita in modo centralizzato e automatizzato, la scadenza smette di essere una seccatura operativa e diventa un’opportunità: garantisce continuità, aggiorna regolarmente le chiavi e mantiene l’infrastruttura aggiornata e governata. Certo, si può scegliere anche una durata estesa (noi offriamo certificati fino a 3 anni) per ridurre ulteriormente l’effort, ma è l’automazione che chiude il cerchio e rende il ciclo di vita dei certificati finalmente semplice, sicuro e senza sorprese.
Detto questo, come forma di autenticazione resta tra le più robuste: una chiave privata sottratta è un incidente isolato e revocabile, mentre un token API compromesso è replicabile indefinitamente e indistinguibile dall’originale. In altre parole: il rischio esiste, ma è governabile, e soprattutto, è un rischio che non ti obbliga a fidarti ciecamente di segreti statici sparsi nell’infrastruttura.
I certificati client indispensabili per tecnici e per enti regolatori
Nel mondo “fiduciario” europeo, per esempio, questa esigenza è già scritta nero su bianco. I servizi REM (Registered Electronic Mail) sotto eIDAS/eIDAS 2.0 puntano su interoperabilità e fiducia end-to-end. Gli standard ETSI per REM e l’uso di certificati qualificati indicano l’adozione di canali TLS con mutua autenticazione quando entrambe le parti hanno certificati di autenticazione adeguati (QWAC/QCert): quindi con certificati client.
Tradotto: se stai costruendo ecosistemi dove la fiducia è parte del servizio, l’identità della macchina chiamante non può essere un optional.
Lo stesso vale nel cloud regolato. Il percorso di qualificazione ACN per i servizi cloud destinati alla PA richiede controlli rigorosi su identità, protezione dei dati in transito e tracciabilità degli accessi, in particolare, le identità di sistema sono gestite impiegando certificati digitali. Anche quando non trovi la parola “mTLS”, l’insieme dei requisiti porta in quella direzione come soluzione coerente e difendibile in audit.
E poi c’è il precedente più evidente: l’open banking e le API dei pagamenti. Lì la mutual authentication con certificati (spesso qualificati) è da anni parte del modello di sicurezza standard. Perché se vuoi fidarti di un client che muove denaro, non gli chiedi “hai un token?”, gli chiedi “fammi vedere chi sei davvero”.
Cosa significa
Per noi questa evoluzione è quasi naturale, perché non stiamo parlando solo di “emettere certificati”, ma di dare identità affidabili alle macchine. E mTLS è il linguaggio con cui queste identità si scambiano fiducia.
In pratica i certificati client abilitano casi d’uso sempre più strategici:
- autenticazione forte delle API interne ed esterne;
- identità per workload cloud-native (Kubernetes, service mesh, microservizi);
- integrazioni macchina-macchina in ambienti regolati (REM, servizi fiduciari, PA, sanità, finance);
- automazione di onboarding, rotazione e revoca su scala.
Questo riduce anche il rischio operativo: meno segreti statici in giro, più controllo centralizzato, più serenità quando arriva l’auditor con la checklist.
Il prossimo passo: crypto-agility e algoritmi quantum-resistant
Mentre il mercato accelera su mTLS, sta entrando in scena un’altra esigenza che non possiamo ignorare. I certificati che usiamo oggi (RSA, ECC) sono solidi contro i computer classici, ma non lo saranno contro computer quantistici sufficientemente potenti. Le istituzioni e gli standard internazionali stanno preparando la transizione post-quantum, e NIST ha standardizzato nel 2024 i primi algoritmi PQC (ML-KEM per key establishment, ML-DSA e SLH-DSA per firme).
Questo significa che chi offre PKI deve iniziare subito a progettare sistemi crypto-agili: CA, profili certificato e stack TLS pronti a integrare algoritmi quantum-resistant o ibridi.
Perché la migrazione non sarà uno switch da un giorno all’altro: sarà una fase lunga in cui conviveranno classico e post-quantum, e chi arriva preparato, con centralizzazione e automazione che rendono agile la transizione, avrà un vantaggio enorme. Non solo tecnico, ma competitivo!
Per maggiori informazioni consulta la nostra pagina dedicata.
In conclusione
Il mutual TLS è diventato il modo più diretto e robusto per garantire che le macchine che si parlano siano davvero chi dicono di essere. È una richiesta che nasce dalla tecnologia cloud-native, ma viene ormai rafforzata anche dalle normative e dalle qualifiche per i servizi fiduciali e per il cloud regolato.
E visto che il futuro prossimo chiede anche algoritmi post-quantum, il tema è gestire identità e fiducia a lungo termine.
Come prepararsi
Se stai progettando (o rivedendo) integrazioni API, service mesh, flussi macchina-macchina in ambienti regolati o servizi cloud qualificati,
come CA e fornitore PKI possiamo aiutarti a:
- definire profili certificato adatti a mTLS,
- automatizzare emissione/rotazione/revoca su scala,
- integrare mTLS nel tuo stack (gateway, mesh, workload identity),
- impostare da subito un percorso crypto-agile e post-quantum ready,
- utilizzare certificati con durate fino a 3 anni per ridurre complessità operativa e incidenti legati alla scadenza.
Ti aiutiamo a far parlare le tue macchine in modo sicuro e verificabile, senza lasciare chiavi in giro.