ЕКСПЛУАТАЦІЙНИЙ ПОСІБНИК · RDP TLS

Як установити довірений сертифікат RDP без втрати доступу

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

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

Клієнт може відхилити сертифікат через відсутнє в SAN ім’я, недовірений центр, недоступний закритий ключ або перезапуск служб RDP після зміни політики.

Для чого потрібен TLS-сертифікат RDP

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

Сертифікат не підтверджує особу користувача й не замінює MFA. Його завдання — автентифікувати сервер і створити зашифрований канал до передавання облікових даних і вмісту сеансу.

Стандарти та рекомендації з безпеки

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

Так, якщо зберігся хоча б один незалежний канал керування.

Що захищає сертифікат

TLS шифрує RDP-транспорт і дозволяє клієнту перевірити сервер. Він не замінює надійні облікові дані, MFA, брандмауер і оновлення Windows.

Перевірка виконується щодо імені, використаного клієнтом. Сертифікат для rdp.example.com не підтверджує інший псевдонім або IP, якщо їх немає в сертифікаті.

1. Визначте постійне ім’я точки RDP

  1. Оберіть стабільне DNS-ім’я для кожної зовнішньої або внутрішньої точки.
  2. Спрямуйте DNS і правила переспрямування портів на потрібний сервер.
  3. Оновіть збережені RDP-профілі для використання цього імені.
  4. Не використовуйте змінну публічну IP-адресу як основну ідентичність.

2. Оберіть модель довіри

  • Let’s Encrypt підходить для публічно делегованого домену з доступною ACME-перевіркою.
  • Внутрішній CA підходить для приватних імен і керованих пристроїв, якщо кореневий сертифікат розповсюджується через Group Policy або MDM.
  • Самопідписаний сертифікат використовуйте лише для обмеженого тестування.

Lira автоматизує ACME-випуск і поновлення, але DNS-делегування challenge має залишатися постійним.

3. Перевірте до прив’язки

  • SAN містить усі підтримувані імена підключення.
  • Enhanced Key Usage дозволяє Server Authentication.
  • Строк чинності та ланцюжок не мають помилок.
  • Закритий ключ установлено на цільовому сервері.
  • Поточну прив’язку listener збережено для відкату.

4. Розгортайте у вікно обслуговування

  1. Збережіть активний адміністративний сеанс і доступ до консолі.
  2. Установіть сертифікат на один пілотний сервер.
  3. Застосуйте відбиток listener і політику RDP через Lira.
  4. Якщо служба RDP перезапускається, дочекайтеся повернення агента онлайн.
  5. Підключіться з іншого клієнта за робочим DNS-ім’ям і перевірте сертифікат.
  6. Продовжуйте лише після успішного пілота.

Автоматичне поновлення та відкат

Lira контролює строк, виконує ACME DNS challenge, завчасно поновлює сертифікат і перевіряє нову RDP-прив’язку. Не видаляйте делегований CNAME після першого випуску.

Якщо нові підключення не працюють, скористайтеся консоллю, відновіть попередній відбиток, перевірте права ключа, DNS, SAN і ланцюжок довіри.

Поширені запитання

Чому RDP показує попередження?

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

Чи потрібен вхідний порт для Let’s Encrypt?

Для DNS-01 — ні. Агент використовує вихідний HTTPS, а володіння доменом підтверджується делегованим DNS challenge.

Чи від’єднаються поточні користувачі?

Імпорт зазвичай не від’єднує сеанси, але зміна listener або політики може перезапустити служби RDP. Плануйте це як обслуговування.

Спочатку перевірте одну точку

Перевірте ім’я, довіру та резервну прив’язку, після чого встановіть сертифікат на пілотному сервері.

Відкрити консоль Lira