Quando un ente locale firma un documento online o verifica l’identità di un agente su un portale interno, si basa su mattoni software spesso invisibili. CAPICOM è stato a lungo uno di questi mattoni, integrato in applicazioni Windows senza che gli utenti finali ne sospettassero l’esistenza. Il suo ruolo: gestire i certificati digitali, crittografare dati e apporre firme elettroniche tramite alcune righe di codice.
Il problema è che Microsoft ha ufficialmente deprecato CAPICOM e ha cessato ogni aggiornamento, ponendo le amministrazioni locali di fronte a un angolo cieco tecnico.
Firma elettronica e certificati: cosa faceva concretamente CAPICOM
Prima di parlare di sostituzione, un passo indietro sul funzionamento aiuta a comprendere l’ampiezza del tema. CAPICOM è una libreria COM (Component Object Model) che permetteva agli sviluppatori di integrare funzioni crittografiche in applicazioni Windows senza dover manipolare direttamente i livelli a basso livello del sistema.
In pratica, questo forniva tre capacità principali:
- Validare e gestire certificati digitali memorizzati nel negozio Windows, ad esempio per autenticare un agente che accede a un servizio online.
- Firmare elettronicamente documenti o flussi di dati, garantendo la loro integrità e l’identità del firmatario.
- Crittografare e decrittografare informazioni sensibili scambiate tra servizi, come atti di stato civile trasmessi tra un comune e una prefettura.
Per un ente locale, queste funzioni riguardavano processi concreti: dematerializzazione degli appalti pubblici, trasmissione di documenti ai servizi dello Stato, autenticazione su portali di lavoro. CAPICOM veniva spesso eseguito tramite controlli ActiveX in Internet Explorer, il che spiega perché il suo utilizzo sia rimasto a lungo invisibile nei browser moderni.
Numerose risorse dettagliate capicom e i suoi usi su Collectivité Numérique, permettono di misurare quanto questa libreria si sia ritrovata intrecciata in catene applicative varie.
Obsolescenza di CAPICOM: rischi reali per gli enti locali
Microsoft non distribuisce più CAPICOM nelle versioni recenti di Windows e raccomanda esplicitamente di migrare verso CryptoAPI, CNG (Cryptography API: Next Generation) o le classi .NET. Non si tratta di un semplice cambio di versione: è un’interruzione definitiva del supporto.
Perché questo rappresenta un vero problema per gli enti locali? Perché una libreria senza patch di sicurezza diventa una porta d’ingresso per gli attacchi. Ogni vulnerabilità scoperta dopo la fine del supporto rimane aperta, senza patch.
Conformità normativa indebolita
Gli enti locali gestiscono dati personali dei cittadini (stato civile, assistenza sociale, fiscalità locale). Utilizzare un componente crittografico obsoleto indebolisce la conformità al GDPR, poiché il regolamento richiede misure tecniche adeguate allo stato dell’arte. Uno strumento abbandonato dal suo editore non soddisfa più questo requisito.
I riferimenti dell’ANSSI e la dottrina cloud dello Stato spingono nella stessa direzione: le soluzioni digitali dei servizi pubblici devono basarsi su componenti mantenuti, auditati e, se possibile, sovrani. CAPICOM non spunta più nessuna di queste caselle.
Dipendenza da Internet Explorer
Molte implementazioni di CAPICOM passavano attraverso controlli ActiveX, tecnologia legata a Internet Explorer. Tuttavia, Microsoft ha interrotto il supporto di Internet Explorer. Gli enti locali che non hanno ancora migrato le loro applicazioni web interne si trovano di fronte a una doppia obsolescenza: browser e libreria crittografica.
Migrazione verso CryptoAPI e .NET: da dove cominciare
La migrazione non è un semplice sostituzione di file DLL. Comporta l’identificazione di tutte le applicazioni che chiamano CAPICOM, per poi riscrivere le porzioni di codice interessate. Ecco i passaggi concreti che ciò implica.
Iniziare con un inventario applicativo completo. Ogni servizio (urbanistica, finanze, risorse umane) può utilizzare software di settore che incorpora CAPICOM senza che il servizio informatico ne sia a conoscenza. Cercare le chiamate alla DLL capicom.dll nel parco applicativo è il punto di partenza.
Successivamente, la scelta della tecnologia di sostituzione dipende dal contesto:
- CryptoAPI è adatta per applicazioni C/C++ che rimangono in ambiente Windows nativo. Offre un accesso diretto al negozio di certificati del sistema.
- CNG (Cryptography API: Next Generation) fornisce algoritmi più recenti e un’architettura modulare. È la pista raccomandata per i nuovi sviluppi.
- Le classi System.Security.Cryptography di .NET sono adatte per applicazioni sviluppate in C# o VB.NET, spesso il caso degli strumenti di lavoro interni degli enti locali.
Ogni sostituzione deve essere testata in un ambiente isolato prima del deployment, poiché il cambiamento della libreria crittografica può modificare il formato delle firme generate e rendere illeggibili documenti già firmati.
Alternative sovrane e suite digitali pubbliche
La questione non si limita alla sostituzione tecnica di CAPICOM. Da alcuni anni, le politiche pubbliche francesi incoraggiano l’adozione di soluzioni digitali libere o controllate per gli enti locali. La DINUM propone LaSuite, un ecosistema di applicazioni collaborative basato su software libero, ospitate in Francia.
LaSuite non sostituisce direttamente CAPICOM (non è una libreria crittografica), ma illustra la direzione presa: privilegiare strumenti il cui codice sorgente è auditabile e l’hosting sovrano. Per il livello di firma elettronica, fornitori qualificati dall’ANSSI offrono servizi conformi al regolamento eIDAS, senza dipendere da componenti proprietari abbandonati.
Gli enti locali che approfittano della migrazione per ripensare la loro architettura di firma guadagnano su due fronti: eliminano un debito tecnico e si allineano ai riferimenti attuali di sicurezza.
La scomparsa di CAPICOM non è un incidente minore. Per gli enti locali che lo utilizzavano ancora, ogni mese senza migrazione aumenta l’esposizione a vulnerabilità non corrette. L’inventario applicativo rimane la prima azione utile, anche prima di scegliere tra CryptoAPI, CNG o .NET. E poiché il quadro normativo francese spinge verso soluzioni aperte e sovrane, è anche l’occasione per non riprodurre la stessa dipendenza da un unico editore.