Удаленный мониторинг сертификата RDP

Вопрос или проблема

CONNECTED(00000003)
140439032170136:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 305 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1539710511
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 305 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1539710511
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

openssl s_client -connect SERVER01:3389 -debug -prexit

openssl s_client -connect SERVER01:3389 -tls1_2 -prexit
openssl s_client -connect SERVER01:3389 -tls1_1 -prexit

openssl s_client -connect SERVER01:3389 -cipher 'HIGH:!aNULL:!eNULL' -prexit

Ответ или решение

Управление сертификатами и безопасностью в IT-инфраструктуре — задача немаловажная. Когда дело касается удалённого мониторинга сертификатов для Remote Desktop Protocol (RDP), это становится еще более критично, так как ошибки могут серьёзно повлиять на доступность и безопасность систем. Рассмотрим проблему отсутствия сертификата на одном из серверов — SERVER01 — и постараемся дать исчерпывающее руководство для её решения.

Теория

Основная проблема заключается в невозможности завершения TLS-рукопожатия при попытке подключения к порту 3389 через OpenSSL. Ошибка ssl23_write:ssl handshake failure свидетельствует о неудачной попытке установления защищенного соединения. Это может быть вызвано целым рядом факторов, от обновления конфигурации на самом сервере до проблем с сетевой инфраструктурой.

Примеры (Почему это может произойти)

1. Изменения на RDP сервере: Поскольку проблема возникла внезапно, с большой вероятностью что-то изменилось на сервере SERVER01. Это могут быть изменения в политике безопасности, вызванные обновлениями Windows или ручной настройкой конфигураций.

2. Неисправный или отсутствующий сертификат: Если сервер не предоставляет сертификат, это может быть вызвано тем, что сертификат истек, был поврежден или неправильно установлен.

3. Шифровальные пакеты (cipher suites): Если сервер и клиент не могут договориться об использовании конкретного пакета шифрования, то соединение не будет установлено. Это может произойти из-за несовместимости обновлений безопасности, устранения устаревших или уязвимых алгоритмов.

4. Сетевые или межсетевые изменения: Изменения в настройках фаервола или сети, такие как инспекция TLS-трафика или изменения в правилах доступа по портам, могут предотвратить успешное подключение.

Применение (Как исправить проблему)

1. Диагностика с помощью OpenSSL:

   • Начните с получения дополнительной информации о рукопожатии, используя команду:

     openssl s_client -connect SERVER01:3389 -debug -prexit

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

   • Протестируйте разные версии TLS, чтобы определить, поддерживаются ли они сервером:

     openssl s_client -connect SERVER01:3389 -tls1_2 -prexit
     openssl s_client -connect SERVER01:3389 -tls1_1 -prexit

   • Поставьте акцент на определенных наборах шифрования:

     openssl s_client -connect SERVER01:3389 -cipher 'HIGH:!aNULL:!eNULL' -prexit

2. Проверка конфигурации сервера:

   • Проверьте Журнал событий Windows на сервере SERVER01 на наличие ошибок, связанных с RDP или сертификатами.
   • Убедитесь, что сертификат RDP правильно установлен в соответствующем хранилище сертификатов.
   • Сравните настройки безопасности RDP с другим рабочим сервером, чтобы выявить возможные расхождения.
   • Включите логирование протоколов RDP на стороне сервера, чтобы отслеживать сбои рукопожатия.

3. Проверка и корректировка сетевых настроек:

   • Убедитесь в отсутствии препятствий на уровне сети или фаервола, которые могут блокировать или изменять трафик.
   • Проверьте, не происходит ли инспекция TLS-трафика на устройствах безопасности, таких как прокси-серверы. Если она включена, попытайтесь отключить её для проверки.

4. Управление сертификатами:

   • Убедитесь в актуальности сертификата. Проверьте на предмет повреждения или истечения срока действия. Если нужно, перепроизведите установку или перевыпустите сертификат.
   • Проверьте цепочку сертификатов. Убедитесь, что все промежуточные сертификаты установлены и действительны.

5. Обновление и проверка настройки безопасности:

   • Проверьте изменения в групповых политиках и, если нужно, откатите их или настройте снова.
   • Убедитесь в том, что все необходимые обновления безопасности были применены корректно, без нарушения конфигурации.

Следуя этим шагам, вы можете диагностировать и устранить проблему отсутствия сертификата на сервере SERVER01. Постоянный мониторинг состояния сертификатов и настроек безопасности поможет предотвратить подобные инциденты в будущем, сохраняя вашу инфраструктуру под надежной защитой.