Lic. Carlos Enrique Loria Beeche.
En los últimos meses varios administradores comenzaron a notar algo que, a primera vista, parecía un “nuevo problema” de Escritorio Remoto: conexiones que antes abrían de inmediato ahora muestran advertencias, piden confirmación adicional o presentan mensajes como “Editor desconocido” o “Conexión remota desconocida”.
La reacción natural ha sido pensar que Windows “rompió RDP”, que hay una actualización defectuosa o que ahora el equipo remoto exige alguna autorización nueva. Sin embargo, el cambio principal no va exactamente por ahí. Lo que Microsoft endureció fue, sobre todo, la apertura de archivos .rdp como medida de seguridad para reducir ataques de phishing y conexiones inducidas a sistemas controlados por terceros.
Si en las últimas semanas usted o sus usuarios comenzaron a ver ventanas como estas, no están imaginando cosas: Microsoft introdujo nuevos avisos de seguridad al abrir archivos .rdp, con el fin de hacer más visibles el destino de la conexión, el publicador del archivo y los recursos locales que podrían quedar expuestos.
Windows explica el nuevo riesgo asociado a archivos
.rdp.
Windows muestra “Editor desconocido” o “Unknown publisher”.
El cuadro cambia y permite verificar el publicador del archivo.
Estas pantallas no significan necesariamente que el servidor remoto esté dañado o comprometido. En muchos casos, lo que ha cambiado es la manera en que Windows trata los archivos .rdp para reducir ataques de phishing y conexiones inducidas a destinos no confiables.
Este artículo resume qué cambió, desde cuándo comenzó a aplicarse, qué significa técnicamente cada advertencia, cómo se relaciona esto con la firma de archivos .rdp, y por qué conviene no confundir esa firma con el certificado TLS del servidor RDP.
Contenido
- Desde cuándo cambió RDP
- Qué cambió exactamente
- Qué significa “Editor desconocido”
- Lo que muchos están confundiendo
- ¿Sirve un certificado autofirmado?
- Qué debería hacer un administrador
- Ejemplo de firma y comandos útiles
- Una nota importante sobre enero de 2026
- Enlaces oficiales que conviene tener a mano
Desde cuándo cambió RDP
Microsoft anunció el 14 de abril de 2026 que, a partir de la actualización de seguridad de abril de 2026, Remote Desktop añadiría nuevas salvaguardas para conexiones iniciadas desde archivos .rdp. El objetivo declarado fue reducir ataques de phishing en los que un usuario es inducido a abrir un archivo .rdp que lo conecta a un destino no confiable y, además, intenta redirigir recursos locales como portapapeles, impresoras, tarjetas inteligentes u otros elementos del equipo cliente.
En otras palabras, no se trata de que “RDP dejó de funcionar”, sino de que Windows empezó a mostrar con más claridad a dónde se conectará el usuario, quién firmó el archivo cuando esa información exista, y qué recursos locales pretende exponer la sesión remota.
Esto explica por qué muchos usuarios perciben que “antes conectaba directo y ahora pide autorización”. En realidad, esa nueva capa de confirmación está orientada a las conexiones iniciadas abriendo un archivo .rdp.
Qué cambió exactamente
Según la documentación de Microsoft, el cambio incorpora dos ideas principales:
- Un nuevo cuadro de seguridad antes de establecer la conexión, mostrando el equipo remoto, el publicador cuando se puede verificar y los recursos locales que el archivo solicita redirigir.
- Las configuraciones solicitadas por el archivo relacionadas con redirección quedan en un modo más cauteloso: el usuario debe habilitarlas de forma explícita antes de conectar.
Además, Microsoft documenta un aviso inicial de una sola vez la primera vez que se abre un archivo .rdp después de aplicar la actualización correspondiente.
Hay un detalle muy importante: Microsoft aclara que este cambio no afecta la experiencia cuando el usuario abre manualmente Conexión a Escritorio remoto y escribe directamente el nombre o la IP del equipo remoto en el cliente mstsc. Es decir, el endurecimiento está centrado en el flujo basado en archivos .rdp.
Qué significa “Editor desconocido” o “Conexión remota desconocida”
Cuando el nuevo cuadro muestra algo como “Editor desconocido” o “Unknown publisher”, Microsoft indica que eso significa, en esencia, que el archivo .rdp está sin firma o que la firma no puede verificarse como confiable en el cliente.
Eso no equivale automáticamente a que el servidor remoto esté comprometido, ni significa por sí solo que el host de destino tenga un problema. Lo que Windows está diciendo es otra cosa: no puede confirmar quién publicó ese archivo de conexión.
Por esa razón, dos situaciones muy distintas terminan viéndose parecidas para el usuario final:
- un servidor perfectamente válido al que se llega mediante un
.rdpcorporativo no firmado; - un archivo potencialmente malicioso enviado por correo o descargado desde una fuente no confiable.
Windows endurece ambos casos porque, desde el punto de vista del cliente, el riesgo inicial es similar: abrir un archivo .rdp cuyo origen o integridad no pueden validarse con suficiente confianza.
Lo que muchos están confundiendo: archivo .rdp firmado vs. certificado del servidor RDP
Este punto es clave y conviene dejarlo muy claro entre colegas:
1) Firma del archivo .rdp
Se usa para que Windows pueda identificar al publicador del archivo. Esta firma se aplica con la herramienta rdpsign. Su función principal es ayudar al cliente a distinguir entre archivos de conexión emitidos por una organización confiable y archivos anónimos o no verificados.
2) Certificado del listener RDP del servidor
Es otro asunto totalmente distinto. Aquí lo que se configura es el certificado TLS usado por el listener RDP-Tcp del equipo remoto, normalmente mediante la propiedad SSLCertificateSHA1Hash. Eso influye en la identidad del servidor durante la conexión y en la protección de la sesión, pero no sustituye la firma del archivo .rdp.
Dicho de forma simple: una cosa es confiar en el archivo que se abrió; otra cosa es confiar en el certificado que presenta el servidor durante la sesión RDP. Microsoft documenta ambas capas por separado, y conviene tratarlas como problemas distintos.
¿Sirve un certificado autofirmado?
La respuesta técnica correcta es: sí, pero con matices.
Microsoft define un certificado válido para firma de archivos .rdp como uno emitido por una autoridad reconocida por el cliente. Desde esa perspectiva, un certificado autofirmado no entra automáticamente en la categoría de “válido” solo por existir. Sin embargo, Microsoft también documenta políticas para definir thumbprints de certificados confiables como publicadores de archivos .rdp.
Por eso, en un entorno controlado, sí puede usarse un self-signed para firmar archivos .rdp, pero únicamente si la organización despliega esa confianza en los clientes. Dicho de otro modo: no basta con que el certificado esté en el servidor; los equipos cliente deben confiar explícitamente en él, ya sea por almacén de certificados, por GPO o por políticas equivalentes.
En la práctica, en un dominio Windows, la opción más limpia suele ser emitir el certificado desde una CA interna de Active Directory. Eso simplifica la confianza y evita improvisaciones. El self-signed puede servir para laboratorio, pruebas o entornos muy cerrados, pero no suele ser la mejor estrategia cuando hay múltiples clientes y usuarios finales.
Qué debería hacer un administrador
Ante este cambio, la salida correcta no es desactivar todo ni “pelearse” con el aviso, sino ordenar la cadena de confianza. En la práctica, eso significa:
- Identificar cómo están conectando los usuarios.
Si abren archivos.rdpdistribuidos por correo, por carpetas compartidas o por accesos directos, ese flujo ahora estará más protegido y mostrará advertencias nuevas. - Firmar los archivos
.rdpcorporativos.
Para eso Microsoft mantiene la herramientardpsign. - Usar un certificado que los clientes reconozcan como confiable.
Idealmente, una CA interna o una CA pública según el escenario. - No confundir la firma del archivo con el certificado del servidor.
Son capas distintas y ambas pueden requerir atención. - Revisar las políticas del cliente.
Microsoft documenta configuraciones para permitir archivos.rdpde publicadores válidos, controlar el comportamiento frente a archivos de publicadores desconocidos y definir thumbprints de publicadores confiables.
Un detalle interesante es que Microsoft incluso documentó una vía temporal para revertir el nuevo diálogo mediante registro. Sin embargo, también advierte que esa reversión puede dejar de ser efectiva en futuras actualizaciones. Por eso no debería tomarse como solución estructural, sino apenas como salida transitoria si una operación quedó bloqueada.
Ejemplo de firma y comandos útiles
Para firmar un archivo .rdp, Microsoft documenta la utilidad rdpsign. En versiones modernas de Windows y Windows Server, corresponde usar /sha256.
rdpsign /sha256 THUMBPRINT_DEL_CERTIFICADO "C:\RDP\Servidor122.rdp"Para probar la operación sin reemplazar el archivo:
rdpsign /sha256 THUMBPRINT_DEL_CERTIFICADO /l "C:\RDP\Servidor122.rdp"El thumbprint debe tomarse del certificado instalado en el almacén correspondiente, y al copiarlo hay que eliminar los espacios. Microsoft lo advierte expresamente en la documentación de rdpsign.
Por otra parte, cuando lo que se desea es configurar el certificado del listener del servidor RDP, Microsoft documenta métodos por WMI, PowerShell y registro. Un ejemplo clásico usando WMI es:
wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="THUMBPRINT"Y la ubicación de registro que Microsoft asocia al listener RDP-Tcp es:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcpcon el valor binario:
SSLCertificateSHA1HashOtra vez: esto configura el certificado del servidor, no firma el archivo .rdp.
Políticas que conviene revisar en GPO o MDM
Microsoft documenta varias políticas útiles bajo la ruta:
Windows Components > Remote Desktop Services > Remote Desktop Connection ClientEntre las más relevantes para este escenario están:
- Allow .rdp files from valid publishers and user's default .rdp settings
- Allow .rdp files from unknown publishers
- Specify SHA1 thumbprints of certificates representing trusted .rdp file publishers
Estas políticas permiten construir una postura de seguridad razonable: aceptar archivos firmados por publicadores válidos, controlar qué hacer con archivos no firmados y, cuando sea necesario, declarar expresamente certificados confiables para publicadores corporativos de archivos .rdp.
Una nota importante sobre enero de 2026
Para no mezclar fenómenos distintos, conviene recordar que Microsoft también documentó aparte un problema ocurrido tras la actualización de seguridad de enero de 2026 (KB5074109), donde algunas aplicaciones de conexión remota presentaron fallos en prompts de credenciales. Ese incidente afectó ciertos escenarios con Windows App, Azure Virtual Desktop y Windows 365, y luego recibió correcciones fuera de banda.
Es importante distinguir ese incidente del endurecimiento de abril de 2026 para archivos .rdp. Ambos temas pueden sentirse parecidos para el usuario final (“RDP ya no entra igual”), pero no son el mismo cambio.
Conclusión
Lo ocurrido en 2026 con RDP no debe interpretarse como un simple capricho visual de Microsoft. El cambio responde a un problema real: los archivos .rdp pueden convertirse en un vector de engaño si el usuario no ve con claridad el destino, el publicador y los recursos locales que quedarán expuestos.
La respuesta técnica correcta no es eliminar ciegamente los avisos, sino separar bien las capas:
- firmar los archivos
.rdpcorporativos; - establecer confianza adecuada en los clientes;
- configurar correctamente el certificado del listener del servidor cuando corresponda;
- y distinguir los cambios de seguridad reales de los incidentes puntuales de conectividad o credenciales.
Cuando esos conceptos se entienden bien, desaparece buena parte de la confusión que hoy se resume, de manera imprecisa, en una sola frase: “antes se conectaba directo y ahora pide autorización”.
Enlaces oficiales que conviene tener a mano
Una pequeña caja de herramientas técnica para administradores, soporte y colegas de infraestructura.
- Windows message center – Remote Desktop adds new safeguards for connections opened from RDP files
Anuncio oficial del cambio publicado por Microsoft el 14 de abril de 2026. - Understanding security warnings when opening Remote Desktop (RDP) files
Explica el nuevo diálogo, qué significa “Unknown publisher” y qué conexiones sí cambian y cuáles no. - rdpsign
Referencia oficial del comando para firmar archivos.rdp. - ADMX_TerminalServer Policy CSP
Políticas relacionadas con archivos.rdpfirmados, publicadores desconocidos y certificados confiables. - Configure Remote Desktop server listener certificate
Documento clave para entender el certificado TLS del listener RDP y no confundirlo con la firma del archivo.rdp. - Resolved issues in Windows 11, version 24H2
Útil para revisar el incidente separado de enero de 2026 relacionado con fallos de prompt de credenciales en ciertas aplicaciones remotas.
Nota final para colegas: en un entorno corporativo pequeño o mediano, la recomendación más ordenada suele ser emitir un certificado desde la CA interna, firmar con él los archivos .rdp que se distribuyen a usuarios y, en paralelo, revisar si el certificado del listener del servidor también merece ser alineado con la política de confianza de la organización.