Gestión avanzada de certificados y firmas de drivers en Windows

Inicio » Seguridad » Gestión avanzada de certificados y firmas de drivers en Windows

La gestión avanzada de certificados y firmas de drivers en Windows se ha convertido en un tema clave tanto para administradores de sistemas como para desarrolladores y usuarios avanzados. Entre cambios de políticas de Microsoft, nuevos requisitos de seguridad y la coexistencia de varios sistemas (Windows 7, 8.1, 10, 11), es fácil perderse si no se tiene una guía clara y bien estructurada.

Además, la combinación de controladores de dispositivo, certificados digitales, smartcards, tokens y modos especiales del sistema (como el modo de prueba o la desactivación de la comprobación de integridad) hace que una mala decisión pueda abrir brechas de seguridad serias. En las siguientes secciones verás, paso a paso y con todo lujo de detalles, cómo se firma un controlador, qué certificados se necesitan, cómo se gestiona la firma en distintas versiones de Windows y cómo tratar con drivers sin firma o defectuosos sin jugarte la estabilidad del sistema.

Conceptos básicos: drivers, certificados y firma digital en Windows

Antes de meternos en harina, conviene tener claro qué es exactamente un controlador de dispositivo (driver): es un pequeño programa que permite al sistema operativo comunicarse con un periférico o componente de hardware, ocultando los detalles técnicos del dispositivo y ofreciendo una interfaz estándar para usarlo.

El sistema operativo, especialmente Windows 10 y Windows 11, incluye una buena cantidad de drivers genéricos que permiten utilizar muchos dispositivos “de serie”, sin instalar nada adicional. Estos controladores suelen ofrecer un conjunto básico de funciones, suficiente para salir del paso pero, en la práctica, las características avanzadas (escaneo en una multifunción, funciones especiales de una tarjeta de sonido, opciones avanzadas de una GPU, etc.) requieren casi siempre los drivers oficiales del fabricante.

La firma digital de controladores en Windows funciona de forma parecida a la firma de aplicaciones: añade una firma criptográfica al archivo (o a un catálogo asociado) que permite comprobar quién lo ha emitido y si el contenido se ha modificado desde que el fabricante lo publicó. Esto implica una “doble aprobación”: por parte del desarrollador, que firma el driver, y de Microsoft, que valida la cadena de confianza y, en muchos casos, lo distribuye a través de Windows Update o lo utiliza como referencia para el arranque seguro.

Esta firma tiene una consecuencia directa: Windows, sobre todo en sus versiones recientes, tiende a bloquear controladores sin firma válida o con certificados no confiables. Esto es un filtro de seguridad importantísimo para evitar rootkits y drivers maliciosos que se carguen en modo kernel con permisos de SYSTEM, pero también puede convertirse en un quebradero de cabeza cuando necesitas instalar un driver legítimo que no cumple las políticas de firma más nuevas.

En contextos de teletrabajo y soporte remoto, muchos usuarios han descubierto que no podían usar impresoras, lectores de tarjetas, dispositivos USB específicos o tarjetas gráficas porque el driver no estaba firmado correctamente o el certificado no era reconocido por Windows, lo que obliga a entender (aunque sea por encima) cómo funciona este sistema.

Requisitos previos: programas, cuentas y certificados necesarios

Para gestionar la firma de drivers a nivel profesional (por ejemplo, en un fabricante de hardware o integrador), es imprescindible estar dado de alta en el Programa de Desarrolladores de Hardware de Microsoft. El registro se realiza a través del Centro de partners (Partner Center) siguiendo el flujo de alta del Programa para desarrolladores de hardware.

Como administrador del Centro de partners, eres el responsable de agregar, actualizar y revocar certificados de firma de código que se vayan utilizando para firmar controladores. Cuando un certificado expira o deja de ser seguro, hay que retirarlo y sustituirlo por uno nuevo para seguir firmando y actualizando drivers sin interrupciones.

En la práctica, esto implica contar con al menos un certificado de firma de código de tipo EV (Extended Validation) emitido por una entidad de certificación (CA) de confianza, que será el que utilices para firmar tus archivos CAB de envío, controladores y catálogos. Estos certificados siempre deben utilizar SHA-2 (SHA256) como algoritmo de firma, ya que Windows ha dejado atrás el viejo SHA1 en sus políticas de integridad de código.

Obtención, alta y renovación de certificados de firma de código

La primera decisión importante es determinar qué tipo de certificado de firma de código necesitas. Microsoft publica requisitos específicos de firma de drivers que definen si es obligatorio un certificado EV, de qué tipo, y cómo se encadena la confianza hasta una CA raíz aceptada por Windows.

Si tu organización ya dispone de un certificado válido y quieres reutilizarlo, puedes saltarte la compra y centrarte en el proceso de alta en el Centro de partners. Si no dispones de ninguno, deberás adquirir un certificado EV de un proveedor certificado. La CA verificará los datos de tu empresa (identidad, dirección, contacto, etc.) y, una vez aprobada la solicitud, te indicará cómo descargar o activar el certificado.

Cuando ya tengas el certificado instalado en el almacén adecuado, accede al Centro de partners con una cuenta de administrador, ve al icono del engranaje (configuración) y entra en “Configuración de la cuenta” o “Configuración del desarrollador”, según la sección disponible, y después en “Administrar certificados”. Desde ahí podrás agregar un nuevo certificado para vincularlo con tus envíos de drivers.

Para completar el alta, el portal te pedirá descargar un archivo binario (normalmente llamado Signablefile.bin) que deberás firmar con tu certificado usando SignTool, especificando el algoritmo SHA256 y una marca de tiempo SHA-2 válida. Una vez firmes ese archivo, lo subes de vuelta al Centro de partners, que lo verificará y asociará el certificado a tu cuenta.

Cuando toque renovar, el procedimiento es similar: adquieres o renuevas el certificado en la CA, lo instalas, repites el proceso de firma del Signablefile.bin con SignTool y lo vuelves a subir. A partir de ahí, ya podrás utilizar el nuevo certificado para seguir firmando controladores y paquetes.

Revocación y eliminación de certificados en el Centro de partners

Hay ocasiones en las que un certificado deja de ser válido antes de su fecha de caducidad, por ejemplo por compromiso de la clave privada, cambio de políticas internas o final de relación con una CA. En esos casos es fundamental revocarlo y retirarlo del portal para evitar que se sigan emitiendo firmas con él.

Para revocar o quitar un certificado de firma de código, entra en el Centro de partners con tu cuenta de administrador, accede de nuevo al menú de “Administrar certificados” y localiza en la lista el certificado concreto que deseas retirar. En la columna de acción tendrás la opción de quitarlo o revocarlo; al hacerlo, dejará de estar disponible para nuevos envíos, aunque las firmas ya generadas seguirán teniendo el comportamiento que marque la política de confianza de Windows y la CA.

Creación del archivo CAB con los drivers a firmar

Una vez tienes el certificado listo, el siguiente paso es preparar el paquete de envío de drivers en formato CAB. Este archivo comprimido es el que se remitirá al Centro de partners para que Microsoft genere las firmas definitivas y los catálogos correspondientes.

Un CAB típico para un controlador sencillo incluye al menos el binario del driver (.sys), su archivo de instalación INF (.inf), los archivos de símbolos (.pdb) para depuración de errores y uno o más archivos de catálogo (.cat). Estos catálogos se utilizan internamente en la empresa y durante el envío, pero Microsoft suele regenerarlos y reemplazarlos por catálogos propios al completar el proceso de firma.

Para montar el CAB, recopila todos los binarios en una carpeta de trabajo (por ejemplo, C:\Echo en el caso de un controlador de ejemplo llamado Echo.sys). Abre una consola con privilegios de administrador y revisa las opciones de MakeCab ejecutando MakeCab /? para ver parámetros de compresión, ficheros de directivas, etc.

Después crea un archivo DDF (directiva de MakeCab) donde defines el nombre del CAB de salida, el directorio de destino interno dentro del CAB y la lista de archivos que se incluirán. Es habitual forzar compresión MSZIP, especificar que se permita un único gabinete y establecer DestinationDir a una subcarpeta (por ejemplo, “Echo”) para evitar archivos en la raíz del CAB.

Con el DDF preparado, ejecuta MakeCab con la opción /F apuntando a ese archivo de órdenes. Si todo va bien, la herramienta mostrará el número de ficheros incluidos, el tamaño antes y después de la compresión y guardará el CAB definitivo, normalmente en un subdirectorio “Disk1”. Ese será el archivo base que firmarás con tu certificado EV y que enviarás al portal.

Firma del archivo CAB con certificado EV y envío al portal

El archivo CAB generado aún no está listo para pasar por el proceso de firma de Microsoft si no lo has firmado previamente con tu certificado EV. Este paso añade una capa de confianza adicional y demuestra que el paquete procede de un desarrollador autenticado.

Cada proveedor de certificados EV suele ofrecer una guía específica, pero en Windows lo más habitual es usar SignTool con SHA256 tanto para el algoritmo de firma como para la marca de tiempo. El comando típico incluye la selección del almacén (por ejemplo, /s MY), el nombre de la entidad emisora o del titular del certificado, el uso de /fd sha256, una URL de servidor de timestamp SHA-2 y la ruta al CAB que vamos a firmar.

Una vez firmado el archivo CAB, ve al Hardware Dev Center dentro del Centro de partners, inicia sesión y crea un envío nuevo para hardware. En la sección de paquetes y propiedades de firma, asigna un nombre de producto descriptivo (te ayudará después a localizar el envío) y deja desactivadas las opciones de firma de prueba si estás creando un controlador de producción.

En el apartado de firmas requeridas, selecciona qué tipos de firmas finales necesitas que incluya el paquete de controladores (por ejemplo, para distintas versiones de Windows o para arquitecturas específicas). Para terminar, sube tu CAB firmado, confirma la configuración y envíalo. Cuando Microsoft complete el proceso, podrás descargar desde el panel el driver ya firmado y listo para distribución.

Tras la descarga, conviene validar que todo está correcto: extrae el paquete, abre una consola de administrador y utiliza SignTool verify sobre el archivo .sys para comprobar que las firmas son válidas y, si quieres, puedes consultar una guía para verificar firmas en Windows.

Envíos con varios controladores y tratamiento interno de firmas

En muchas ocasiones, no envías un único driver, sino varios paquetes relacionados. En ese caso, puedes crear un CAB que incluya múltiples subdirectorios, uno por cada driver, y referenciarlos en el archivo DDF con distintas secciones DestinationDir (DriverPackage1, DriverPackage2, etc.).

El proceso de MakeCab y la firma con el certificado EV es el mismo, simplemente tendrás más archivos y más rutas internas en el DDF. Esto facilita gestionar en bloque familias completas de controladores o versiones específicas para diferentes modelos de dispositivo.

Cuando el controlador se desinstala o se reemplaza por otro, Windows sigue una secuencia interna: añade una firma SHA2 incrustada de Microsoft al binario, sobrescribe cualquier firma previa del cliente si es necesario, y genera un nuevo archivo de catálogo firmado con un certificado SHA2 de Microsoft que sustituye a los catálogos originales enviados por el desarrollador.

Este comportamiento garantiza que, incluso si el fabricante ha firmado el driver por su cuenta, las versiones instaladas en el sistema se ajustan a las políticas de integridad y firma de Microsoft, reforzando la seguridad del arranque y del kernel.

Políticas de firma de controladores según la versión de Windows

Las políticas de firma de drivers han cambiado bastante con el tiempo, especialmente a partir de Windows 10 versión 1607. En versiones anteriores, muchos controladores funcionaban con firmas cruzadas más flexibles, mientras que ahora la exigencia se ha endurecido, sobre todo si el arranque seguro (Secure Boot) está habilitado.

Antes de Windows 10 1607, los controladores en modo kernel y modo usuario, así como aquellos que gestionaban contenido protegido (audio o vídeo con PUMA, PAP o PVP-OPM), podían firmarse con un certificado Authenticode y un certificado cruzado de Microsoft, bastando con encadenarse a una CA aceptada. Ahora se exigen cadenas de confianza específicas y certificados vinculados a raíces de Microsoft (Microsoft Root Authority 2010, Microsoft Root Certificate Authority, etc.).

Para sistemas cliente como Windows Vista y Windows 7, y versiones de Windows 8+ con Secure Boot desactivado, solo los sistemas de 64 bits requieren que los controladores estén firmados; en 32 bits la firma no era obligatoria. La firma podía ser incrustada en el propio archivo o mediante catálogo, siempre con algoritmos SHA-2 y apoyándose en raíces estándar de integridad de código.

En Windows 8, 8.1 y Windows 10 versiones 1507 y 1511 con arranque seguro activado, la firma es obligatoria tanto en 32 como en 64 bits, siempre con SHA-2, y la cadena de confianza sigue estando basada en raíces estándar para integridad de código. A partir de Windows 10 1607 y sucesivas (1703, 1709, 1803 y posteriores), el requisito se afina: la firma debe encadenarse explícitamente a las raíces de Microsoft mencionadas, y se endurece la política de bloqueos a drivers con firma cruzada no conformes.

Existen, sin embargo, algunas excepciones: si el equipo se actualizó desde una versión anterior de Windows a Windows 10 1607, si el arranque seguro está desactivado en la BIOS, o si el driver fue firmado con un certificado emitido antes del 29 de julio de 2015 que se encadena a una CA cruzada soportada, puede seguir funcionando como antes. Además, para no dejar sistemas sin arrancar, los controladores de arranque no se bloquean de golpe, aunque el Asistente de compatibilidad de programas puede proponer su eliminación.

Firma de drivers con HLK/HCK y firma por atestación

Para que un controlador se considere plenamente soportado por Microsoft en distintas versiones de Windows, es necesario someterlo a pruebas de certificación mediante HLK (Hardware Lab Kit) para Windows 10 o HCK (Hardware Certification Kit) para Windows 7/8/8.1.

El proceso consiste en instalar el HLK correspondiente a cada versión de Windows objetivo, ejecutar un pase de certificación completo en un cliente de prueba, y obtener un registro de resultados por cada versión. Después, esos registros se pueden combinar con la versión más reciente de HLK para generar un único conjunto de datos que se adjuntará al envío del driver en el Centro de partners.

En el portal, se envía el controlador junto con los logs combinados de HLK, y Microsoft revisa que se cumplan las directivas del Programa de Compatibilidad de Hardware (WHCP) para las versiones indicadas. Si todo está correcto, el controlador obtiene el sello de certificación y las firmas correspondientes.

En los casos en los que solo se quiere probar un controlador en sistemas cliente de Windows 10, sin cumplir todo el programa de certificación, se puede recurrir a la firma de atestación. Este tipo de firma no requiere pruebas HLK, pero sí que el fabricante asuma la responsabilidad declarando que el controlador cumple determinados requisitos. Es útil para controladores distribuidos fuera de Windows Update o en escenarios específicos de partners.

Firma de controladores para Windows 7 y otros sistemas antiguos

Aunque Windows 7 está oficialmente fuera de soporte, sigue habiendo muchos entornos donde se utiliza, y ahí la gestión de firmas de drivers puede dar problemas especiales, sobre todo por cambios en la compatibilidad con SHA-2.

Un ejemplo típico es el de usuarios que intentan instalar drivers modernos de GPU (como una GTX 950 o una GTX 1060) en Windows 7 de 64 bits. Si Windows indica que “los certificados de firma no están instalados” o que falta compatibilidad con SHA-2, hay que asegurarse primero de tener instalada la actualización KB3033929, que habilita el soporte de firmas SHA-2 en Windows 7.

En algunos casos, esa actualización ya está instalada pero el instalador del driver sigue dando errores. Una solución práctica que ha funcionado para ciertos usuarios consiste en extraer manualmente el ejecutable del driver (por ejemplo, la versión 474.11, último WHQL para Windows 7), y luego ir al Administrador de dispositivos, seleccionar el adaptador de pantalla y usar la opción “Actualizar controlador”, indicando manualmente la carpeta donde se han extraído los archivos. De este modo, Windows instala el controlador saltándose algunos pasos del instalador original.

Es importante saber que versiones más recientes del driver (como 474.14 en este mismo ejemplo) pueden no ser detectadas por el instalador del Administrador de dispositivos, lo que obliga a quedarse en la última versión reconocida con firma WHQL válida para Windows 7. En última instancia, se podría desactivar permanentemente la aplicación de la firma de drivers en Windows 7 con bcdedit, pero no es recomendable salvo que el equipo esté totalmente aislado y controlado.

Métodos para instalar drivers sin firma en Windows 10 y 11

En Windows 10 y 11, la política por defecto es que solo se instalen controladores con firma digital reconocida por Microsoft o por una CA confiable. Esto protege frente a mucho malware disfrazado de driver, pero complica el uso de hardware antiguo o de desarrolladores pequeños que no han firmado correctamente sus controladores.

Si necesitas instalar un driver sin firma (siempre que provenga de una fuente en la que confíes de verdad), tienes cuatro estrategias principales: usar el arranque con aprobación temporal, cambiar una directiva de grupo, arrancar en modo de prueba o desactivar por completo la comprobación de integridad.

El método más prudente es arrancar sin la función de firma de controladores de manera temporal. Para ello, se abre el menú Inicio, se pulsa en el botón de encendido manteniendo pulsada la tecla Shift y se elige “Reiniciar”. Al volver a arrancar, se entra en “Solucionar problemas” → “Opciones avanzadas” → “Configuración de inicio” y, en la lista, se selecciona la opción de desactivar el uso obligatorio de controladores firmados (consulta también las instrucciones sobre modo seguro y opciones de inicio). En ese arranque se puede instalar el driver sin firma, y al siguiente reinicio la protección se vuelve a activar sola.

Para quienes usen Windows 10/11 Pro, existe la opción de modificar la directiva de grupo que regula la firma de controladores. Desde Win + R se ejecuta gpedit.msc, y se navega hasta Configuración de usuario → Plantillas administrativas → Sistema → Instalación de controladores. En la directiva “Firma de código para controladores de dispositivo” se puede ajustar la política, por ejemplo deshabilitándola temporalmente. Esta opción es más adecuada en entornos corporativos donde se gestionan políticas de manera centralizada.

Otra alternativa es el Modo de prueba (TESTSIGNING), pensado sobre todo para desarrolladores que quieren probar drivers sin pasar aún por todo el proceso de firma. Activar este modo con bcdedit hace que Windows cargue controladores sin firma completa y muestra una marca de agua en el escritorio indicando que el sistema está en modo de prueba. Una vez acabadas las pruebas, se vuelve a activar el modo normal ejecutando el comando inverso y reiniciando.

Por último, está la opción más radical: desactivar de forma permanente la comprobación de integridad de controladores con bcdedit.exe /set nointegritychecks on. Esto elimina todas las verificaciones, permitiendo instalar cualquier driver, pero también abre una puerta enorme a código malicioso. Si llegas a usar este método por necesidad extrema, es muy recomendable volver a habilitarlo (nointegritychecks off) en cuanto termines de instalar lo que te hacía falta.

Peligros de desactivar la firma de drivers y buenas prácticas de seguridad

Parece tentador desactivar todos los controles de firma para quitarse problemas, pero hay que tener muy presente que los mayores riesgos de seguridad en Windows vienen muchas veces de drivers maliciosos con permisos de SYSTEM. Estos drivers pueden actuar como rootkits, interceptar tráfico de red, instalar certificados falsos, redirigir la navegación a webs controladas por atacantes, desactivar antivirus o permitir la instalación silenciosa de otro malware.

Una vez un controlador malicioso se cuela en el sistema a bajo nivel, suele ser prácticamente invisible para el usuario y extremadamente difícil de eliminar sin formatear el equipo. Por eso, nunca es buena idea instalar drivers de procedencia dudosa, y mucho menos hacerlo tras desactivar por completo la firma de controladores.

Siempre que busques controladores, intenta descargarlos exclusivamente desde la web oficial del fabricante. Evita páginas genéricas de descarga de drivers que aparecen por delante en las búsquedas y que muchas veces distribuyen instaladores empaquetados con adware, spyware o código malicioso. Si la función de firma de drivers está activa, Windows puede bloquear muchos de estos paquetes no fiables, pero si la deshabilitas pierdes ese filtro importante.

Además, recuerda que Microsoft ha diseñado estas medidas de seguridad precisamente para proteger tus datos y la integridad del sistema. Desactivarlas de manera prolongada solo debería ser el último recurso, y siempre combinándolo con otras medidas como mantener el equipo desconectado de Internet o en redes aisladas.

Detección de drivers defectuosos o problemáticos en Windows

Incluso con todo firmado y en regla, los drivers pueden corromperse, quedar obsoletos o entrar en conflicto con otros componentes del sistema. Cuando esto ocurre, el síntoma típico es que el dispositivo deja de funcionar, lo hace de forma errática o el sistema se vuelve inestable.

El primer sitio donde mirar es el Administrador de dispositivos de Windows, accesible desde el menú contextual del botón Inicio. Ahí aparece un listado completo de todos los componentes hardware y sus drivers asociados. Si uno de ellos tiene un problema, se muestra con un icono de advertencia amarillo.

La forma más sencilla de intentar arreglarlo es hacer clic derecho sobre el dispositivo afectado y elegir la opción de actualizar o reinstalar el controlador, dejando que Windows busque versiones nuevas en su base de datos o en Windows Update. Si esto no da resultado, habrá que acudir a la web del fabricante y descargar el controlador manualmente, asegurándose de que coincide con la versión de Windows y la arquitectura del sistema.

En algunos casos, un driver empieza a fallar justo después de una actualización. Si sospechas que ha sido una versión nueva del controlador la que ha roto algo, puedes Volver a la versión anterior desde las propiedades del dispositivo (pestaña “Controlador” → “Volver a la versión anterior”), siempre que Windows aún conserve la versión previa.

También puedes usar el solucionador de problemas de hardware integrado en Windows para que escanee el sistema en busca de irregularidades con los controladores y proponga acciones automáticas. Se accede desde Configuración → Actualización y seguridad → Solucionar problemas → Hardware y dispositivos.

Gestión de drivers desconocidos, sin firma o de terceros

Cuando Windows detecta un dispositivo pero no encuentra driver, lo muestra en el Administrador de dispositivos como dispositivo desconocido. En ese caso, puedes identificarlo copiando el Id. de hardware desde la pestaña Detalles del dispositivo, seleccionando “Id. de hardware” en el desplegable de propiedades.

Esos identificadores suelen empezar por PCI, USB u otras cadenas y codifican el tipo de dispositivo, el fabricante y el modelo concreto. Con esa cadena, se puede buscar en sitios especializados que mapean IDs de hardware a drivers, o acudir directamente a la página de soporte del fabricante para localizar el controlador adecuado.

Si lo que descargas es un ejecutable de instalación, bastará con lanzarlo y seguir el asistente. Si en su lugar recibes una carpeta con archivos sueltos (.inf, .sys, .cat, etc.), tendrás que usar la opción de “Actualizar controlador” en el Administrador de dispositivos, elegir “Buscar software de controlador en el equipo” y señalar la carpeta donde están los archivos.

Cuando se trata de drivers sin firma reconocida, recuerda que Windows 10 solo permite instalarlos desactivando temporalmente la comprobación de firma en el arranque avanzado. Una vez instalado, conviene reactivar la protección y verificar que el controlador funciona correctamente.

Para ver qué drivers de terceros tienes en tu sistema, herramientas como DriverView de Nirsoft pueden mostrar una lista detallada, destacando en colores diferentes los controladores de Microsoft firmados y los de terceros. Esto te ayuda a localizar drivers desconocidos y valorar si conviene actualizar, desinstalar o investigar más a fondo su origen.

Integración de certificados en Windows, navegadores y Adobe

La gestión de certificados digitales asociados a smartcards o tokens va de la mano de la gestión de drivers, porque para que Windows pueda usar esos certificados en autenticación o firma, necesita que estén correctamente cargados en sus almacenes de certificados.

Herramientas como Bit4id PKI Manager permiten ver los dispositivos conectados (tarjetas, tokens), iniciar y cerrar sesión en ellos, cambiar o desbloquear PIN/PUK, importar o exportar certificados y, en definitiva, administrar todo el ciclo de vida del certificado en el dispositivo criptográfico.

Cuando se inserta una tarjeta inteligente y se inicia sesión introduciendo el PIN correcto, el software puede importar automáticamente los certificados de usuario al almacén de Windows (certmgr.msc, carpeta Personal → Certificados). Si por algún motivo no se importan, se puede forzar manualmente la importación desde las opciones de configuración del middleware. Para casos concretos de uso del DNIe en entornos legacy, consulta la guía para instalar DNIe en Windows 7.

Los navegadores como Firefox gestionan su propio almacén de certificados independiente. Para que reconozcan los certificados de la tarjeta, hay que entrar en las opciones de privacidad y seguridad, ir a la sección de certificados, ver certificados e introducir el PIN cuando lo pida, comprobando que los certificados de usuario aparecen correctamente.

Otros navegadores como Edge, Chrome u Opera utilizan el almacén de Windows, por lo que suelen funcionar sin configuraciones adicionales: basta con que los certificados estén en el almacén adecuado.

En aplicaciones como Adobe Acrobat Reader, si quieres firmar documentos PDF con tu certificado de tarjeta, debes comprobar que los IDs digitales de Windows están habilitados. Desde Preferencias → Firmas → Identidades y certificados de confianza → Más, se puede revisar la lista de IDs disponibles y seleccionar el correspondiente a la smartcard para usarlo en la firma de documentos.

Operaciones avanzadas con smartcards: PIN, PUK, importación y borrado

Las tarjetas inteligentes y tokens usan un PIN para controlar el acceso a la clave privada y, en caso de bloqueo, un PUK para desbloquear el PIN. Bit4id PKI Manager ofrece funciones como Desbloquear PIN, Cambiar PIN, Cambiar PUK o Borrar dispositivo, que deben manejarse con cuidado.

Si introduces mal el PIN demasiadas veces (normalmente tres), la tarjeta se bloquea, y solo es posible recuperarla usando el PUK con la función Desbloquear PIN. De igual modo, si introduces el PUK incorrectamente varias veces, la tarjeta puede quedar bloqueada de forma definitiva, obligándote a solicitar un nuevo dispositivo al proveedor o Autoridad de Certificación.

Para importar un certificado en la tarjeta, se utiliza un archivo .p12 o .pfx que contenga el certificado y la clave privada. El proceso solicita el PIN de la tarjeta, la contraseña del archivo PFX y, opcionalmente, un identificador CKA_ID que algunas aplicaciones utilizan para identificar el certificado. Tras completar la importación, el certificado aparece en la lista de certificados de usuario de la tarjeta.

La exportación, en cambio, solo permite sacar el certificado público en formato .cer; la clave privada no se puede extraer por seguridad. Si se necesita limpiar la tarjeta (por ejemplo, antes de reciclarla), se puede usar la opción Borrar dispositivo, que elimina todos los certificados y claves. Esta acción es irreversible, así que hay que estar absolutamente seguro antes de ejecutarla.

A través de la pestaña de certificados, se puede consultar en detalle la información del certificado X.509, las características de la clave pública y privada (aunque no la clave en sí), las fechas de validez, el emisor, el sujeto y los usos permitidos de la clave, información que resultará muy útil para diagnosticar problemas de firma o autenticación.

Conociendo a fondo cómo funcionan los certificados, las firmas de drivers, las políticas de Windows y la gestión de tarjetas y almacenes de certificados, resulta mucho más sencillo mantener un sistema seguro sin renunciar a usar hardware específico o antiguo. La clave está en combinar buenas prácticas: obtener los controladores del fabricante, respetar las políticas de firma siempre que sea posible, utilizar métodos temporales cuando haya que instalar drivers sin firma y manejar con cuidado los certificados y dispositivos criptográficos que sostienen la autenticidad y la integridad de nuestros controladores y documentos.