Cuando una entidad local firma un documento en línea o verifica la identidad de un agente en un portal interno, se apoya en bloques de software a menudo invisibles. CAPICOM ha sido durante mucho tiempo uno de esos bloques, integrado en aplicaciones de Windows sin que los usuarios finales sospecharan su existencia. Su función: gestionar certificados digitales, cifrar datos y aplicar firmas electrónicas a través de unas pocas líneas de código.
El problema es que Microsoft ha depreciado oficialmente CAPICOM y ha cesado cualquier actualización, colocando a las administraciones locales ante un vacío técnico.
Firma electrónica y certificados: lo que CAPICOM hacía concretamente
Antes de hablar de reemplazo, un desvío por el funcionamiento ayuda a comprender la magnitud del tema. CAPICOM es una biblioteca COM (Component Object Model) que permitía a los desarrolladores integrar funciones criptográficas en aplicaciones de Windows sin manipular directamente las capas de bajo nivel del sistema.
En la práctica, esto proporcionaba tres capacidades principales:
- Validar y gestionar certificados digitales almacenados en el almacén de Windows, por ejemplo, para autenticar a un agente que accede a un teleservicio.
- Firmar electrónicamente documentos o flujos de datos, garantizando su integridad y la identidad del firmante.
- Cifrar y descifrar información sensible intercambiada entre servicios, como documentos de estado civil transmitidos entre un ayuntamiento y una prefectura.
Para una entidad, estas funciones afectaban procesos concretos: desmaterialización de contratos públicos, transmisión de documentos a los servicios del Estado, autenticación en portales de negocio. CAPICOM se ejecutaba a menudo a través de controles ActiveX en Internet Explorer, lo que explica por qué su uso ha permanecido invisible durante mucho tiempo en los navegadores modernos.
Numerosos recursos detallan capicom y sus usos en Collectivité Numérique, lo que permite medir hasta qué punto esta biblioteca se ha encontrado entrelazada en diversas cadenas aplicativas.
Obsolescencia de CAPICOM: riesgos reales para las entidades locales
Microsoft ya no distribuye CAPICOM en las versiones recientes de Windows y recomienda explícitamente migrar a CryptoAPI, CNG (Cryptography API: Next Generation) o las clases .NET. No es un simple cambio de versión: es un cese definitivo del soporte.
¿Por qué esto plantea un verdadero problema para las entidades? Porque una biblioteca sin parches de seguridad se convierte en una puerta de entrada para los ataques. Cada vulnerabilidad descubierta después del fin del soporte permanece abierta, sin parche.
Conformidad regulatoria debilitada
Las entidades manejan datos personales de los administrados (estado civil, ayuda social, fiscalidad local). Utilizar un componente criptográfico obsoleto debilita la conformidad con el RGPD, ya que el reglamento exige medidas técnicas adaptadas al estado del arte. Una herramienta abandonada por su editor ya no cumple con este requisito.
Los referenciales de la ANSSI y la doctrina en la nube del Estado empujan en la misma dirección: las soluciones digitales de los servicios públicos deben basarse en componentes mantenidos, auditados y, si es posible, soberanos. CAPICOM ya no cumple con ninguno de estos requisitos.
Dependencia de Internet Explorer
Muchas implementaciones de CAPICOM pasaban por controles ActiveX, una tecnología vinculada a Internet Explorer. Sin embargo, Microsoft ha puesto fin al soporte de Internet Explorer. Las entidades que aún no han migrado sus aplicaciones web internas se encuentran con una doble obsolescencia: navegador y biblioteca criptográfica.
Migración a CryptoAPI y .NET: por dónde empezar
La migración no es un simple reemplazo de archivo DLL. Supone identificar todas las aplicaciones que llaman a CAPICOM, y luego reescribir las porciones de código afectadas. Aquí están los pasos concretos que esto implica.
Comenzar con un inventario completo de aplicaciones. Cada servicio (urbanismo, finanzas, recursos humanos) puede utilizar software de negocio que incluya CAPICOM sin que el servicio informático tenga conocimiento. Buscar las llamadas a la DLL capicom.dll en el parque de aplicaciones es el punto de partida.
A continuación, la elección de la tecnología de reemplazo depende del contexto:
- CryptoAPI es adecuada para aplicaciones C/C++ que permanecen en un entorno Windows nativo. Ofrece acceso directo al almacén de certificados del sistema.
- CNG (Cryptography API: Next Generation) proporciona algoritmos más recientes y una arquitectura modular. Es la opción recomendada para nuevos desarrollos.
- Las clases System.Security.Cryptography de .NET son adecuadas para aplicaciones desarrolladas en C# o VB.NET, que a menudo es el caso de las herramientas de negocio internas de las entidades.
Cada reemplazo debe ser probado en un entorno aislado antes de su implementación, ya que el cambio de biblioteca criptográfica puede modificar el formato de las firmas generadas y hacer ilegibles documentos ya firmados.
Alternativas soberanas y suites digitales públicas
La cuestión no se limita al reemplazo técnico de CAPICOM. Desde hace algunos años, las políticas públicas francesas fomentan la adopción de soluciones digitales libres o controladas para las entidades. La DINUM propone LaSuite, un ecosistema de aplicaciones colaborativas basadas en software libre, alojadas en Francia.
LaSuite no reemplaza directamente a CAPICOM (no es una biblioteca criptográfica), pero ilustra la dirección tomada: priorizar herramientas cuyo código fuente sea auditable y el alojamiento soberano. Para la capa de firma electrónica, proveedores calificados por la ANSSI ofrecen servicios conformes al reglamento eIDAS, sin depender de componentes propietarios abandonados.
Las entidades que aprovechan la migración para repensar su arquitectura de firma ganan en dos frentes: eliminan una deuda técnica y se alinean con los referenciales actuales de seguridad.
La desaparición de CAPICOM no es un incidente menor. Para las entidades que aún lo utilizaban, cada mes sin migración aumenta la exposición a fallos no corregidos. El inventario de aplicaciones sigue siendo la primera acción útil, incluso antes de elegir entre CryptoAPI, CNG o .NET. Y dado que el marco regulatorio francés impulsa hacia soluciones abiertas y soberanas, también es la oportunidad de no reproducir la misma dependencia a un único editor.