ЭКСПЛУАТАЦИОННОЕ РУКОВОДСТВО · RDP TLS

Как установить доверенный сертификат RDP без потери доступа

TLS-сертификат подтверждает подлинность RDP-сервера и защищает транспортный канал. Для безопасной установки должны совпадать имя подключения, SAN сертификата, закрытый ключ, цепочка доверия и привязка RDP listener.

Даже действующий сертификат может нарушить подключение клиентов.

Клиент отклонит сертификат при подключении по IP или псевдониму, отсутствующему в SAN, при недоверенном центре сертификации, недоступном закрытом ключе или изменении политики, требующем перезапуска служб удалённых рабочих столов.

Для чего нужен TLS-сертификат RDP

TLS защищает RDP-трафик при передаче и связывает открытый ключ сервера с DNS-именем, к которому подключается пользователь. Корректно проверяемый сертификат снижает риск перехвата и подмены сервера и устраняет неоднозначные предупреждения сертификата на управляемых клиентах.

Сертификат не подтверждает личность пользователя и не заменяет MFA. Его задача — подтвердить сервер и создать шифрованный канал до передачи учётных данных и содержимого сеанса.

Стандарты и рекомендации по безопасности

Можно ли восстановить доступ через консоль Lira?

Да, если сохранился хотя бы один независимый канал управления.

Что защищает сертификат

TLS шифрует транспорт RDP и позволяет клиенту проверить, к какому серверу он подключился. Сертификат не заменяет надёжные пароли Windows, MFA, брандмауэр и своевременное обновление системы.

Проверка выполняется относительно имени, использованного клиентом. Сертификат для rdp.example.com не подтверждает другой псевдоним или прямое подключение по IP, если этот идентификатор не указан и не поддерживается.

1. Определите постоянное имя RDP-точки

  1. Выберите одно стабильное DNS-имя для каждой публичной или внутренней точки RDP.
  2. Направьте DNS и правила проброса портов на нужный сервер.
  3. Обновите сохранённые RDP-профили, чтобы они использовали это имя.
  4. Не используйте меняющийся публичный IP как основную идентичность сервера для пользователей.

2. Выберите модель доверия

  • Публичный центр сертификации, например Let’s Encrypt, подходит для публично делегированного домена с доступной проверкой ACME.
  • Внутренний центр сертификации подходит для частных имён и управляемых устройств, если корневой сертификат распространяется через Group Policy, MDM или другой контролируемый канал.
  • Самоподписанный сертификат допустим только для ограниченного тестирования, поскольку доверие требуется настраивать отдельно на каждом клиенте.

Lira автоматизирует выпуск и продление ACME, однако постоянная DNS-делегация challenge должна быть настроена корректно.

3. Проверьте сертификат до привязки

  • Subject Alternative Name содержит все поддерживаемые имена подключения.
  • Enhanced Key Usage разрешает Server Authentication.
  • Сертификат находится в периоде действия, а цепочка строится без ошибок.
  • Закрытый ключ установлен на целевом сервере и не является экспортируемым без явного требования политики.
  • Текущая привязка listener сохранена для отката.

4. Выполняйте установку в окно обслуживания

  1. Сохраните действующий административный сеанс и доступ к консоли восстановления.
  2. Установите сертификат на один пилотный сервер.
  3. Разрешите Lira применить отпечаток listener и необходимую политику безопасности RDP.
  4. Если требуется перезапуск службы удалённых рабочих столов, дождитесь возврата агента на связь.
  5. Подключитесь с отдельного клиента по рабочему DNS-имени и проверьте предъявленный сертификат.
  6. Расширяйте установку только после успешной проверки пилота.

Автоматический выпуск и продление

Для автоматизации Let’s Encrypt Lira использует ACME DNS challenge, контролирует срок действия, заранее запрашивает продление, устанавливает обновлённый сертификат и проверяет итоговую привязку RDP.

Делегация DNS challenge должна оставаться постоянной. Удаление CNAME после первого выпуска нарушает автоматическое продление и приводит к повторным предупреждениям.

  • Контролируйте срок и состояние продления в портале.
  • Не удаляйте делегацию ACME challenge после выпуска.
  • Проверьте продление на некритичной точке до массового применения.
  • Поддерживайте актуальными получателей уведомлений и ответственных за эскалацию.

Восстановление и откат

  1. Используйте консольный доступ или уже открытый сеанс, если новые RDP-подключения перестали работать.
  2. Восстановите ранее сохранённый отпечаток сертификата listener.
  3. Проверьте права закрытого ключа и перезапускайте службы RDP только в согласованное окно восстановления.
  4. Повторно подключитесь по точному DNS-имени и проверьте цепочку сертификата.
  5. Исправьте SAN, DNS, доверие или права ключа до новой попытки установки.

Частые вопросы

Почему RDP продолжает показывать предупреждение?

Основные причины: несовпадение имени, недоверенный издатель, неполная цепочка, истёкший срок либо подключение по IP при наличии в сертификате только DNS-имени.

Требует ли Let’s Encrypt входящего порта на каждом RDP-сервере?

При проверке DNS-01 входящий порт не требуется. Агент устанавливает только исходящие HTTPS-соединения, а владение доменом подтверждается через делегированную DNS-запись.

Отключит ли установка текущих пользователей?

Импорт сертификата обычно не отключает сеансы, но применение listener или политики безопасности может потребовать перезапуска службы RDP. Выполняйте изменение как обслуживание и предупредите активных пользователей.

Сначала проверьте одну точку, затем весь парк

Откройте Lira, проверьте имя точки и цепочку доверия, сохраните текущую привязку и выполните первую установку на пилотном сервере.

Открыть консоль Lira