GUÍA OPERATIVA · CERTIFICADOS RDP

Instale certificados RDP de confianza sin interrumpir el acceso

El certificado TLS autentica el extremo RDP y protege el transporte. El nombre de conexión, SAN, clave privada, cadena de confianza y enlace del listener RDP deben coincidir.

Un certificado vigente también puede interrumpir conexiones.

Un SAN incorrecto, una cadena no confiable, una clave privada inaccesible o un enlace equivocado del listener puede bloquear conexiones nuevas. Conserve el thumbprint anterior y acceso por consola.

Por qué se necesita un certificado TLS para RDP

TLS protege el tráfico en tránsito y vincula la clave pública del servidor con el nombre DNS utilizado por el cliente. Una validación correcta reduce el riesgo de interceptación y suplantación y elimina advertencias ambiguas.

El certificado no autentica al usuario ni sustituye MFA. Autentica el servidor y crea un canal cifrado antes del intercambio de credenciales y datos de sesión.

Normas y recomendaciones de seguridad

¿Se puede restaurar el acceso desde la consola Lira?

Sí, mientras quede disponible al menos un canal de administración independiente.

Qué protege el certificado

TLS cifra el transporte RDP y permite comprobar la identidad del servidor. No sustituye credenciales fuertes, MFA, firewall ni actualizaciones.

La validación utiliza el nombre escrito por el cliente; un certificado para un nombre no valida automáticamente un alias o una dirección IP.

1. Defina el nombre del extremo

  1. Asigne un nombre DNS estable a cada extremo.
  2. Dirija DNS y la publicación de red al servidor correcto.
  3. Actualice los perfiles RDP para usar ese nombre.
  4. No utilice una IP cambiante como identidad del servicio.

2. Seleccione el modelo de confianza

  • Una CA pública como Let’s Encrypt es adecuada para nombres delegados públicamente y validación ACME.
  • Una CA interna es adecuada para nombres privados y equipos gestionados cuando la raíz se distribuye de forma controlada.
  • Un certificado autofirmado debe limitarse a pruebas.

Lira automatiza emisión y renovación ACME, pero la delegación DNS permanente del desafío debe mantenerse.

3. Valide antes de enlazar

  • Compruebe SAN, EKU Server Authentication, vigencia y cadena completa.
  • Confirme que la clave privada existe en el servidor de destino.
  • Registre el enlace actual del listener para poder revertir.

4. Instale durante mantenimiento

  1. Mantenga una sesión administrativa y la consola disponibles.
  2. Instale primero en un servidor piloto.
  3. Aplique el thumbprint y la política RDP mediante Lira.
  4. Espere a que el agente vuelva a estar en línea si se reinicia el servicio.
  5. Conéctese desde otro cliente usando el nombre DNS y examine el certificado.

Emisión, renovación y recuperación

Lira realiza el flujo ACME DNS, vigila la caducidad, renueva, instala y verifica el enlace resultante. La delegación CNAME del desafío debe permanecer configurada.

Si las conexiones nuevas fallan, entre por consola, restaure el thumbprint anterior y compruebe permisos de la clave, DNS, SAN y cadena antes de repetir.

Preguntas frecuentes

¿Por qué RDP sigue mostrando una advertencia?

Las causas habituales son nombre distinto, emisor no confiable, cadena incompleta, caducidad o conexión por IP cuando el certificado solo contiene DNS.

¿DNS-01 requiere abrir un puerto entrante?

No. El agente usa HTTPS saliente y el control del dominio se confirma mediante el desafío DNS delegado.

¿Se desconectarán los usuarios actuales?

La importación no suele hacerlo, pero aplicar el listener o la política puede reiniciar servicios RDP. Trátelo como mantenimiento programado.

Valide un extremo antes de todo el parque

Compruebe el nombre, la cadena y la configuración anterior; después instale el certificado en un servidor piloto.

Abrir la consola Lira