La gestión avanzada de certificados y firmas de drivers en Windows se ha vuelto un tema crítico tanto para administradores de sistemas como para desarrolladores y usuarios avanzados. Desde que Microsoft endureció las políticas de firma en Windows de 64 bits, cualquier controlador que funcione en modo kernel debe ir firmado correctamente, y en muchos casos, además, pasar por los sistemas de validación de Microsoft. Si a esto le sumamos cambios como la adopción obligatoria de SHA‑2 o la firma por atestación, es fácil que la cosa se haga cuesta arriba si no se tiene una buena visión global.
A todo esto se le añade que, en entornos reales, hay que lidiar con drivers antiguos, dispositivos sin soporte actualizado, tarjetas criptográficas, certificados en smartcards, herramientas de terceros, teletrabajo, equipos sin conexión a Internet e incluso sistemas aún en producción con Windows 7 o Windows XP. En este contexto, entender cómo funcionan las firmas, qué tipos de certificados se usan, cómo se gestionan en el Panel de hardware y qué opciones tenemos cuando algo falla es fundamental para no perder horas con errores crípticos ni comprometer la seguridad del sistema.
Qué es la firma de controladores en Windows y por qué es tan importante
En Windows, un driver firmado incorpora una firma digital asociada al paquete del controlador (binarios, INF, catálogos, etc.). Esa firma sirve para dos cosas principales: verificar que el paquete no ha sido modificado desde que el editor lo publicó (integridad) y confirmar la identidad del proveedor que lo firma (autenticidad). En sistemas de 64 bits desde Windows Vista, la regla básica es clara: los controladores en modo kernel deben estar firmados o no se cargan.
Cuando instalamos un dispositivo, el propio sistema usa firmas digitales y certificados para comprobar que ese paquete de controlador proviene de un publicador confiable y que no se ha corrompido en el camino. Si algo no cuadra (firma inválida, certificado caducado, algoritmo no admitido, catálogo modificado…), Windows lanza advertencias, bloquea la instalación o directamente impide cargar el driver al arrancar.
Además, desde las primeras versiones de Windows 10, Microsoft ha ido obligando a que los drivers pasen por su canal de firma mediante el Centro de desarrollo de hardware y que se utilicen algoritmos SHA‑2. Esto no solo impacta en los binarios firmados por Microsoft, sino también en cómo se aceptan o rechazan controladores de terceros que estén firmados con SHA1 o con certificados que ya no se consideran seguros.
Cambios en la firma de drivers: de SHA1 a SHA2 y problemas de compatibilidad
Uno de los puntos que más dolores de cabeza ha generado es la transición de SHA1 a SHA2 en la firma de controladores. A partir de Windows 10 versión 1507, todos los controladores firmados por el Centro de hardware van con SHA‑2. Además, ciertos binarios en modo kernel que incorporan firmas duales (SHA1 y SHA2) de proveedores externos pueden dar problemas en sistemas anteriores a Windows 10, o incluso provocar bloqueos en Windows 10 y versiones posteriores si no tienen instaladas determinadas actualizaciones.
En concreto, Microsoft documentó casos en los que drivers firmados e incrustados con certificados duales no se cargaban correctamente o podían ocasionar pantallazos azules en sistemas sin parches críticos. Para evitarlo, se recomendó instalar actualizaciones como la KB 3081436, donde además se publicaban los hashes SHA de los archivos afectados, permitiendo verificar si el sistema estaba usando binarios problemáticos.
Este escenario mixto ha hecho que, al desplegar drivers en entornos con versiones de Windows variadas, sea imprescindible revisar los requisitos de firma por versión del sistema operativo y asegurarse de que la combinación de algoritmo de hash, tipo de certificado y método de firma sea compatible con cada plataforma objetivo.
Rol del administrador en el Centro de partners y gestión de certificados de drivers
Cuando hablamos de desarrolladores de hardware y empresas que distribuyen drivers, el papel del administrador del Centro de partners (antiguo Centro de desarrolladores de hardware) es clave. Esta persona es la encargada de gestionar los certificados de firma de código que se usan para firmar controladores y realizar envíos para que Microsoft los firme o valide.
Desde el panel de hardware del Centro de partners, el administrador puede agregar, renovar y revocar certificados de firma. Para ello, inicia sesión, accede a la configuración de la cuenta o del desarrollador y entra en el apartado “Administrar certificados”. Desde ahí es posible añadir nuevos certificados, descargar los archivos que hay que firmar (como el clásico Signablefile.bin) y subir de nuevo los resultados firmados.
El flujo típico de alta de un certificado pasa por descargar el archivo binario que facilita Microsoft, firmarlo con SignTool usando /fd sha256 y una marca de tiempo SHA‑2 adecuada, y subir el archivo resultante. Windows Hardware Dev Center validará que el certificado es de la empresa y quedará asociado a la cuenta para futuras firmas de paquetes de drivers, ya sea mediante atestación o a través de los procesos estándar de certificación.
Obtención y renovación de certificados EV para firmar drivers
Para firmar controladores a nivel profesional, especialmente cuando se requiere firma de atestación o se quiere publicar drivers a través de Windows Update, es indispensable contar con un certificado EV (Extended Validation) de firma de código emitido por una entidad de certificación reconocida. Estos certificados exigen una validación más estricta de la organización, pero a cambio ofrecen mayor nivel de confianza.
El proceso habitual arranca determinando qué tipo de certificado de firma de código se necesita en función del tipo de controlador, las versiones de Windows que se van a soportar y los requisitos de Microsoft. Si ya se tiene un certificado válido y no se desea cambiar de proveedor, se puede reutilizar. Si no, hay que adquirir un nuevo certificado EV tras un proceso de verificación de identidad de la empresa por parte de la CA.
Una vez aprobada la emisión, el proveedor de certificados proporciona las instrucciones para recuperar el certificado EV, que a menudo se aloja en un dispositivo hardware (token USB o HSM) o se instala en un almacén de certificados protegido. Ese certificado será el que se utilice, junto con SignTool o herramientas equivalentes, para firmar los CAB de envío, los catálogos y, en muchos casos, también los binarios del controlador antes de remitirlos a Microsoft.
Alta, actualización y retirada de certificados en el Panel de hardware
Con el certificado EV operativo, el siguiente paso es mantenerlo correctamente registrado en el Panel de hardware del Centro de partners. Para añadir un nuevo certificado, el administrador inicia sesión, accede a “Configuración de cuenta” o “Configuración del desarrollador” y entra en “Administrar certificados”. Desde allí puede seleccionar “Agregar un nuevo certificado” y seguir el asistente.
Durante el proceso, el sistema genera un archivo Signablefile.bin que se debe descargar y firmar con el nuevo certificado digital de la empresa. Se utiliza SignTool con el parámetro /fd sha256 y una marca de tiempo SHA‑2, asegurando así que el certificado no quede inservible cuando caduque su validez si en algún momento se necesitan validaciones temporales.
Una vez firmado ese archivo, se vuelve al Centro de partners y se sube desde la misma sección. Si todo es correcto, el nuevo certificado quedará asociado a la cuenta del desarrollador, listo para ser utilizado en futuros envíos de controladores.
Cuando un certificado deja de ser necesario o se sospecha que pueda estar comprometido, es posible retirarlo desde el propio panel. Basta con localizarlo en la lista y usar la opción “Quitar” en la columna de acciones. Esto no revoca automáticamente todas las firmas realizadas con él (las firmas ya emitidas seguirán siendo válidas en la mayoría de los casos), pero evita que vuelva a usarse en nuevos envíos o configuraciones.
Firma por atestación: creación y firma de CAB para controladores
La firma de atestación es un mecanismo que permite distribuir drivers sin necesidad de pasar por todo el proceso tradicional de certificación WHQL, manteniendo la firma de Microsoft y el cumplimiento de las reglas de carga del kernel. Para ello, se prepara un archivo CAB con el paquete de controlador y se envía a través del Centro de partners para que sea firmado por Microsoft.
Un CAB típico de envío contiene, como mínimo, el archivo binario del driver (por ejemplo, Echo.sys), el INF correspondiente (Echo.inf) y los archivos de símbolos PDB (como Echo.pdb) necesarios para que las herramientas de Microsoft puedan analizar volcados de memoria en caso de fallos. También se pueden incluir archivos de catálogo (.cat) para comprobaciones internas de la empresa, aunque Microsoft regenerará sus propios catálogos durante el proceso de firma.
La creación del CAB suele hacerse con MakeCab y un archivo DDF que define el nombre del archivo resultante, la organización en carpetas internas del paquete y los ficheros que se deben incluir. En el DDF se definen parámetros como el tipo de compresión, el nombre de salida (por ejemplo, Echo.cab) y el directorio de destino dentro del CAB (normalmente una subcarpeta para que los archivos no queden en la raíz).
Una vez preparado el DDF, se ejecuta un comando del estilo MakeCab /f Echo.ddf, que genera el CAB en un subdirectorio (como Disk1). Conviene revisar su contenido para asegurarse de que tanto los binarios como los INF y PDB se han incluido correctamente antes de pasar al siguiente paso: la firma con el certificado EV.
Firma EV del CAB y envío a través del Centro de partners
Con el CAB generado, hay que firmarlo con el certificado EV de la organización. Para ello se recurre de nuevo a SignTool, apuntando al almacén de certificados donde se encuentra el EV y especificando tanto el algoritmo de hash (SHA256) como la URL del servidor de sellado de tiempo:
Un ejemplo clásico de comando sería algo como SignTool sign /s MY /n "Nombre de la empresa" /fd sha256 /tr http://... /td sha256 /v Echo.cab. Esta firma garantiza que el paquete completo está protegido y que se puede verificar su integridad y procedencia antes incluso de que Microsoft lo procese.
A continuación, el CAB firmado se sube desde el panel del Centro de partners, en el apartado de envíos de nuevo hardware. Allí se asigna un nombre al producto, se indican las propiedades de firma deseadas (qué tipos de firma se quieren para el paquete, qué arquitecturas y sistemas se soportan) y se desactivan o no las firmas de prueba dependiendo del escenario.
Cuando el envío se completa y el proceso de firma ha terminado, el desarrollador puede descargar el controlador ya firmado por Microsoft desde el propio panel. Ese paquete será el que se instale en los equipos de los usuarios, normalmente sin advertencias de seguridad, siempre que el sistema confíe en las autoridades de certificación implicadas y la cadena de confianza esté bien configurada.
Verificación de la firma y EKUs del controlador
Una vez descargado el driver firmado, no está de más comprobar que las firmas y certificados se han aplicado correctamente. Para ello, la herramienta de referencia vuelve a ser SignTool, con comandos como SignTool verify Echo.sys para validar la firma básica o parámetros adicionales como /pa /ph /v /d para obtener más detalles, incluidos los hashes y la verificación de todas las firmas existentes en el archivo.
Además de la verificación por línea de comandos, se puede realizar una comprobación manual de los certificados desde las propiedades del archivo en el Explorador de Windows. En la pestaña “Firmas digitales” se listan las firmas aplicadas; al seleccionar una y entrar en “Detalles” → “Ver certificado” se accede a toda la información relevante de la cadena de confianza.
En la pestaña de detalles del certificado, el campo Uso mejorado de claves (EKU) permite confirmar que el certificado se ha emitido con las extensiones adecuadas para firmar código y drivers. Si las EKUs no son correctas, el sistema puede aceptar la firma a nivel criptográfico, pero seguir rechazando la carga del driver porque el certificado no está autorizado para ese propósito específico.
Gestión avanzada del ciclo de vida de los controladores firmados
El proceso interno de Microsoft al firmar un envío suele implicar varias acciones encadenadas. Primero, se añade una firma incrustada de Microsoft basada en SHA‑2 sobre el binario del controlador. Si el cliente ya había insertado sus propias firmas en el binario, estas pueden ser sobrescritas por la firma de Microsoft si es necesario para garantizar la compatibilidad con las políticas de carga.
Después, el sistema crea y firma un nuevo archivo de catálogo (.cat) con un certificado SHA‑2 de Microsoft, que reemplaza cualquier catálogo enviado originalmente por el desarrollador. De este modo, la integridad del paquete completo se controla desde el catálogo firmado por Microsoft, mientras que los binarios individuales cuentan con firmas que respetan las reglas del modo kernel.
Una vez instalado el driver en Windows (ya sea con devcon, pnputil, instaladores personalizados o a través de Windows Update), si la configuración es correcta no deberían aparecer mensajes como “Windows no puede comprobar el publicador de este software de controlador”. Ese tipo de avisos suelen indicar problemas con la cadena de certificados, firmas incompletas, catálogos no registrados o incompatibilidades con las políticas de firma del sistema.
Controladores en Windows 10 y gestión básica de drivers
Desde la perspectiva del usuario final o del técnico de soporte, la primera herramienta para revisar el estado de los controladores en Windows 10 es el Administrador de dispositivos. Aquí se muestra la lista completa de dispositivos instalados en el equipo: aquellos que funcionan correctamente aparecen sin símbolos de advertencia, mientras que los que tienen problemas se marcan con iconos amarillos o rojos.
La ruta más rápida para abrirlo es usar el buscador del menú Inicio escribiendo “Administrador de dispositivos”, o bien recurrir al menú contextual de Inicio (Win+X) y seleccionar la opción correspondiente. Desde esta consola se pueden actualizar, deshabilitar, desinstalar o inspeccionar las propiedades de cada driver, incluidas sus firmas digitales.
En un escenario ideal, la mayoría de dispositivos quedan cubiertos por drivers genéricos o específicos que el propio Windows descarga e instala a través de Windows Update. Sin embargo, cuando el sistema no reconoce un hardware concreto, aparecen “dispositivos desconocidos” que requieren una gestión más artesanal por parte del usuario o del administrador.
Dispositivos desconocidos y localización manual del driver adecuado
Cuando aparece un dispositivo desconocido con un icono de advertencia, el procedimiento más eficaz para identificarlo suele ser consultar su Id. de hardware. Desde sus propiedades, en la pestaña “Detalles”, se selecciona “Id. de hardware” y se copian las cadenas que empiezan por PCI, USB u otros prefijos. Estas cadenas incluyen el identificador de fabricante y modelo del dispositivo.
Con ese identificador en la mano, se puede buscar de forma segura el controlador correspondiente en las páginas oficiales del fabricante o, en algunos casos, en bases de datos especializadas de drivers. Una vez descargado el paquete, si se trata de un instalador ejecutable bastará con seguir el asistente; si en cambio llega como una carpeta repleta de archivos INF, SYS y demás, habrá que usar la opción “Buscar software de controlador en el equipo” indicando la ruta a esa carpeta.
En muchas ocasiones, sobre todo en equipos más antiguos o combinaciones de hardware no muy habituales, este tipo de búsqueda manual es la única forma viable de conseguir que el dispositivo funcione con normalidad, siempre teniendo cuidado de descargar drivers únicamente de fuentes fiables y no de portales genéricos que empaquetan controladores con software no deseado.
Drivers sin firma reconocida, modos especiales y opciones de seguridad
Windows 10 incluye una capa adicional de seguridad consistente en exigir que los controladores estén firmados por Microsoft o por proveedores de confianza. Esto tiene mucho sentido desde el punto de vista de la protección del sistema, pero puede convertirse en un obstáculo cuando se necesita instalar drivers legítimos que no están correctamente firmados o que no cuentan con una firma reconocida por el sistema.
En versiones anteriores de Windows se podía aceptar manualmente la instalación de un controlador no firmado mediante un simple “Instalar de todas formas”, pero a partir de Windows 10 esa puerta se ha cerrado en gran medida. Para instalar estos controladores ahora hay que recurrir a opciones como el inicio avanzado con la comprobación de firma deshabilitada, el modo de prueba o cambios en las directivas de grupo, dependiendo de la edición del sistema.
El método más conservador consiste en reiniciar Windows en un modo especial donde se desactiva temporalmente la obligatoriedad de controladores firmados. Esto se hace desde la configuración del sistema (Win+I → Actualización y seguridad → Recuperación) usando “Inicio avanzado” y, tras varios menús (“Solucionar problemas” → “Opciones avanzadas” → “Configuración de inicio”), seleccionando la opción que deshabilita el uso obligatorio de firmas de controladores. De este modo se puede instalar el driver necesario, aunque al siguiente reinicio la protección volverá a estar activa.
Desactivar la firma de drivers: Directivas de grupo, modo de prueba y comandos BCDEdit
En entornos más avanzados, como ediciones Pro o Enterprise de Windows 10/11, existe la opción de ajustar el comportamiento de la firma de controladores mediante directivas de grupo (Gpedit). Navegando por Configuración de usuario → Plantillas administrativas → Sistema → Instalación de controladores se encuentra la política “Firma de código para controladores de dispositivo”. Establecerla como “Deshabilitada” relaja la exigencia de firma, aunque conviene usarlo con precaución y tener claro el impacto sobre la seguridad.
Otra posibilidad es el Modo de prueba (TESTSIGNING), pensado para desarrolladores que están trabajando con drivers aún en fase de pruebas. Activando este modo con bcdedit /set TESTSIGNING ON (y reiniciando) se permite la carga de controladores firmados con certificados de prueba, normalmente emitidos por la propia organización. Mientras el sistema está en este modo, se muestra una marca de agua en el escritorio indicando que se está trabajando en un entorno de pruebas.
La opción más drástica pasa por desactivar completamente las comprobaciones de integridad de los controladores con comandos como bcdedit.exe /set nointegritychecks on. Esto permite instalar y cargar cualquier driver, esté o no firmado, y aunque puede ser útil en situaciones muy concretas (por ejemplo, al mantener hardware crítico sin soporte moderno en un entorno totalmente aislado), supone un riesgo de seguridad considerable. Siempre que se use este método, es recomendable volver a activarlo con bcdedit.exe /set nointegritychecks off una vez instalados los controladores necesarios.
Peligros de deshabilitar las protecciones de firma de controladores
Relajar o desactivar la política de firma de drivers abre la puerta a amenazas muy difíciles de detectar y aún más complicadas de erradicar: rootkits y malware con forma de controlador. Estos componentes se cargan con privilegios de SYSTEM y se ejecutan a muy bajo nivel, pudiendo monitorizar el tráfico, interceptar comunicaciones, bloquear antivirus y ocultarse de casi cualquier herramienta de seguridad.
Una vez que un falso controlador de este tipo se ha instalado con éxito, el sistema puede quedar completamente comprometido sin que haya síntomas evidentes. La detección por parte de las soluciones de seguridad tradicionales es muy complicada, ya que el malware se camufla como un driver legítimo. En muchos casos, la única forma fiable de recuperar un equipo infectado es formatear y reinstalar el sistema desde cero.
Por eso, cualquier software que nos insista en desactivar permanentemente la firma de drivers para “optimizar rendimiento”, “activar funciones ocultas” o promesas similares debe considerarse sospechoso. Siempre es preferible buscar alternativas: drivers oficiales actualizados, versiones firmadas, modos de prueba controlados o incluso mantener el hardware fuera de servicio si es necesario, antes que dejar el sistema desprotegido.
Drivers de Windows frente a drivers del fabricante: qué usar y cuándo
Un punto que genera bastante confusión es la diferencia entre los drivers genéricos que aporta Microsoft con el sistema y los controladores específicos de cada fabricante. Los primeros permiten que la mayoría de dispositivos funcionen “de serie” al conectar el hardware, pero suelen ofrecer solo las funciones básicas del componente.
Si, por ejemplo, se trata de una impresora multifunción, es probable que con los drivers de Windows se pueda imprimir sin problemas, pero puede resultar complicado acceder al escáner, a funcionalidades avanzadas de gestión de papel o a paneles de diagnóstico propios del fabricante. Para sacar todo el partido al dispositivo, lo ideal es instalar los controladores y software oficiales del proveedor, que suelen incluir firmas digitales válidas y más opciones de configuración.
A la hora de descargar drivers, es crítico asegurarse de que la web visitada es realmente la del fabricante y no un portal de terceros que actúa de intermediario. Un truco sencillo es comprobar cuidadosamente la URL del dominio y evitar instaladores genéricos que prometen “actualizar todos tus drivers” pero añaden adware o incluso malware. Siempre que la firma de controladores esté habilitada, Windows ayudará a bloquear este tipo de paquetes dudosos, mostrando advertencias o impidiendo su instalación.
Herramientas de actualización y diagnóstico de drivers
Para los usuarios que prefieren delegar parte del trabajo, existen utilidades especializadas en detectar drivers desactualizados y sugerir versiones más recientes, como Driver Booster, Driver Talent, AVG Driver Updater o soluciones más técnicas como Snappy Driver Installer o DriverPack Solution. Aunque pueden ser útiles para localizar paquetes difíciles de encontrar, conviene usarlas con prudencia y siempre verificando la procedencia de los controladores propuestos.
En el lado del diagnóstico, herramientas como DriverView, de Nirsoft, permiten listar todos los drivers instalados en el sistema y distinguir rápidamente cuáles pertenecen a Microsoft (con firmas válidas) y cuáles son de terceros. Esta aplicación muestra, por ejemplo, los controladores de Microsoft con fondo blanco y resalta en rojo aquellos que proceden de otras empresas, facilitando la identificación de posibles fuentes de problemas.
DriverView permite ordenar la lista por compañía, filtrar para ocultar los drivers de Microsoft y centrarse en los de terceros, y ver información detallada de cada uno al hacer doble clic: nombre, ruta, versión, empresa, etc. Con esa información, es más sencillo decidir si un controlador sospechoso forma parte de un software de confianza o es un candidato a ser desinstalado para mejorar la estabilidad o seguridad del sistema.
Smartcards, certificados en tarjeta y Bit4id PKI Manager
En entornos corporativos y administrativos, es muy habitual que los certificados usados para firma electrónica, autenticación o cifrado se almacenen en tarjetas inteligentes o tokens criptográficos. La gestión de estos dispositivos —incluyendo PIN, PUK, importación y exportación de certificados— requiere herramientas específicas como Bit4id PKI Manager y su middleware asociado.
Bit4id PKI Manager ofrece una vista de los dispositivos conectados (lectores de tarjetas, tokens) y, tras iniciar sesión con el PIN, permite ver los certificados de usuario y de Autoridad de Certificación (CA) alojados en el dispositivo. Desde su panel se pueden realizar tareas como desbloquear PIN con el PUK, cambiar el PIN o el PUK, iniciar y cerrar sesión en la tarjeta, renombrar el dispositivo o importar certificados en formato .p12/.pfx que incluyan la clave privada.
Al importar un certificado, la aplicación solicita seleccionar el archivo, introducir el PIN de la tarjeta, la contraseña del contenedor PFX/P12 y, opcionalmente, un identificador CKA_ID para uso con PKCS#11. A la inversa, también permite exportar certificados en formato .cer, conteniendo solo la clave pública, ya que la clave privada de una smartcard nunca se puede extraer por motivos de seguridad.
Una funcionalidad adicional interesante es la posibilidad de sincronizar automáticamente los certificados de la tarjeta con el almacén de certificados de Windows, algo imprescindible para que aplicaciones como Microsoft Edge, Chrome, Opera o Adobe Reader puedan utilizar esos certificados para autenticarse o firmar documentos PDF desde el propio navegador o aplicación.
Comprobación de certificados en Windows, navegadores y Adobe Reader
Para verificar que los certificados en tarjeta se han cargado correctamente en el sistema, se puede abrir el almacén de certificados de Windows con certmgr.msc desde el menú Inicio. Dentro de la carpeta “Personal” → “Certificados” deberían aparecer los certificados de usuario vinculados a la tarjeta si el middleware ha hecho bien su trabajo.
En el caso de Firefox, que mantiene su propio almacén de certificados independiente, es necesario revisar la sección de seguridad y certificados en las preferencias del navegador. Si se configuran correctamente los módulos PKCS#11 y se introduce el PIN cuando se pide, los certificados de la smartcard aparecerán también en las pestañas de certificados de usuario y de autoridades.
Para Adobe Acrobat Reader, la ruta pasa por el menú de “Preferencias” → “Firmas” → “Identidades y certificados de confianza” y la sección de “IDs digitales de Windows”. Si los certificados están en el almacén de Windows, Adobe podrá utilizarlos directamente para firmar digitalmente documentos PDF. El flujo típico consiste en seleccionar “Usar un certificado”, elegir el área del PDF donde se colocará la firma, escoger el certificado adecuado y completar el proceso introduciendo el PIN de la tarjeta cuando se solicite.
Solución de problemas frecuentes con drivers y certificados
Cuando un controlador empieza a comportarse de forma errática o un componente de hardware deja de funcionar, lo primero es revisar el icono correspondiente en el Administrador de dispositivos. Un icono amarillo indica un problema con el driver: puede estar dañado, desactualizado, mal firmado o entrar en conflicto con otra pieza de software.
Entre las acciones recomendadas se encuentran el uso del solucionador de problemas de hardware integrado en Windows, la actualización manual del controlador desde el Administrador de dispositivos, la desinstalación y reinstalación del driver o incluso volver a una versión anterior si una actualización reciente ha introducido el fallo. En muchos casos, simplemente permitiendo que Windows Update reinstale el controlador se resuelven los conflictos.
En escenarios más complejos, como instalaciones multiarranque con sistemas antiguos, errores del tipo “Los certificados de firma no están instalados” al instalar drivers de GPU en Windows 7, puede ser necesario extraer manualmente los archivos del instalador del fabricante y apuntar desde el Administrador de dispositivos a la carpeta de extracción para forzar la instalación del INF correcto. También ayuda asegurarse de que Windows 7 tenga las actualizaciones que habilitan SHA‑2 (como KB3033929) y, si todo falla, valorar si es viable desactivar temporalmente la firma de drivers en ese sistema concreto, siempre que permanezca aislado y con drivers de fuente confiable.
Finalmente, cuando el problema se relaciona con certificados en smartcard (PIN inconsistentes, errores al iniciar sesión en el middleware, fallos al cargar certificados en el almacén), conviene recopilar toda la información de diagnóstico del PKI Manager, versiones instaladas, resultados de pruebas en navegadores y aplicaciones, y remitirla al proveedor de la tarjeta o a la Autoridad de Certificación para agilizar la resolución de la incidencia.
A la vista de todo lo anterior, queda claro que la gestión avanzada de certificados y firmas de drivers en Windows no es solo una cuestión de “que el dispositivo funcione”, sino de combinar seguridad, compatibilidad y buenas prácticas: elegir bien los certificados de firma de código, controlar su ciclo de vida en el Centro de partners, respetar las políticas de SHA‑2, saber cuándo y cómo relajar las restricciones de firma, aprovechar herramientas como DriverView o Bit4id PKI Manager y, sobre todo, descargar e instalar siempre controladores y certificados de fuentes confiables, manteniendo el equilibrio entre estabilidad, funcionalidad y protección frente a amenazas de bajo nivel.