Ultimo aggiornamento: 15 settembre 2025

Negli ultimi trent’anni, i certificati digitali (X.509) sono gradualmente diventati parte dell’infrastruttura critica, con le aziende che si affidano a essi per sostenere le attività essenziali. Tuttavia, poiché l’adozione dei certificati digitali si è ampliata incrementando col tempo, molte organizzazioni non hanno adottato le best practice; la gestione dei certificati continua spesso in modo informale, senza supervisione e controllo centralizzati. Questo comporta maggiori rischi per il business, esposizioni di sicurezza sconosciute e frequenti interruzioni di servizio.

Questo documento è strutturato come segue: nella prima parte esamineremo gli strumenti di gestione del ciclo di vita dei certificati (CLM) e le loro funzionalità. Discuteremo delle PKI private e pubbliche, inclusi vantaggi e svantaggi. Nella seconda parte vedremo un programma CLM suddiviso in passi, applicabile ad aziende di ogni dimensione. Seguendo questo programma, potrai acquisire il controllo sul patrimonio di certificati digitali, partendo dalle basi fino a raggiungere visibilità, controllo, automazione e implementazione delle best practice di sicurezza.

La gestione del ciclo di vita dei certificati è un processo completo per la gestione dei certificati digitali lungo tutto il loro ciclo di vita. È un aspetto fondamentale della sicurezza informatica, che garantisce identità digitali sicure e comunicazioni affidabili per un’organizzazione. Un programma CLM di successo deve rispondere a due principali esigenze: 1) aiutare a scoprire e monitorare i certificati dell’organizzazione e 2) fornire supporto operativo per tutte le operazioni sui certificati, inclusa l’automazione dell’emissione, della distribuzione, della rotazione e della revoca.

Le attività legate alla gestione dei certificati sono meglio comprese all’interno del più ampio contesto della governance della crittografia. Scoperta e inventario della crittografia sono due iniziative strettamente intrecciate con la gestione del ciclo di vita dei certificati. Il CLM va inteso come un programma continuo, pensato per soddisfare le esigenze organizzative di disponibilità, conformità e sicurezza.

La gestione del ciclo di vita dei certificati è una funzione necessaria per la maggior parte delle imprese, ma oggi ci sono due grandi forze che richiedono un’azione immediata:

• Durata ridotta dei certificati: nel settore delle PKI pubbliche, la validità dei certificati sta per essere ridotta dall’attuale massimo di un anno, prima a 200 giorni a marzo 2026, poi a 100 giorni a marzo 2027, fino a soli 47 giorni a marzo 2029. Se il rinnovo non viene automatizzato, questi cambiamenti comporteranno un aumento dei costi operativi legati ai rinnovi e la maggiore probabilità di interruzioni di servizio. Approfondisci questi cambiamenti nel nostro post sul blog sull’argomento.
• Migrazione post-quantistica: la minaccia all’orizzonte rappresentata da computer quantistici rilevanti richiede l’abbandono degli algoritmi crittografici a chiave pubblica oggi in uso. Il consenso generale è che la migrazione delle proprietà importanti dovrà essere completata nei prossimi cinque anni.

La Public Key Infrastructure (PKI) è un sistema per la gestione delle identità digitali. Un’identità digitale si basa su una chiave privata, che ne rappresenta l’essenza, e sul relativo certificato che include la chiave pubblica associata insieme ai metadati. Le identità, insieme alle regole di emissione, uso, revoca e altre operazioni, costituiscono una PKI.

Una PKI viene solitamente creata e progettata per soddisfare una specifica esigenza. In effetti, è buona norma separare le PKI che non condividono casi d’uso sovrapposti, poiché ciò migliora la sicurezza tramite compartimentazione.

Alcune PKI sono destinate a collaborazioni tra organizzazioni e vengono chiamate pubbliche. Se una azienda crea una PKI solo per i propri scopi, si parla allora di PKI privata. La differenza principale è che, nelle PKI pubbliche, esiste di solito una struttura di governance separata; tutti i partecipanti devono rispettare le stesse regole. Nelle PKI private, invece, chi le crea e le utilizza ha pieno controllo e può personalizzarle per le proprie esigenze.

• Progettate per l’interoperabilità tra organizzazioni.
• Governance indipendente; tutti devono rispettare le stesse regole.
• Gran parte delle attività è svolta da terzi, come i root program e le CA.
• I cambiamenti sono lenti e spesso coinvolgono logiche politiche o attese per i partecipanti meno rapidi.

• Pensate per l’uso interno a una organizzazione.
• Controllo totale sulla progettazione e operatività della PKI.
• Richiedono più sforzi di implementazione per coprire ogni aspetto della PKI.
• Permettono di procedere al ritmo dell’organizzazione.

Esistono diverse PKI pubbliche di interesse. Internet PKI indica il sistema globale che protegge Internet. In questo sistema, i certificati digitali vengono rilasciati per validare le connessioni tra i partecipanti alla rete, generalmente utilizzando il protocollo Transport Layer Security (TLS). La Web PKI è una sottocategoria dell’Internet PKI ed è destinata solo ai browser, adattata alle loro esigenze. Le due PKI si sovrappongono e i termini sono spesso usati come sinonimi. La S/MIME PKI è progettata per la protezione delle comunicazioni email e segue regole differenti.

Queste PKI pubbliche sono gestite principalmente dai principali root program, come quelli di Apple, Chrome, Microsoft e Mozilla. I root program stabiliscono le regole e scelgono quali CA possono partecipare. Inoltre, il CA/Browser Forum è un ente industriale che regola alcuni aspetti tecnici delle PKI pubbliche.

Le caratteristiche chiave sono le seguenti:

• Partecipazione aperta a tutti
• Emissione basata sulla prova di controllo dell’infrastruttura
• Le durate brevi dei certificati impongono di fatto l’automazione
• I certificati sono per lo più gratuiti
• Tutti i certificati sono registrati in log pubblici
• Crittografia debole non ammessa
• Profili di certificato predefiniti
• Opzioni limitate di controllo della revoca

Il vantaggio principale delle PKI pubbliche è che sono gestite da grandi organizzazioni globali, per cui il costo della partecipazione è basso o nullo. Questo garantisce interoperabilità, ma limita la flessibilità. In molti casi, questo compromesso funziona, soprattutto ora che i certificati pubblici sono disponibili gratuitamente. Anche le grandi aziende spesso usano certificati pubblici anche per le proprie infrastrutture interne.

Tuttavia, alcuni casi d’uso rendono le PKI pubbliche troppo limitanti:

• Mancanza di autenticazione forte all’emissione 
• Nessun controllo sulla durata dei certificati
• I certificati rivelano informazioni sulle infrastrutture private
• Nessun supporto per certificati client o dispositivi
• Nessun supporto per firma di codice o documenti
• Nessun supporto per profili di certificato personalizzati
• Emissione certificati soggetta a limiti di velocità
• Opzioni limitate per i protocolli di emissione
• Adozione lenta dei nuovi standard (es. crittografia post-quantistica)

A seconda del caso d’uso, delle competenze e dei budget disponibili, un’organizzazione può scegliere di realizzare e gestire una PKI internamente, oppure affidarsi a soluzioni gestite offerte da fornitori cloud e autorità di certificazione.

Abbiamo stabilito che i certificati vengono creati nelle rispettive PKI. Grazie al protocollo Automated Certificate Management Environment (ACME), oggi ampiamente diffuso, i server possono ottenere certificati automaticamente comunicando con la CA preferita. Questa modalità viene adottata sia da piccole sia da grandi aziende.

Alcune organizzazioni che desiderano più controllo o visibilità possono scegliere di utilizzare strumenti di gestione del ciclo di vita dei certificati. Ad esempio, un’organizzazione che desidera monitorare le proprie attività può adottare un prodotto CLM che fornisca funzionalità di discovery e monitoraggio.

Le aziende più grandi possono affidarsi a uno o più strumenti CLM per garantire emissione centralizzata e maggiore controllo su CAs utilizzate nei diversi contesti, soprattutto se gestiscono PKI private per le infrastrutture interne. 

Come per qualsiasi altra iniziativa, la chiave per avviare un programma CLM di successo è comprendere i bisogni aziendali sottostanti. Ad esempio, valuta i seguenti bisogni di sicurezza e compliance:

• Gestione del rischio e governance; ottenere visibilità su tutti i certificati emessi come base per un controllo rigoroso ed efficace.
• Requisiti normativi e conformità; garantire che i certificati rispettino tutte le normative applicabili.
• Maggiore sicurezza; controllare le implementazioni dei certificati per assicurare l’uso di crittografia abbastanza robusta.
• Agilità crittografica; supportare la capacità dell’organizzazione di identificare gli asset crittografici e migrare rapidamente verso nuovi algoritmi quando necessario. 
• Migrazione crittografia post-quantistica; come esigenza immediata e pressante, sostenere gli sforzi aziendali a migrare dalla crittografia a chiave pubblica vulnerabile.
• Riduzione dei costi e rating di sicurezza; ridurre i costi tramite l’uso di certificazioni “in policy”. Inoltre, migliorare la visibilità pubblica della sicurezza aziendale può portare a costi ridotti per le assicurazioni cyber.

Per quanto riguarda le esigenze operative, sono meno numerose, ma richiedono esecuzione impeccabile perché gli errori possono causare downtime:

• Automazione: comunicare con le autorità di certificazione (CA) approvate per ottenere l’emissione dei certificati, poi distribuirli, ruotarli e revocarli secondo necessità.
• Disponibilità e interoperabilità; assicurare che i certificati siano idonei agli scopi e soddisfino requisiti di interoperabilità, prestazioni e resilienza.
• Prevenzione delle interruzioni di servizio e disponibilità: minimizzare le interruzioni monitorando i certificati implementati per scadenza, revoca inattesa e altri problemi di disponibilità.

Dato che il mondo PKI è complesso, non sorprende che esistano molteplici strumenti CLM e PKI, ciascuno pensato per soddisfare casi d’uso specifici, senza che esista uno strumento che faccia tutto. Le funzionalità ricadono di solito in una delle seguenti categorie:

• Semplice automazione dell’emissione; strumenti che automatizzano emissione e rinnovo agendo direttamente sull’infrastruttura che utilizza i certificati. Di norma sono implementati tramite ACME e sono sempre più integrati nei server.
• Prodotti PKI privati; strumenti per creare e amministrare PKI private, self-hosted o gestiti, spesso offerti da grandi fornitori cloud o CA.
• Discovery e visibilità; strumenti per costruire l’inventario dei certificati e fornire piena visibilità di quelli aziendali, incluso il loro utilizzo e la posizione.
• Automazione del ciclo di vita; strumenti per l’orchestrazione avanzata dell’emissione, progettati per integrarsi con varie PKI pubbliche e private. Per abilitare opzioni avanzate, questi strumenti forniscono plugin per l’integrazione con molte piattaforme e software server.
• Monitoraggio dei certificati; alcune funzionalità di monitoraggio sono spesso incluse negli strumenti pensati principalmente per la sicurezza delle reti, la disponibilità e la gestione IT.

Quando si decide quali strumenti adottare, si parte dagli obiettivi, si valutano le funzionalità offerte dai vari vendor e si scelgono quelli che meglio rispondono alle proprie esigenze.

Con la diffusione di ACME, aumentano gli strumenti per emissione e rinnovo automatico dei certificati. È sempre più comune trovare funzionalità ACME integrate in server e appliance, rendendo la gestione più semplice. Se non già oggi, a breve quasi tutti i software che usano certificati supporteranno nativamente ACME, facilitando le attività base di gestione.

L’automazione semplice può essere spesso sufficiente, ma non copre l’intero ciclo di vita. Alcune operazioni, come cambiare CA o sostituire certificati prima della scadenza, dovranno essere manuali.

I prodotti CLM che implementano l’automazione completa possono offrire queste capacità di base già pronte, tramite ACME o plugin di integrazione proprietari. Così, la scelta è se affidarsi all’automazione semplice, correggendo manualmente quando serve, oppure optare per un’automazione completa con più lavoro iniziale, ma minor manutenzione futura. Se si preferisce la piena automazione, è bene verificare che il CLM scelto supporti l’integrazione con piattaforme e software utilizzati. Si consiglia di iniziare con un proof-of-concept rappresentativo prima di impegnarsi a fondo.

Trovare i giusti strumenti per sostenere un programma CLM può essere difficile, viste le molteplici funzionalità disponibili, e spesso non basta uno strumento solo. Quando si definiscono i criteri di valutazione, considera se gli strumenti scelti permettono di rispondere a queste domande:

• Abbiamo un inventario completo di tutti i certificati?
• Tutti i certificati sfruttano una crittografia robusta?
• Quali CA vengono utilizzate?
• Le CA sono impiegate correttamente nei diversi contesti?
• Dove sono installati i certificati sulle nostre reti?
• I certificati e i protocolli sono distribuiti in modo corretto e sicuro?
• Utilizziamo l’accordo di chiavi post-quantistico sulle proprietà importanti?
• I certificati vengono emessi e rinnovati in automatico?
• Siamo in grado di ruotare i certificati a richiesta?
• Siamo pronti a gestire revoche impreviste?
• Chi emette i nostri certificati e dove?
• Quali terzi emettono certificati per nostro conto?
• Sono stati emessi certificati fraudolenti a nostro nome?

Nella seconda parte di questo documento forniamo una guida passo passo per un programma di gestione dei certificati che ti consentirà di prendere il controllo della PKI pubblica. Essenzialmente, la gestione del ciclo di vita dei certificati e della PKI si riduce a tre step:

1. Stabilire il controllo della PKI pubblica
2. Gestione ed evoluzione delle PKI private 
3. Implementazione di uno o più CLM per l’automazione completa

Abbiamo impostato questo programma osservando che tutte le organizzazioni partecipano al PKI pubblico, ma poche hanno sufficiente visibilità e ancora meno controllano davvero l’emissione certificati per i loro domini. Tuttavia, questa attività può essere affrontata separatamente e completata rapidamente rispetto alle altre. Prendendo il controllo della PKI pubblica, costruirai conoscenza preziosa che ti consentirà di capire le tue necessità reali e prendere decisioni informate su PKI private e automazione certificati.

La prossima riduzione della validità dei certificati a meno di un anno ti richiede di focalizzarti con urgenza sui tuoi certificati pubblici. Con il primo passaggio a 200 giorni ormai vicino (marzo 2026), dovrai agire in fretta o affrontare un notevole aumento del carico di rinnovi manuali.

Inizia elencando i tuoi requisiti e obiettivi. Nessun ambiente è uguale a un altro, tantomeno sul tema PKI. Nella prima parte abbiamo illustrato diversi obiettivi comuni. Ora valuta ciascun obiettivo e definiscine la priorità. Questo ti aiuterà a dare un contesto alle decisioni successive.

Inoltre, i trend di settore e la regolamentazione influenzeranno pesantemente la priorità delle tue attività. Analizza le normative di riferimento per capire gli adempimenti richiesti. La crittografia è una priorità negli ultimi anni ed è ormai all’ordine del giorno. DORA, NIS2, NIST, FIPS, PCI DSS, HIPPA e altri impongono requisiti stringenti su crittografia e gestione delle chiavi. Il mondo sta affrontando la transizione verso la crittografia post-quantistica, con molto da fare e scadenze ravvicinate; scopri cosa è necessario fare e quando.

Il vantaggio delle Internet PKI è che offrono visibilità totale sui certificati, molto più facilmente di quelle private. Questo è merito del sistema Certificate Transparency (CT): raccoglie e pubblica tutti i certificati pubblici per auditing e monitoraggio. Tecnicamente, CT non sarebbe obbligatorio, ma poiché Apple, Google e Microsoft lo richiedono per riconoscere valida una certificazione, praticamente tutti i certificati sono conformi.

Con lo strumento giusto, puoi ottenere visibilità completa praticamente istantanea su tutti i certificati pubblici, sfruttando database aggiornati dai vendor specializzati. Partendo da una lista di domini aziendali, il discovery tramite CT setaccia miliardi di certificati, trovando quelli corrispondenti anche a sottodomini. Red Sift Certificates è il nostro prodotto che svolge questa funzione.

La facilità del Certificate Transparency rivela spesso un altro problema, ossia che molte organizzazioni non dispongono di una lista completa dei propri domini. In molte delle realtà con cui abbiamo lavorato, queste liste vengono compilate di volta in volta, con grande dispendio di tempo e risorse.

Per risolvere, puoi affiancare al CLM strumenti per il discovery automatico dell’infrastruttura. Questi strumenti sono noti come Attack Surface Monitoring o ASM. Partendo da una lista di domini iniziali forniti dal cliente e sfruttando database basati sull’osservazione di tutta l’infrastruttura mondiale, questi prodotti mantengono aggiornata la lista delle risorse aziendali. L’integrazione con fonti ufficiali—come registrar di dominio, provider DNS e CA—garantisce la completezza dell’inventario. Abbiamo integrato il discovery automatico in Red Sift Certificates per agevolare i clienti.

Risultati desiderati:

• Elenco completo dei domini registrabili di proprietà aziendale
• Sincronizzazione automatica dei domini dalle fonti ufficiali
• Enumerazione continuativa di tutti i sottodomini
• Scoperta costante di nuovi domini registrabili
• Inventario esaustivo dei certificati pubblici emessi
• Report sugli enti certificatori e sulle criticità dei certificati

Avere l’inventario completo è solo l’inizio: il vero vantaggio deriva dal sapere dove e come vengono utilizzati. Serve quindi un monitoraggio attivo per determinare posizione e info di ciascun certificato installato.

• Monitoraggio di domini e sottodomini: partendo dall’inventario, il tool esegue scansioni continue sugli indirizzi IP pertinenti ai domini. Questo copre di fatto tutti i servizi pubblici.
• Riconfigurazione del firewall: alcuni servizi possono funzionare su infrastrutture pubbliche senza essere accessibili pubblicamente. Consentire l’accesso allo strumento tramite firewall aumenta la visibilità con minimo sforzo.
• Monitoraggio di range IP statici: scansionare le range di rete in uso esclusivo aziendale può aiutare a scoprire domini sfuggiti al monitoraggio o servizi esposti sugli IP privi di dominio associato. Idealmente, la scansione dev’essere agentless (gestita) per ridurre il carico di lavoro.
• Monitoraggio delle reti private: molte aziende hanno infrastrutture non accessibili pubblicamente. In questi casi, è necessario installare agent su ogni ambiente per abilitare la visibilità; questa è la parte più impegnativa in quanto richiede installazione manuale.

Risultati desiderati:

• Scoperta completa di tutte le distribuzioni di certificati
• Identificazione di terze parti collegate e relativo profilo di sicurezza
• Identificazione dei certificati a rischio scadenza, interni e di terzi
• Identificazione di certificati mal configurati
• Censimento di servizi/protocolli/configurazioni crittografiche
• Monitoraggio della copertura post-quantum
• Monitoraggio della copertura dell’automazione
• Monitoraggio della condivisione dei certificati tra servizi

A questo punto hai visibilità completa dei certificati e della loro posizione/utilizzo. Al contrario dei primi tre step, che seguono sempre l’ordine stabilito, qui si lavora in modo più organico. Potresti identificare subito criticità gravi, legate a certificati scaduti o mal configurati. L’assenza o la presenza di key exchange post-quantistico è una delle cose che potrai valutare subito. Ha senso intervenire subito sulle criticità, perché il resto del lavoro richiederà maggior impegno e collaborazione interdipartimentale.

L’obiettivo è suddividere la PKI in gruppi coerenti col contesto, di solito per business unit, importanza e tipologia dei dati. Comprendere le caratteristiche tecniche dell’infrastruttura per il triage può richiedere molta comunicazione interna.

In seguito, individua i team responsabili di ciascun gruppo. Questa fase è cruciale, perché assicura che qualunque segnalazione venga gestita dagli addetti competenti. Così si chiariscono anche le dipendenze da terzi: a seconda dei casi, potresti include o escludere fornitori esterni come team di riferimento.

Definiti i gruppi e i team, attivare il sistema di alerting dovrebbe essere questione di un click. Dopo questa fase, idealmente, non ti capiterà più di vedere un certificato scaduto.

Questo step sarà la base di tutte le attività future: prenditi il tempo di identificare tutti gli stakeholder e di coinvolgerli nel programma. Valuta anche se integrare il tool PKI ad altri tool affinché le info sui certificati siano disponibili dove necessario.

Risultati desiderati:

• Identificazione delle proprietà prioritarie per azioni urgenti
• Definizione delle business unit e dei team
• Raggruppamento delle proprietà per priorità e ownership
• Configurazione del sistema di alerting, instradato ai responsabili
• Identificazione dei servizi terzi, integrati o presenti su domini aziendali
• Integrazione tra alerting e sistemi esterni via API

Nel 2025 l’automazione è diventata fondamentale: i certificati ancora rinnovati manualmente—oggi annualmente—dovranno essere rinnovati due volte l’anno dopo marzo 2026. Da questa data, infatti, saranno vietati certificati oltre i 200 giorni. Dal 2027 sono previsti limiti a 100 giorni, e dal 2029 solo 47 giorni. È quindi urgente individuare subito le situazioni non ancora automatizzate e coinvolgere tutta l’organizzazione nella migrazione all’automazione.

Il supporto all’automazione tramite protocollo Automatic Certificate Management Environment (ACME) cresce ogni giorno e diventerà a breve la soluzione di default. Il vantaggio di ACME è la sua natura generica, che ti permette di passare tra CA senza vincoli. I CLM completi possono offrire integrazioni proprietarie, ma con il rischio di lock-in. Con ACME si va più sul sicuro, con possibilità di adottare successivamente un CLM proprietario, magari solo per i domini di maggior valore che richiedono funzioni avanzate.

Dovrai anche scegliere le CA da utilizzare; la decisione va adattata alle circostanze. Sulla PKI pubblica le CA gratuite portano vantaggi, perché offrono lo stesso servizio senza costi. Infatti, Let's Encrypt spesso introduce per primo nuove funzionalità e misure di sicurezza. Sul fronte PKI private potresti aver bisogno di più supporto, strumenti e servizi professionali.

Risultati desiderati:

• Percorso chiaro verso l’automazione
• Elenco completo degli ambienti che richiedono certificati
• Istruzioni per l’automazione in ogni ambiente
• Decisione tra ACME e integrazioni CLM proprietarie
• Elenco ristretto delle CA affidabili

Uno dei punti di forza delle PKI pubbliche è il sistema di monitoraggio e auditing integrato tramite Certificate Transparency (CT). L’abbiamo già incontrato al primo step, dove era fondamentale per la discovery di tutti i certificati della tua PKI pubblica. In quel caso, la priorità era trovare tutti i certificati non ancora scaduti. Tuttavia, CT permette anche di monitorare in tempo reale i nuovi certificati, come vengono creati e registrati nei log pubblici. Questo è importante sia per vedere subito i propri certificati, sia per scoprire tempestivamente emissioni non autorizzate.

Sulla PKI pubblica, il titolare di un dominio non ha controllo tecnico sull’emissione: qualunque CA, se autorizzata, può rilasciare certificati per qualunque dominio nel mondo, senza consenso del proprietario. Per questo il monitoraggio è fondamentale per rilevare attività fraudolente. 

Un altro aspetto del CT è che ti aiuta a comprendere la tua infrastruttura: ogni certificato riporta uno o più domini a cui si applica, offrendo un ottimo metodo per la discovery; puoi scoprire sottodomini appena vengono registrati nei log CT.

I certificati pubblici finiscono nei log CT, accessibili da chiunque. Con un buon strumento, analizzare questi log è semplice, specialmente se c’è automazione per gestire i grandi numeri e comprendere gli usi dei certificati. In alternativa, puoi affidarti a strumenti open source per lavorare direttamente sui log.

All’inizio potresti trovare utile ricevere una email a ogni emissione, ma presto la cosa diventa caotica. E in ogni caso, che farci con tutte queste notifiche? Come distinguere tra emissioni autorizzate e fraudolente? Questo tipo di attività è perfetta per una buona automazione.

I tool di monitoraggio CT si focalizzano spesso solo sui certificati emessi su domini noti, ma si può ampliare il controllo a tutti i certificati per rilevare tentativi di frode. Questo consente per esempio di individuare certificati invalidi su domini simili ai tuoi, usati per phishing. Il rilevamento di questi attacchi viene di solito implementato in strumenti di protezione reputazione dominio e brand. Red Sift's Brand Trust è uno di questi strumenti.

Risultati desiderati:

• Monitoraggio in tempo reale dei certificati emessi
• Gestione automatica delle emissioni di routine per eliminare i “rumori”
• Rilevamento di emissioni insolite che meritano attenzione
• Individuazione di emissioni impersonate su tutta la PKI pubblica

Un punto curioso della PKI pubblica è che l’emissione dei certificati non è autenticata in senso stretto. Per semplicità, chiunque può ottenere un certificato se dimostra di controllare una parte dell'infrastruttura. Questo di solito funziona, ma apre la porta a emissioni indesiderate in caso di configurazioni errate. Ad esempio, il problema del Dangling DNS: un dominio ancora puntato a un IP ormai non più sotto il controllo del proprietario (ad esempio dopo aver distrutto una VM cloud senza aggiornare la configurazione DNS). In questa situazione, chi ottiene lo stesso IP può emettere un certificato per il tuo dominio.

Uno standard relativamente nuovo, il Certification Authority Authorization (CAA), sta guadagnando terreno per dare più ordine e controllo sull’emissione. CAA permette ai proprietari dei domini di pubblicare policy di emissione da far rispettare a tutte le CA. Non si tratta ancora di un’autenticazione forte, ma è il massimo livello di sicurezza ottenibile oggi sulla PKI pubblica.

Le policy CAA si configurano come record DNS dei domini da proteggere. In modo molto semplice, consentono di selezionare uno o più CA fidati, escludendo implicitamente tutte le altre CA pubbliche. Puoi controllare l’emissione per certificati ordinari e wildcard, S/MIME, BIMI e altri tipi futuri. Se consenti una sola CA, è possibile implementare configurazioni dettagliate per aumentare la sicurezza.

CAA può essere applicata in molti modi. In sintesi: 1) di default, senza CAA, ogni CA può emettere su tuoi domini; 2) una CAA con più CA è facile da implementare e riduce già molto il rischio; 3) una CAA stretta e personalizzata offre massima sicurezza per le proprietà critiche. 

NOTA: a giugno 2025 il CA/Browser Forum ha deciso di rendere obbligatorio il controllo DNSSEC su tutte le operazioni DNS relative all’emissione, inclusa la validazione CAA. Dal marzo 2026, il DNSSEC garantirà la validità crittografica della policy CAA e ridurrà il rischio di attacchi contro l’infrastruttura di emissione.

Il monitoraggio CT, già visto nello step precedente, dà i migliori risultati se la policy CAA è completa: insieme costituiscono una difesa efficace contro tutte le emissioni non autorizzate.

Risultati desiderati:

• Scegliere una lista ristretta di CA fidate/competenti, meno soggette a errori o compromissioni
• Distribuire la configurazione CAA estesa a tutti i domini
• Distribuire una CAA “deny-all” ai domini parcheggiati
• Personalizzare policy CAA rigide per le proprietà di valore
• Implementare un monitoraggio CT avanzato integrato con le policy CAA

Il mondo sta attraversando una transizione alla crittografia post-quantistica per difendersi dall’arrivo dei quantum computer rilevanti (CRQC), ritenuti in grado di compromettere gli algoritmi a chiave pubblica odierni. A seconda dei casi, la migrazione per le proprietà più importanti dovrà concludersi entro 5 anni, per il resto entro 10. Non sappiamo quando arriverà il cosiddetto Q-Day, ma speriamo sia dopo aver completato la migrazione.

Sul fronte PKI pubblica, l’unica azione immediata è migliorare la copertura di key exchange post-quantistico sulle proprietà. Anche se al momento non si pensa che nessuno abbia accesso a CRQC, c’è il rischio di attacco "Store Now, Decrypt Later" (o "Harvest Now, Decrypt Later"): i dati criptati oggi vengono raccolti per essere decifrati in futuro se (o quando) i CRQC saranno usabili. In base alla tua esposizione, questa minaccia potrebbe richiedere azioni urgenti: se devi proteggere certe informazioni ancora per un decennio e il CRQC arriva prima... potrebbe già essere tardi.

Abbiamo preparato una guida dettagliata per accompagnarti nella transizione alla crittografia post-quantistica.

Risultati desiderati:

• Adozione immediata del key exchange post-quantistico sulle proprietà critiche
• Percorso chiaro per il resto del patrimonio

L’ultimo step del percorso di gestione della PKI pubblica riguarda una serie di configurazioni che potrebbero minare la sicurezza. Anche se hai il pieno controllo dei tuoi certificati, non conta se poi questi non vengono utilizzati correttamente. Ecco alcune aree su cui concentrarsi:

• Algoritmo di chiave pubblica e robustezza: assicurati di usare algoritmi e lunghezze chiave adeguati alla funzione. Sulla PKI pubblica le CA rifiutano chiavi troppo deboli, ma qualche problema resta possibile, soprattutto su PKI private.
• Configurazione dei protocolli crittografici: usa solo protocolli sicuri e configura i parametri secondo gli utenti che devono accedere. Questa config non è mai binaria: a volte servono compromessi con client legacy. 
• Correttezza delle catene di certificati: i certificati devono essere distribuiti insieme a una chain valida che termina in un root accettato dagli utenti; il root non deve necessariamente far parte della configurazione. Catene errate possono causare blocchi difficili da diagnosticare.
• HTTP Strict Transport Security: attiva e pre-carica HSTS su tutti i domini, così da impedire bypass sugli avvisi di certificati non validi e richiedere sempre la cifratura del traffico. HSTS impedisce agli utenti di ignorare gli avvisi in caso di attacco sulla rete.
• Cookie HTTP sicuri: i cookie HTTP vanno marcati come sicuri e si devono implementare i Cookie Name Prefixes (RFC 6265bis) per correggere debolezze storiche nella gestione dei cookie. L’assenza di questi accorgimenti rende possibile il furto di sessioni HTTP anche su siti sicuri.
• HTTP mixed content: le pagine web devono utilizzare HTTPS sia sul contenuto primario sia su tutte le risorse esterne richiamate. Anche i link verso l’esterno devono essere cifrati.
• Policy CAA: già trattata in precedenza, qui ricordata per completezza; ogni proprietà deve avere la propria configurazione restrittiva per l’emissione dei certificati.

Affidati ai tuoi strumenti PKI per verificare quali siti presentano questi problemi. Non tutti i tool supportano tutte queste tecnologie: la maggior parte dei CLM gestisce PKI e TLS ma non la sicurezza sull’"ultimo miglio". Tutte queste funzioni sono disponibili nei prodotti Red Sift. Se usi uno strumento che non le offre, prova il nostro tool gratuito su hardenize.com per colmare le lacune residue. Il nostro test è utile anche per collaborare con terzi che non hanno accesso agli stessi tool.

Per maggiori informazioni consulta la guida completa alla configurazione SSL/TLS e PKI, con approfondimenti su tutti questi temi e molto altro.

Risultati desiderati:

• Manuale delle best practice crittografiche
• Nuovi sistemi in linea con le best practice
• Piano per l’adeguamento delle proprietà esistenti alle best practice
• Piano di governance per la valutazione continua e l’evoluzione delle policy