PKI per VPN senza stress: come creare certificati affidabili da zero senza impazzire

Perché i certificati sono fondamentali nelle VPN del 2026 e perché non sono più una scelta, ma una necessità

Le password non bastano più: come i certificati colmano le lacune

Le password si esauriscono. Le persone si stancano. Abbiamo visto tutti le stesse cose: password condivise nelle configurazioni, screenshot nelle chat, biglietti appiccicati al monitor. Nel 2026, le password, anche abbinate ai codici SMS, non bastano più contro il phishing e gli attacchi MFA fatigue. Il certificato invece non si può spiare né rubare con uno screenshot. È legato al dispositivo, protetto da una chiave e, se configurato correttamente, anche da hardware dedicato (TPM o smart card). È una barriera reale, non una mera illusione di sicurezza.

Nel contesto VPN i certificati assicurano un'autenticazione reciproca (mTLS). Non ci fidiamo solo del server, ma il server verifica anche il client. Non si tratta di “chi conosce la password”, ma di “chi possiede la chiave legittima e un certificato emesso da noi”. È il fondamento del Zero Trust e un modo pratico per ridurre il rischio di hijacking delle sessioni.

Regolamentazioni, Zero Trust e sicurezza centrata sul dispositivo

La tendenza del 2026 è il passaggio de facto a controlli senza password (passwordless) e l’autenticazione vincolata al dispositivo. PKI per VPN si inserisce perfettamente in questo trend. Certificati sui dispositivi, emissione tramite MDM, durata breve, rotazione automatica — così non abbiamo solo un “accesso tramite tunnel”, ma un accesso contestuale nel quadro Zero Trust. I regolatori nei settori finanziario, infrastrutture critiche e governativo richiedono direttamente audit, rotazione, revoca e verifica dello stato. PKI risponde a queste esigenze.

Dove si applica: OpenVPN, IPsec/IKEv2, SD-WAN e SASE

I certificati sono utilizzabili in OpenVPN (TLS), IPsec/IKEv2 (scambio di certificati, EAP-TLS), nelle piattaforme corporate SD-WAN e SASE. WireGuard non usa nativamente X.509, avendo proprie chiavi, ma i certificati sono spesso necessari per il control-plane, il portale di configurazione e la gestione dei dispositivi. Insomma, in 9 casi su 10 negli scenari aziendali PKI è il lavoro quotidiano, non un esercizio accademico.

Basi di PKI per VPN spiegate semplice

Cosa è X.509 e quali campi sono critici per VPN

Il certificato X.509 è come un passaporto per server o client. Contiene il Subject, estensioni come Subject Alternative Name (SAN) con nomi host o IP, Key Usage e Extended Key Usage. Per la VPN ci interessano soprattutto SAN (DNS e IP), EKU (ClientAuth per client, ServerAuth per server), e campi come CRL Distribution Points e Authority Information Access per OCSP.

Importante ricordare: il CN da tempo non è più il riferimento principale per verificare il nome del server, i client si affidano al SAN. Se dimentichiamo il SAN, rischiamo rifiuti di connessione o eccezioni brutte da gestire. Perciò inseriamo subito i SAN corretti, incluso DNS e indirizzi IP.

Gerarchia: Root CA e Intermediate CA

La Root CA è il nostro “organismo sovrano” che non si fida di nessuno tranne che di se stessa, firmando solo gli intermediate. La teniamo offline, come un gioiello di famiglia, chiusa a chiave, e le chiavi dove possibile in HSM. L’Intermediate CA funziona online, emettendo certificati a server e client. Così riduciamo il rischio: anche se l’intermedio viene compromesso, la Root rimane intatta.

Algoritmi: RSA, ECDSA e quando usare Ed25519

Nel 2026 le scelte sicure e pratiche sono RSA 3072 o 4096 bit ed ECDSA P-256/P-384. RSA è universale, soprattutto per client più datati. ECDSA è più veloce e meno dispendioso in CPU. Ed25519 è amato da sviluppatori e sistemi moderni, ma non tutti gli stack VPN e strumenti PKI lo supportano bene in X.509, anche se per alcuni scenari è ottimo. In sintesi, ECDSA P-256 per sistemi nuovi, RSA 3072 per retrocompatibilità.

mTLS: verifica reciproca senza complicazioni

Nel mTLS il server presenta il suo certificato al client, e il client fa lo stesso al server. Assicuriamo di comunicare con il nostro gateway VPN e permettiamo solo i dispositivi con i certificati client autorizzati. Sembra semplice ma ha un impatto enorme: le password perse non sono più critiche, perché senza la chiave non si possono generare token di accesso.

Progettare PKI: dalla policy di naming a scadenze e revoca

Policy di naming, SAN e audit

Descriviamo in anticipo come devono chiamarsi server e dispositivi nei certificati, quali domini e IP verranno inseriti nel SAN, come distinguere certificati di test da quelli di produzione. La nomenclatura deve essere prevedibile. Per esempio: vpn-gw-eu-1.corp.example, vpn-gw-us-2.corp.example. Per i client includiamo l’identificativo del dispositivo, UPN degli utenti o device ID da MDM. Più chiara la policy, più semplice l’automazione e l’audit.

EKU e Key Usage per evitare confusione ai client

Per i server impostiamo EKU ServerAuth. Per i client, ClientAuth. Nei Key Usage mettiamo Digital Signature (e a volte Key Encipherment per RSA). Per IKEv2 ci possono essere requisiti speciali, come IPsec IKE Intermediate su alcuni stack. Mantenere coerenza è essenziale, altrimenti alcuni client diventano capricciosi.

Durata: equilibrio fra sicurezza e operatività

Raccomandazioni 2026: durata Root CA 10–20 anni ma offline. Intermediate CA 3–5 anni. Certificati server 6–12 mesi per limitare i rischi e spingere l’automazione. Client 3–12 mesi a seconda di maturità MDM e preparazione alla rotazione automatica. Durate brevi sono il nostro “pilota automatico di sicurezza”, se c’è automazione.

CRL e OCSP: come evitare trappole

La revoca è il cuore della gestione. CRL è semplice e affidabile se aggiornata spesso e non troppo grande. OCSP è un controllo online rapido. Nel mondo VPN i client non sempre verificano OCSP di default, ma molti lo supportano. Fondamentale è la resilienza: se OCSP non è disponibile, non vogliamo bloccare tutto a caso. Configuriamo un failover ragionevole e monitoriamo le metriche.

Implementare CA: root offline e intermediate online

Generazione chiavi: HSM, TPM o software

L’ideale è HSM per root e intermediate CA. La realtà? Budget. Se HSM non è disponibile, almeno macchina offline senza rete, chiavi cifrate, backup multipli e separazione accessi. TPM è buono per server con chiavi di certificati server, ma per CA meglio dispositivi protetti dedicati. Compromesso sensato: root in HSM o offline con gestione sicura dei segreti, intermediate in HSM o strumenti come Vault con supporto hardware.

Strumenti: OpenSSL, step-ca, CFSSL, AD CS

La scelta strumenti dipende dalla maturità del team. OpenSSL è universale ma richiede cura e template. step-ca di smallstep semplifica ACME e automazione. CFSSL è comodo per emissione programmatica. AD CS è valido se si è profondamente in ambiente Windows con MDM/Intune. Nel 2026 si sceglie spesso un mix: root offline con OpenSSL, intermediate online con step-ca o Vault PKI, integrazioni via ACME, EST o SCEP.

Conservazione e rituali di sicurezza

Chiave root offline. Conservazione su supporti cifrati, segreto diviso in parti (Shamir), cassaforte fisica, log delle cerimonie di emissione intermediate. Suona paranoico? È giusto così. La compromissione della root è la “fine del mondo” per la fiducia. L’intermediate è il cavallo da lavoro: lo proteggiamo, monitoriamo e doubleggiamo.

Certificati server per gateway VPN

OpenVPN: SAN, tls-crypt-v2 e OCSP affidabile

Per OpenVPN sono importanti SAN con DNS e IP del gateway, EKU ServerAuth, keyUsage corretto. Attiviamo tls-crypt-v2 o almeno tls-auth per proteggere da scansioni e DoS malevoli. Supporto OCSP c’è ma dipende da versione e client; se attiviamo OCSP testiamo il failover. Durata certificato 6–12 mesi, automatizziamo con ACME o script con accesso sicuro alle chiavi.

IPsec/IKEv2: identificatori e profili rigorosi

In IKEv2 è cruciale impostare correttamente gli identificatori: FQDN, formato email o IP. I certificati server devono avere i valori corretti nel SAN, altrimenti i client (specialmente mobili) si lamentano. Supporto a CRL e OCSP in strongSwan e implementazioni simili è robusto. Controlliamo in anticipo EKU e Key Usage nelle documentazioni stack per evitare sorprese.

Cloud, SD-WAN e SASE

Le moderne piattaforme SASE spesso supportano integrazione con CA private: importazione root e intermediate, emissione via API, sincronizzazione CRL/OCSP. Progettiamo la zona di fiducia: quali PoP usano la nostra CA, come diffondiamo gli aggiornamenti, chi gestisce la rotazione. In più monitoraggio: metriche emissioni e errori per evitare cadute di massa notturne.

Certificati client: utenti, dispositivi, MDM

Device aziendali vs BYOD

Sui dispositivi aziendali è semplice: MDM installa profilo, genera chiave nel keystore della piattaforma, richiede certificato, configura VPN e rotazione. In BYOD è più complesso: policy privacy, consenso utente, limiti permessi. A volte conviene emettere certificati a vita breve con restrizioni rigide e controllare accesso tramite segmentazione.

Windows, macOS, iOS, Android, Linux

In Windows usiamo Intune o AD GPO/NDES (SCEP). Su macOS e iOS MDM (Jamf, Kandji, Mosyle, Intune). Android Enterprise via profili EMM con certificati e config VPN. Linux tramite gestori config e secret manager, o agenti step-ca/Vault. Regola: generare chiavi sui dispositivi, non trasmettere chiave privata in rete, e specificare EKU/Key Usage precisi.

Smart card, token e PIV

Per aree sensibili ottime smart card e token (YubiKey, PIV). Le chiavi non sono estraibili, la firma avviene sul dispositivo. Contro: costi operativi e logistica. Pro: affidabilità e conformità audit. Per VIP e admin quasi indispensabile.

Revoca e controllo stato: CRL e OCSP senza problemi

CRL: semplice se fatto bene

CRL è ottimo se pubblicato frequentemente (es. ogni 2–6 ore), mantenuto piccolo (archiviazioni, CRL separati per profili), distribuito via CDN o caching. La dimensione conta: CRL troppo grande penalizza la latenza, soprattutto su mobile.

OCSP: rapido, ma serve alta disponibilità

OCSP fornisce uno stato “live”, ma richiede un servizio altamente disponibile. Anycast/IP-balance, scaling orizzontale, caching aggressivo e SLO chiari sono indispensabili. Nei client VPN OCSP non è sempre attivato di default, quindi verifichiamo e documentiamo comportamento client e fallback.

Fail-open o fail-closed

Idealmente la sicurezza preferisce fail-closed: nessuna risposta OCSP = negazione. Ma la VPN è critica. Spesso scegliamo un fail-open morbido per gli utenti remoti, compensando con monitoraggio e certificati a breve scadenza. Compromesso onesto: meno downtime, ma controlli vigili.

Rotazione e automazione: ACME, SCEP, EST, GitOps

ACME per certificati server VPN

ACME ha superato il campo web pubblico. Nel 2026 CA ACME private (step-ca, Vault ACME, simili) offrono emissione e rotazione automatiche di certificati server. Agenti sui gateway aggiornano certificato poche ore prima della scadenza, riavviano servizi, inviano metriche a monitoraggio. Stabile, prevedibile, senza magie manuali.

Automazione client: SCEP e EST

SCEP è popolare in MDM: semplice, non perfetto in sicurezza, ma con policy e limiti funziona. EST è più moderno: più sicuro, supporta aggiornamento chiavi, più aderente a Zero Trust. Strumenti come EJBCA, AD CS via NDES, step-ca con plugin EST e piattaforme PKI commerciali offrono connettori pronti per MDM (Intune, Jamf, MobileIron ecc.).

GitOps per PKI e Terraform

Infrastructure as code in PKI non è uno scherzo. Policy, ruoli, profili, indirizzi CRL/OCSP, routing — tutto in repo, revisionato, testato e promosso tra ambienti. Provider Terraform per Vault, operator Kubernetes per step-ca, Ansible per integrazioni — garantiscono reproducibilità. Addio errori da “modifiche fatte il venerdì sera”.

Osservabilità: metriche, SLO e alert

Misuriamo: percentuale certificati con scadenza entro N giorni, tempi risposta OCSP, dimensioni CRL, errori emissione, numero revoche, quota client senza verifica stato. SLO: 99,9% disponibilità OCSP, max 1% certificati a 7 giorni dalla scadenza, zero interventi manuali sulle rotazioni. Alert solo utili, niente spam.

Sicurezza e compliance: niente noia, solo sostanza

Audit e integrità dei log

Ogni emissione, revoca, modifica policy va nel log. Logs firmati, conservati in archivi WORM o protetti da modifiche. Verifiche periodiche, audit esterni, report per ISO 27001 o SOC 2 — aumentano fiducia. E sì, in caso di incidente fanno risparmiare tempo e reputazione.

Separazione dei compiti e principio delle 4-occhi

Nessuno deve avere il controllo totale. Dividiamo ruoli: emissione, approvazione, revisione. Operazioni critiche richiedono due pareri. Nelle cerimonie CA è un principio chiave: meno tentazioni, meno errori, sonno più sereno.

Standard e requisiti

Seguiamo NIST 800-53 e 800-63 (livelli autenticazione), ISO 27001, PCI DSS per settore finanziario, normative dati personali (GDPR, 152-ФЗ). Buone notizie: mTLS e PKI gestita coprono metà delle checklist. Cattive? Bisogna documentare. Ma sappiamo farlo, vero?

Performance e resilienza

TLS 1.3 e risparmio CPU

TLS 1.3 riduce overhead. In OpenVPN e soluzioni basate su TLS è un vantaggio evidente. In IKEv2 si lavora su crypto-profile e suite cipher. Attiviamo AEAD moderne (ChaCha20-Poly1305 per dispositivi senza AES-NI, AES-GCM per server con accelerazione hardware). Risultato: più client sullo stesso hardware.

Accelerazione hardware: AES-NI, QAT

Se abbiamo un perimetro grande con migliaia di connessioni, usiamo AES-NI, QAT, talvolta schede di rete specializzate. Cloud? Controlliamo che i tipi di istanze supportino le istruzioni necessarie. Altrimenti i soldi volano e la CPU soffre.

CRL/OCSP potenziati

OCSP e CRL sono servizi. Li rendiamo distribuiti: Anycast, geo-replica, CDN per CRL. Controllo cache rigoroso per evitare troppe richieste backend. E test di carico prima del lancio.

Testing e Chaos Engineering

Simuliamo cadute OCSP, ritardi CRL, certificati scaduti. Osserviamo comportamenti client. Addestriamo on-call: dove cliccare, cosa riavviare, come passare a modalità degradata. Esercitazioni imperfette risparmiano nervi in produzione.

Transizione post-quantistica e futuro PKI VPN

Certificati ibridi e realtà 2026

Cripto post-quantistica si sta sviluppando. Nel 2026 molte aziende sperimentano schemi ibridi: classico + PQC (es. Kyber con ECDSA per TLS), ma supporto universale nei VPN stack è ancora lontano. Il piano è semplice: seguire standard, inserire possibilità di migrazione rapida, scegliere strumenti con roadmap PQC, testare in pilota.

Chiavi legate al dispositivo e attestazione

Tendenza: chiavi vincolate al dispositivo (TPM/TEE) più attestazione dello stato. Per VPN significa: non basta avere un certificato. Serve un’etichetta trusted che confermi che il device è sano, non jailbroken e non compromesso. Alza la sicurezza e riduce rischi BYOD.

Casi reali: senza fronzoli né slogan

Migrazione da password condivisa a mTLS su OpenVPN

Piccola impresa, 120 utenti. C'era una password comune, lamentele continue su “qualcuno usa la mia sessione”. Piano: implementato step-ca, root offline su OpenSSL, intermediate in Docker con backup, agente ACME sul gateway. Certificati client distribuiti con utility semplice e guida, durata 6 mesi. In due settimane migrati 90% utenti, poi dismessa la vecchia soluzione. Risultato: zero reclami per sostituzione, log emissione e revoca trasparenti. Costo: qualche sera di lavoro ingegneristico, senza spese extraterrestri.

Industria: IKEv2, smart card e audit rigoroso

Fabbrica con requisiti audit, 800 utenti, molte sedi remote. Soluzione: IKEv2 con certificati client su smart card per operatori di sistemi critici, per gli altri chiavi software a breve termine. CRL aggiornato ogni 4 ore, OCSP su Anycast. Root su HSM, intermediate in cluster Vault. Esito: stabilità, conformità e zero multe da regolatori.

Antipattern: cosa evitare

Root CA online (orrore), CRL su server unico morente (VPN cade di domenica), certificati da 5 anni (dimenticati, scaduti, guasto), chiavi private in repository (lo sappiamo tutti), mancata rotazione (tutto si rompe insieme). Semplice: non lo facciamo mai. Mai.

Checklist e piano chiaro

30-60-90 giorni: roadmap

Primi 30 giorni: definire requisiti, scegliere strumenti (OpenSSL + step-ca/Vault/AD CS), descrivere policy (SAN, EKU, durate), preparare root offline. Successivi 60: deploy intermediate, automatizzare certificati server via ACME, integrare MDM client, configurare CRL/OCSP e monitoraggio. A 90 giorni: pilotare, formare supporto, migrare tutti, disattivare vecchi metodi login.

Piano rotazione senza paura

Rotazione automatica server 14 giorni prima scadenza, client 7 giorni. Buffer di una settimana, alert, dashboard. Zero interventi manuali — KPI del team. Scenario recovery: se l’agente cade, richiesta manuale con logging e registrazione motivazione.

Compromissione CA: succede anche questo

Se compromesso intermediate: revoca immediata, nuova CRL pubblicata, nuovo intermediate emesso, rinnovo certificati server e client, comunicazione utenti. Se root colpito — più grave: cerimonia completa sostituzione, nuove catene trusted, ricalcolo certificati. Doloroso ma gestibile con piano pronto.

Pratica: avvio rapido fai-da-te

PKI minimamente funzionale

Root offline su OpenSSL, intermediate su step-ca, pubblicazione CRL in storage compatibile S3 con CDN, OCSP integrato in step-ca, agenti ACME su VPN gateway. MDM client (Intune o Jamf), profili EST/SCEP. Terraform per configurare step-ca e infrastruttura pubblicazione, alert via Prometheus e Slack. Semplice ed efficace.

Migliorie per team maturi

HSM per chiavi CA, separazione ruoli, log firmati, GitOps con più ambienti, test carico OCSP, profili ibridi per PQC futuro, chiavi legate a TPM su server. Team piattaforma dedicato o pool SRE condiviso, SLO chiari, game day regolari.

Errori comuni e come correggerli

SAN e EKU errati

Assenza SAN fa si che i client si lamentino. EKU sbagliato impedisce al server di partire o il client di connettersi. Soluzione: template e test. Non emettiamo nulla senza validazione profili.

Durate lunghe e assenza automazione

Certificati pluriennali sono allettanti ma rischiosi. Vogliamo sicurezza: durate brevi e automazione. Altrimenti si rischiano fallimenti di massa.

OCSP/CRL come unico punto di failure

Costruiamo tutto come servizio completo: replica, cache, monitoraggio. E testiamo in anticipo i comportamenti client in caso di guasti.

FAQ: sintetico e chiaro

Posso usare un certificato unico per tutti i client?

Tecnica sì, ma praticamente no. La perdita di una chiave compromette tutti. Certificati unici funzionano con revoca e audit trasparente. Uno solo per tutti è strada sicura per i guai.

Meglio RSA o ECDSA?

Se serve compatibilità ampia, RSA 3072. Client moderni e prestazioni importanti? ECDSA P-256. In ambienti misti si usano entrambi su gateway diversi.

Serve OCSP se ho CRL?

CRL è sufficiente se aggiornata spesso e disponibile ovunque. OCSP accelera verifica, ma richiede infrastruttura resistente. Meglio avere entrambi con configurazioni intelligenti di fallback.

Con che frequenza cambiare certificati client?

3–12 mesi è ideale. Con automazione matura 3–6 mesi. Durata breve riduce rischi e semplifica risposta incidenti. L’automazione fa la differenza.

E WireGuard con certificati?

WireGuard non usa X.509 nei tunnel, ha un modello chiavi proprio. Ma PKI serve spesso per controllo accessi a configurazioni, portali e device. In reti miste PKI resta essenziale.

Conviene passare subito al post-quantistico?

Prepararsi sì. In produzione su tutto il perimetro è presto per la maggior parte. Si fanno piloti, si scelgono strumenti con roadmap, si monitora compatibilità VPN. È questione di prontezza, non fretta.

Una piccola squadra può automatizzare tutto?

Sì. Si parte con step-ca e ACME, si integra MDM con EST/SCEP, si terraforma l’infrastruttura. In pochi sprint si raggiunge il pilota automatico, addio rinnovi manuali. Sembra complesso, ma è più semplice di quanto sembri.