Chứng chỉ và chữ ký trình điều khiển trong Windows: hướng dẫn đầy đủ

Trong Windows, controladores y sus firmas digitales se han convertido en una pieza clave de la seguridad del sistema. Más allá de que un driver haga funcionar una impresora, una tarjeta gráfica o una tarjeta inteligente, lo importante hoy en día es que el sistema pueda comprobar que ese software es auténtico, íntegro y que procede de un proveedor en el que se puede confiar.

Si alguna vez te has encontrado con mensajes del tipo “Windows no puede verificar el publicador de este software de controlador” o errores relacionados con certificados al instalar un driver, ya sabes lo frustrante que puede ser. En este artículo vamos a desgranar con calma cómo funciona la firma de controladores en Windows (tanto en modo kernel como en modo usuario), qué requisitos cambian según la versión de Windows, cómo firmar tus propios drivers y qué opciones tienes para desactivar, de forma segura, la comprobación de firmas cuando no te queda más remedio.

Qué es la firma de controladores en Windows y por qué es tan importante

Cuộc gọi chữ ký của tài xế no es otra cosa que asociar una firma digital (basada en certificados) a un paquete de drivers. Esa firma se aplica generalmente al archivo de catálogo (.CAT) del paquete o directamente a los binarios del controlador (.SYS, .DLL, etc.) mediante técnicas de firma incrustada.

Durante la instalación de un dispositivo, Windows utiliza estas firmas digitales para dos cosas clave: comprobar que el paquete no ha sido modificado desde que se firmó (integridad) y confirmar la identidad del proveedor de software (editor del controlador). Si algo no cuadra, salta un aviso o, en los escenarios más estrictos, directamente se bloquea la instalación o la carga del driver.

En las versiones de 64 bits de Windows Vista y posteriores, Microsoft introdujo una política bastante clara: todo driver en modo kernel debe ir firmado para poder cargarse, salvo contadas excepciones. Esto sitúa a los drivers en la misma liga de seguridad que el resto de binarios del sistema, porque un fallo a nivel de kernel puede comprometer completamente el equipo.

Las reglas se han ido endureciendo con el tiempo. A partir de la versión 1507 de Windows 10, todos los controladores firmados a través del Centro de desarrollo de phần cứng Microsoft se firman obligatoriamente con SHA‑2. El viejo SHA‑1 quedó obsoleto por motivos de seguridad criptográfica, y Microsoft lo ha ido retirando de forma progresiva de todo el ecosistema.

Hay un detalle importante: los binarios de drivers de modo kernel firmados con certificados duales (SHA‑1 + SHA‑2) emitidos por entidades que no son Microsoft pueden tener problemas en sistemas anteriores a Windows 10, o incluso llegar a provocar bloqueos en Windows 10 y posteriores. Para evitarlo, Microsoft publicó la actualización KB3081436, que incluye los hashes correctos de los archivos y corrige comportamiento de carga en estos casos.

Visión general de la firma de drivers en Windows

Para entender bien cómo funciona todo esto, conviene separar conceptos. Por un lado está la firma de código del driver (modo kernel o modo usuario) y, por otro, los requisitos de firma de instalación de dispositivos Plug and Play (PnP). Aunque van de la mano, no son exactamente lo mismo: puedes tener un controlador correctamente firmado a nivel de binario, pero que no cumpla algún requisito extra de instalación.

Microsoft cuenta con documentación específica sobre firmas digitales para módulos de kernel en sistemas Windows Vista y posteriores, donde detalla qué certificados son válidos, cómo se deben construir las cadenas de confianza y qué algoritmos de hash se admiten (actualmente SHA‑2). Para drivers que transmiten contenido protegido (audio y vídeo con DRM, PUMA, PAP, PVP‑OPM, etc.), existen además requisitos especiales de firma de código centrados en la protección de contenidos multimedia.

En cuanto al flujo de publicación, hoy hay varias formas de enviar controladores al portal de hardware de Microsoft. Para controladores de producción, la vía estándar es ejecutar pruebas con el HLK o el antiguo HCK y subir tanto el binario como los registros de prueba. Para escenarios de solo cliente en Windows 10, se puede recurrir a la firma de atestación, que reduce la exigencia de pruebas automatizadas pero mantiene la validación y firma por parte de Microsoft.

También sigue existiendo la opción de chữ ký thử nghiệm pensada para desarrollo y test internos, donde se utilizan certificados no públicos o emitidos por una PKI propia. Esos drivers sólo se cargarán si el sistema está configurado en modo prueba o con políticas específicas que permitan controladores de test.

Excepciones y controladores con firma cruzada

En versiones intermedias de Windows 10, los llamados “controladores con firma cruzada” (cross-signed) todavía se permiten bajo ciertas condiciones. Estos son drivers firmados por el propio proveedor con un certificado Authenticode que se encadena a un certificado intermedio firmado por Microsoft, sin pasar por el flujo completo del portal de hardware.

Microsoft mantiene varias excepciones para no dejar sin arrancar sistemas ya desplegados. Se permiten controladores con firma cruzada si se da alguna de estas situaciones: el equipo se actualizó desde una versión anterior de Windows a Windows 10 versión 1607; các khởi động seguro (Secure Boot) está desactivado en la BIOS/UEFI; o el controlador está firmado con un certificado emitido antes del 29 de julio de 2015 que se encadena a una CA firmada cruzada soportada.

Para reducir riesgos de dejar un sistema inservible, los controladores de arranque no se bloquean aunque no cumplan las nuevas políticas, pero el Asistente para compatibilidad de programas puede marcarlos y proponer su eliminación o sustitución. La idea es no romper la secuencia de arranque, pero ir retirando poco a poco drivers no conformes.

Requisitos de firma por versión de Windows

Las exigencias de firma cambian dependiendo de la versión concreta del sistema operativo y de si el equipo utiliza Secure Boot. A grandes rasgos, la tabla de políticas de firma para ediciones cliente se resume así:

• Windows Vista và cửa sổ 7, y también Windows 8+ con arranque seguro desactivado: en 64 bits se requiere firma, mientras que en 32 bits no se pedía firma obligatoria. La firma puede ir incrustada en el archivo o en un catálogo asociado, y el algoritmo exigido es SHA‑2. La cadena de certificados debe terminar en raíces estándar de confianza para la Integridad de Código.
• Windows 8 y 8.1, y Windows 10 versiones 1507 y 1511 con Secure Boot activado: tanto 32 bits como 64 bits necesitan drivers firmados. Se sigue permitiendo firma incrustada o de catálogo, con SHA‑2, confiando en las raíces estándar para integridad de código.
• Windows 10 versiones 1607, 1703 y 1709 con Secure Boot: la exigencia se endurece y se requiere que las firmas estén ancladas a certificados raíz de Microsoft específicos (Microsoft Chân răng Authority 2010, Microsoft Root Certificate Authority y Microsoft Root Authority).
• Windows 10 versión 1803 y posteriores con Secure Boot: se mantienen los mismos requisitos de firmas ancladas a las autoridades raíz de Microsoft mencionadas, para 32 y 64 bits.

Junto a la firma del código de controlador, el paquete también debe cumplir con los requisitos de firma para instalación de dispositivos PnP. Esto implica que los archivos .INF, los catálogos y los binarios deben estar correctamente relacionados y reflejados en la firma para que el instalador de dispositivos (y el Trình quản lý thiết bị) los consideren válidos.

Existen además tipos especiales de drivers como los ELAM (Phần mềm chống phần mềm độc hại ra mắt sớm), que se cargan muy temprano en el proceso de arranque para proteger el sistema frente a phần mềm độc hại de bajo nivel. Estos controladores tienen requisitos adicionales de firma y certificación documentados en la guía de antimalware de arranque temprano.

Firmar un controlador para Windows 10, Windows 8.x y Windows 7

Si eres desarrollador de drivers o trabajas en un entorno donde se distribuyen controladores personalizados, necesitas cumplir el Programa de compatibilidad de hardware de Windows (WHCP) usando las herramientas adecuadas para cada versión: HLK para Windows 10 y HCK para versiones anteriores.

En el caso de Windows 10, el flujo típico sería: descargar el Hardware Lab Kit (HLK) correspondiente a cada versión de Windows 10 que quieras soportar, instalar el entorno de pruebas y ejecutar un pase completo de certificación en un cliente que ejecute esa versión. Cada ejecución generará un registro de pruebas.

Si has probado el controlador en varias versiones, tendrás múltiples registros. Lo habitual es combinar todos los các bản ghi en un único informe usando la versión más reciente de HLK. Esa combinación facilita el envío al portal de hardware y permite que una misma firma cubra varias versiones del sistema.

Una vez tengas los registros, envías el binario del controlador y los resultados combinados de HLK al panel del Centro para desarrolladores de hardware de Windows. Allí eliges el tipo de firma que quieres (por ejemplo, producción, atestación, etc.), configuras las propiedades del envío y esperas a que el proceso automático de Microsoft genere los catálogos firmados y te devuelva el paquete ya certificado.

Para Windows 7, Windows 8 y Windows 8.1 se sigue un enfoque similar pero usando el Hardware Certification Kit (HCK) adecuado a cada versión. Microsoft mantiene una guía de usuario para este kit donde se explica el flujo de pruebas, validación y envío.

Firma de drivers para versiones anteriores a Windows 10 versión 1607

Antes de la llegada de Windows 10 versión 1607, muchos tipos de drivers necesitaban un certificado Authenticode combinado con un certificado cruzado de Microsoft. Esta técnica, conocida como firma cruzada, permitía a los fabricantes firmar sus drivers y que Windows los aceptara como si estuvieran “bendecidos” por la infraestructura de Microsoft.

Entre los controladores que requerían este modelo de firma se encontraban los drivers de dispositivos en modo kernel, los drivers en modo usuario que interactúan estrechamente con el kernel y los controladores utilizados para reproducir o procesar contenido protegido (audio y vídeo con DRM). En estos últimos se incluyen drivers de audio basados en PUMA o PAP, así como controladores de vídeo que gestionan protección de salida (PVP‑OPM).

La firma de código para componentes multimedia protegidos tiene sus propias guías, ya que la cadena de confianza y las extensiones de certificado deben garantizar que el contenido protegido no se pueda interceptar ni manipular fácilmente.

Uso práctico de SignTool para firmar drivers en modo kernel (Windows 7 y 8)

En el terreno práctico, la herramienta reina para firmar binarios en Windows es Dấu hiệuCông cụ, incluida en el SDK de Windows. Para controladores de modo kernel en Windows 7 y 8, hay una serie de opciones que resultan especialmente útiles a la hora de firmar y verificar.

Entre los parámetros más importantes de SignTool destacan: /ac para añadir un certificado adicional (como el certificado cruzado de Microsoft), /f para indicar el archivo que contiene el certificado de firma (por ejemplo, un .pfx), /p para la contraseña de ese PFX, /fd para especificar el algoritmo de hash (por ejemplo, /fd sha256 para forzar SHA‑256, ya que SHA‑1 es el valor por defecto histórico).

También resulta fundamental el parámetro /n «Nombre común del certificado», que permite seleccionar el certificado correcto desde el almacén de certificados de Windows usando su Common Name. Y para añadir marcas de tiempo, puedes usar /t con un servidor Authenticode clásico o /tr con un servidor compatible con RFC 3161, que es lo más moderno y recomendable.

Un posible flujo sería recopilar los binarios del controlador en un directorio de trabajo o incluso copiar todo a la carpeta bin del SDK de Windows. Después se adquiere el certificado de firma de código y, si hace falta, el certificado cruzado de Microsoft (por ejemplo, el CrossCert correspondiente a la CA que emitió tu certificado). Ambos se colocan en el mismo directorio desde el que vas a ejecutar SignTool.

Con todo listo, el comando de ejemplo podría ser algo como: signtool sign /ac CrossCert.crt /f CodeSign.pfx /p password1234 /fd sha256 /tr http://timestamp.globalsign.com/tsa/r6advanced1 filter.sys. Esto genera una firma moderna con SHA‑256, incluye el certificado cruzado y añade marca de tiempo RFC 3161, imprescindible para que la firma siga siendo válida incluso cuando caduque el certificado.

Una vez firmado, se recomienda verificar con un comando como signtool verify -v -kp filter.sys. El flag -v muestra información detallada, mientras que -kp comprueba la firma según los criterios de drivers de modo kernel. Si la salida indica que la firma es válida y que la cadena de confianza termina en una raíz aceptada, el driver está listo para desplegarse.

No hay que olvidar que, en muchos casos, también se firma el archivo de catálogo (.CAT). El flujo se repite: se firma el .CAT, se verifica y, cuando todo cuadra, se procede a la instalación normal del controlador en el sistema.

Firma por atestación y creación de paquetes CAB

Microsoft ofrece la firma por atestación como vía relativamente ligera para distribuir controladores, especialmente en sistemas cliente de Windows 10. El proveedor se responsabiliza de que el driver cumple los requisitos, y Microsoft se limita a validar y firmar, evitando la batería completa de pruebas HLK en algunos escenarios.

Para enviar un controlador mediante atestación, normalmente se prepara un archivo CAB que agrupa los componentes esenciales del paquete. Un CAB típico incluye el propio controlador binario (.SYS), el archivo INF (.INF) que usará Windows durante la instalación, los símbolos de depuración (.PDB) para análisis de fallos y, en ocasiones, catálogos .CAT que Microsoft utilizará de referencia para comprobar la estructura (aunque luego genera catálogos propios para la distribución final).

La forma de crearlo es sencilla: se recopilan todos los archivos que se van a firmar en un directorio único, por ejemplo C:\Echo. Desde una ventana de lệnh con privilegios de administrador, se consulta la ayuda de MakeCab para ver sus opciones y se prepara un archivo DDF con las directivas necesarias indicando qué archivos se van a comprimir, qué cabina se va a generar y en qué subcarpetas deben quedar organizados dentro del CAB.

Para el ejemplo de un controlador Echo, el archivo DDF podría fijar el nombre de salida como Echo.cab, activar la compresión MSZIP y definir un directorio de destino (DestinationDir=Echo) de manera que dentro de la cabina no haya archivos sueltos en la raíz. Luego se listan las rutas completas de Echo.inf y Echo.sys para que MakeCab los incluya.

Con el DDF listo, se ejecuta algo como MakeCab /f Echo.ddf. La herramienta mostrará cuántos archivos ha incluido, el nivel de compresión alcanzado y en qué carpeta (normalmente Disk1) ha depositado el CAB resultante. Basta con abrir el archivo Echo.cab con el Explorador para confirmar que contiene todo lo esperado.

Firmar el CAB con un certificado EV y enviarlo al Centro de Partners

Antes de subir el paquete al portal de hardware de Microsoft, lo normal es firmar el CAB con un certificado EV (Extended Validation). Estos certificados, más estrictos en la validación de la entidad, aportan un plus de confianza y suelen ser requisito para ciertos tipos de firma.

El proceso varía un poco según el proveedor de certificados EV, pero la idea general consiste en usar de nuevo SignTool, esta vez apuntando al CAB. Un comando típico podría ser: SignTool sign /s MY /n «Company Name» /fd sha256 /tr http://sha256timestamp.ws.symantec.com/sha256/timestamp /td sha256 /v C:\Echo\Disk1\Echo.cab, lo que añade una firma SHA‑256 con marca de tiempo SHA‑256 a la cabina.

Tras firmar, se accede al Centro de partners de Microsoft, concretamente al panel de hardware, y se inicia sesión con las credenciales de la organización. Desde allí se elige la opción de “Enviar nuevo hardware”, se sube el archivo CAB firmado y se rellenan las propiedades del envío: nombre de producto, tipo de firma requerida, si se desea firma de prueba o sólo de producción, etc.

Điều quan trọng là no activar las opciones de firma de prueba si lo que se busca es un controlador de producción. En la sección de firmas requeridas se eligen las variantes que se desean incluir en el paquete (por ejemplo, firmas para distintas versiones de Windows o arquitecturas).

Una vez completado el formulario, se pulsa en Enviar y se deja que el portal procese el paquete. Cuando Microsoft termina de firmar el controlador, el panel indicará que el envío ha sido procesado y permitirá descargar el driver ya firmado, normalmente acompañado de los catálogos y metadatos necesarios para su distribución.

Validar que el controlador está firmado correctamente

Con el paquete descargado, toca comprobar que todo está en orden. Lo primero es extraer los archivos del envío a una carpeta temporal y abrir una ventana de comandos con đặc quyền quản trị viên. Desde ahí se puede usar SignTool para verificar las firmas aplicadas a los binarios clave.

Un comando básico sería SignTool verify Echo.sys, que comprueba rápidamente la validez de la firma. Si queremos una verificación más completa, se puede recurrir a SignTool verify /pa /ph /v /d Echo.sys, donde /pa indica que se utilice la política Authenticode, /ph añade comprobación del hash y /v genera salida detallada con toda la información de la cadena de certificados.

Para revisar las EKU (Usos mejorados de clave) del certificado utilizado en la firma, se puede usar el propio Explorador de Windows: botón derecho sobre el binario, Propiedades, pestaña “Firmas digitales”, seleccionar la entrada correspondiente y pulsar en “Detalles”. Desde “Ver certificado” y la pestaña “Detalles” se puede inspeccionar el campo “Uso mejorado de claves” para confirmar que incluye las extensiones adecuadas para firma de código o firma de drivers.

El proceso interno de algunos flujos de firma implica que Microsoft vuelva a insertar una firma SHA‑2 propia en el binario, eliminando las firmas que haya aplicado el cliente si no cumplen las políticas actuales. También se genera un nuevo archivo de catálogo firmado por Microsoft que sustituye a cualquier .CAT previo enviado por el proveedor.

Prueba e instalación del controlador en Windows

Una vez firmado el driver, queda comprobar que se instala y funciona en el sistema objetivo. Desde una consola de administrador se puede recurrir a herramientas como nhà phát triển para automatizar la instalación. Por ejemplo, si el paquete contiene un echo.inf que define un dispositivo root\ECHO, bastaría con ejecutar devcon install echo.inf root\ECHO en la carpeta adecuada.

Durante este proceso, si todo está correctamente firmado, no deberían aparecer avisos del estilo “Windows no puede comprobar el publicador de este software de controlador”. Si aparecen, es indicio de que algo en la cadena de confianza o en los catálogos no está bien alineado, y conviene revisar tanto las firmas como los certificados raíz instalados en el sistema.

En escenarios más complejos, es posible crear envíos con múltiples controladores. Para ello lo habitual es generar subcarpetas separadas dentro de la estructura de archivos, una por cada paquete de driver (DriverPackage1, DriverPackage2, etc.), y ajustar el archivo DDF para que cada conjunto de .SYS y .INF quede en su propia subcarpeta en el CAB. MakeCab se encarga de montar todo en una única cabina lista para enviar al portal.

Firma de controladores desde el punto de vista del usuario

Desde el lado del usuario final, la firma de drivers se percibe como un filtro de seguridad integrado en Windows. Igual que con las aplicaciones firmadas, la idea es que el usuario sepa que el software procede de una fuente legítima y que no ha sido alterado. Sin embargo, en el caso de los controladores la exigencia es mayor, porque operan a un nivel de privilegios muy alto.

Cuando un driver está correctamente firmado y publicado a través de los canales oficiales, Windows Update o el propio sistema operativo lo distribuyen de forma bastante transparente. Esto facilita que el usuario reciba versiones actualizadas y corregidas sin tener que buscar nada manualmente, con el respaldo de que han pasado por los filtros de Microsoft.

El problema surge cuando se necesita instalar controladores que no están firmados digitalmente o cuya firma ya no es aceptada por las políticas actuales (por ejemplo, al tratar de usar hardware antiguo en sistemas nuevos). En estas situaciones, Windows bloquea la instalación o muestra advertencias reiteradas, lo que obliga a recurrir a soluciones más avanzadas para poder seguir adelante.

Métodos para instalar drivers no firmados (y sus riesgos)

Hay varios caminos para instalar drivers que no cumplen las políticas de firma, pero es fundamental tener presente que cada método implica un nivel de riesgo distinto. No es lo mismo un ajuste temporal que se revierte al reiniciar que desactivar completamente las comprobaciones de integridad.

Un método muy utilizado es arrancar Windows desactivando temporalmente el uso obligatorio de controladores firmados. Para eso se reinicia el equipo entrando en las opciones avanzadas (por ejemplo desde el menú Inicio, pulsando Shift mientras se hace clic en Reiniciar), se accede a Solucionar problemas > Opciones avanzadas > Configuración de inicio y se elige la opción “Desactivar el uso obligatorio de controladores firmados”. El sistema arrancará esa vez sin exigir firma, lo que permite instalar el driver. Al reiniciar de nuevo, la protección vuelve a aplicarse automáticamente.

Otra opción, disponible sólo en Windows 10/11 Pro y ediciones superiores, es usar el Editor de directivas de grupo (gpedit.msc). Dentro de Configuración de usuario > Plantillas administrativas > Sistema > Instalación de controladores, se puede editar la directiva “Firma de código para controladores de dispositivo” y establecerla como Deshabilitada. Tras reiniciar, Windows será mucho más permisivo con los controladores sin firma o con firmas cuestionables.

Para escenarios de prueba y desarrollo existe el llamado Chế độ thử nghiệm de Windows. Se activa desde una consola de administrador ejecutando un comando de bcdedit, y permite cargar drivers firmados con certificados de test sin necesidad de pasarlos por la infraestructura pública. En este modo suele aparecer una marca de agua en el escritorio indicando que el sistema está en modo de prueba.

Finalmente, está la vía más extrema: desactivar por completo la comprobación de integridad de controladores mediante bcdedit.exe (parámetro nointegritychecks). Esto deja al sistema totalmente expuesto a la instalación de cualquier driver, legítimo o no, y sólo debería usarse en casos muy concretos y sabiendo exactamente qué se está haciendo.

Peligros reales de desactivar la firma de controladores

Deshabilitar esta protección no es sólo una molestia menor, sino que abre la puerta a una de las amenazas más difíciles de detectar: los rootkits a nivel de driver. Estos se instalan como si fueran controladores legítimos, pero una vez cargados disponen de permisos de SYSTEM y capacidad para monitorizar o manipular el sistema a muy bajo nivel.

Un rootkit de este tipo puede interceptar el tráfico de Internet, insertar certificados falsos, redirigir conexiones a sitios controlados por atacantes, bloquear la instalación de antivirus y facilitar la entrada de otro malware. Todo esto sin dejar prácticamente rastro visible para el usuario, ni siquiera para muchas soluciones de seguridad tradicionales.

Al operar con los máximos privilegios, estos drivers maliciosos son prácticamente invisibles y difíciles de eliminar. En muchos casos, la única solución realista pasa por định dạng el PC por completo y empezar desde cero, lo que supone una pérdida importante de tiempo y datos si no hay copias de seguridad al día.

Por eso, cuando una aplicación te pide que desactives la firma de controladores para instalar “algo mágico”, conviene desconfiar. Siempre que sea posible, es preferible buscar alternativas o versiones firmadas, incluso aunque suponga renunciar a cierto hardware obsoleto o a alguna funcionalidad concreta.

Drivers de Windows frente a drivers del fabricante

Al instalar periféricos y componentes, Windows suele ofrecer trình điều khiển chung que permiten utilizar el hardware de manera básica. Por ejemplo, una impresora multifunción puede imprimir sin problema con el driver genérico, pero si queremos escanear, usar el alimentador automático o acceder a opciones avanzadas, casi seguro necesitaremos el paquete oficial del fabricante.

Lo mismo ocurre con tarjetas de sonido, tarjetas gráficas y otros dispositivos complejos: con drivers genéricos el equipo funciona, pero se pierden prestaciones, optimizaciones de rendimiento o herramientas de configuración avanzadas. En muchos casos, los drivers oficiales ofrecen también correcciones de errores específicas que nunca llegan a los controladores genéricos de Microsoft.

El lugar adecuado para descargar estos controladores es siempre la web oficial del fabricante del hardware. Cuando se busca en Google, es frecuente que aparezcan primero páginas de terceros llenas de “descargadores de drivers” o instaladores sospechosos. Si el enlace no pertenece al dominio del fabricante, lo más prudente es ignorarlo.

Si la firma de controladores sigue activada, muchos de estos paquetes dudosos serán bloqueados por Windows al detectar que no se trata de software válido o que las firmas no están en orden. Esto actúa como una red de seguridad extra frente a instaladores torpes o directamente maliciosos.

Caso práctico: error de certificados de firma con drivers de GPU en Windows 7

En equipos con sistemas antiguos como Windows 7 64-bit, es relativamente común tropezar con problemas al instalar drivers modernos de tarjetas gráficas o de otro hardware reciente. Un ejemplo típico es el error “Los certificados de firma no están instalados. Por favor, instala los certificados requeridos” al intentar instalar drivers de Nvidia para GPUs como la GTX 1060 o la GTX 950.

En muchos casos, aunque el usuario desactive la firma de drivers al arrancar, el controlador no llega a funcionar tras reiniciar porque la política de firma vuelve a activarse. Se han probado soluciones como instalar todas las versiones previas del driver, usar instaladores alternativos (como Snappy Driver Installer), aplicar actualizaciones de soporte SHA‑2 (como KB3033929) o reinstalar desde el Administrador de dispositivos, sin éxito.

Una solución práctica que ha funcionado consiste en extraer manualmente el contenido del instalador de la versión 474.11 (último driver WHQL para Windows 7) a una carpeta y, desde el Administrador de dispositivos, actualizar el controlador de la GPU eligiendo la opción de buscar el driver en el equipo y señalando esa carpeta. El mismo método puede fallar con otras versiones posteriores, como la 474.14, si el asistente no reconoce los archivos INF como válidos para ese sistema.

Este tipo de casos ilustra hasta qué punto puede ser delicado el equilibrio entre drivers recientes, certificados SHA‑2 y hệ điều hành ya sin soporte. Cada vez es más complicado instalar -y mantener seguros- controladores modernos en plataformas antiguas que no reciben actualizaciones ni correcciones de seguridad.

Cómo detectar y solucionar problemas con drivers defectuosos

Aunque los controladores estén correctamente firmados, pueden estropearse o quedar en un estado inconsistente por muchos motivos: conflictos con otros programas, malware, instalaciones interrumpidas, actualizaciones de Windows que no terminan bien, etc. Cuando esto pasa, el dispositivo afectado suele dejar de funcionar o lo hace de forma errática.

La primera herramienta de diagnóstico es el Trình quản lý thiết bị. Pulsando con el botón derecho en el botón Inicio y eligiendo la opción correspondiente, se abre una lista completa de todo el hardware detectado. Si un dispositivo tiene problemas con su driver, aparecerá marcado con un icono de advertencia amarillo.

En estos casos, un primer intento de solución es hacer clic derecho sobre el dispositivo, elegir “Actualizar controlador” y dejar que Windows busque un driver más adecuado, ya sea localmente o en Windows Update. Si eso no da resultado, se puede desinstalar el dispositivo (manteniendo o no el software de controlador) y reiniciar para que Windows intente reinstalarlo desde cero.

Ngoài ra, Windows còn bao gồm một trình khắc phục sự cố phần cứng và thiết bị dentro del panel de Configuración, concretamente en la sección “Actualización y seguridad” > “Solucionar problemas”. Este asistente escanea el sistema en busca de irregularidades y propone acciones automatizadas para restablecer el funcionamiento de algunos controladores.

Si una actualización concreta del driver ha provocado el problema, puede venir bien usar la opción de “Volver al controlador anterior” en la pestaña “Controlador” de las propiedades del dispositivo, siempre que Windows conserve la versión previa. Esto revierte la instalación problemática y puede devolver la estabilidad al sistema.

Ver y analizar drivers de terceros instalados en Windows

Para tener un mayor control sobre lo que hay instalado en el sistema, se pueden usar herramientas de terceros como Chế độ xem trình điều khiển de Nirsoft, que muestra una lista detallada de todos los controladores cargados en el equipo. Es una utilidad gratuita y portátil que facilita mucho la auditoría de drivers.

DriverView utiliza un código de colores muy sencillo: controladores de Microsoft con firma digital válida aparecen con fondo blanco, mientras que los drivers de terceros (propios de fabricantes o software adicional) se resaltan en rojo. Esto ayuda a identificar rápidamente qué piezas del puzzle no dependen directamente del sistema operativo.

La lista se puede ordenar por columnas, por ejemplo por “Company” para agrupar todos los drivers provenientes de la misma empresa. Además, en el menú View suele haber una opción para ocultar todos los controladores de Microsoft y mostrar sólo los de terceros, lo que permite centrarse en los que más probabilidades tienen de causar conflictos.

Haciendo doble clic sobre cualquier entrada se abre una ventana con información detallada del driver: versión, ruta completa, descripción, fabricante, fecha de carga, etc. En el caso de controladores desconocidos o sospechosos, estos datos ayudan a determinar si forman parte de un programa que realmente usamos o si conviene investigar más a fondo e incluso desinstalarlos.

Con todo este panorama, queda claro que las firmas de controladores y los certificados en Windows no son un mero formalismo, sino un engranaje fundamental para mantener la estabilidad y la seguridad del sistema. Conocer cómo se firman los drivers, qué requisitos cambian entre versiones de Windows, qué herramientas existen para validar y cómo actuar cuando un controlador no está firmado o falla, nos permite aprovechar al máximo nuestro hardware sin perder de vista la protección frente a amenazas de muy bajo nivel.