Службе Sstp не удалось прочитать хэш сертификата sha256 из реестра

Обновлено: 21.11.2024

Демультиплексирование сеанса

Выбор сертификации

  • Сценарий 1

Сценарий 1

В сценарии 1 VPN-клиент пытается установить соединение с сервером маршрутизации и удаленного доступа на основе STTP, используя адрес IPv4 или и IPv6. Однако соединение не устанавливается. Это связано с тем, что веб-сервер IIS может привязать сертификат только к прослушивателю 0.0.0.0:443. При настройке SSTP после настройки веб-сервера IIS SSTP не может настроить прослушиватель [::]:443. Кроме того, SSTP не может настроить хэш Sha256 в реестре. В этом случае в журнале системных событий VPN-клиента регистрируется следующее сообщение об ошибке:

Служба протокола безопасного туннелирования сокетов либо не смогла прочитать хэш сертификата SHA256 из реестра, либо данные недействительны. Чтобы быть действительным, хэш сертификата SHA256 должен иметь тип REG_BINARY и иметь длину 32 байта. Возможно, SSTP не сможет получить значение из реестра из-за другого системного сбоя. Подробное сообщение об ошибке приведено ниже. Соединения SSTP не будут приниматься на этом сервере. Устраните проблему и повторите попытку.

Системе не удается найти указанный файл.

  1. Выдайте тот же сертификат, который используется веб-сервером IIS, для прослушивателя [::]:443.
  2. Настройте хэш Sha256 в реестре.
  3. Перезапустите службы SSTP и маршрутизации и удаленного доступа.

Сценарий 2

  • Сертификат, выдаваемый для конкретной комбинации IP-адреса и порта веб-сервером IIS, аналогичен сертификату, выдаваемому для 0.0.0.0:443 и [::]:443 маршрутизацией на основе SSTP и Сервер удаленного доступа. В этом случае все VPN-подключения на основе SSTP к этому VPN-серверу выполняются успешно.
  • Сертификат, выданный веб-сервером IIS для определенной комбинации IP-адреса и порта, отличается от сертификата, выданного для 0.0.0.0:443 и [::]:443 службой маршрутизации и удаленного доступа на основе SSTP. Сервер доступа. В этом случае VPN-подключение не будет успешным, если подключение будет выполнено с использованием этого IPv4-адреса. VPN-подключение не установлено, так как предполагается, что процесс установления VPN-подключения на основе SSTP использует хэш-значение, зарегистрированное в реестре для сертификата, выданного прослушивателю 0.0.0.0:443 для установления VPN-подключения. Но сертификат, который используется на этапе SSL, — это тот же сертификат, который выдается для конкретной комбинации IP-адреса и порта веб-сервером IIS. Таким образом, существует несоответствие хэш-значений сертификатов, используемых для процесса VPN-подключения на основе SSTP, и VPN-подключение не может быть установлено. Чтобы обойти эту проблему, можно заменить хэш-значение сертификата сервера маршрутизации и удаленного доступа на основе SSTP хэш-значением сертификата веб-сервера IIS. Дополнительные сведения см. в разделе "Как изменить хэш-значение сертификата".

Сценарий 3

В сценарии 3 сертификат, используемый сервером маршрутизации и удаленного доступа на основе SSTP и веб-сервером IIS, одинаков. В этом сценарии VPN-клиент может успешно установить соединение с сервером маршрутизации и удаленного доступа на основе SSTP. Например, если сервер маршрутизации и удаленного доступа на основе SSTP использует сертификат с именем Cert 1 , а веб-сервер IIS также использует тот же сертификат с именем Cert 1 , VPN-подключения выполняются успешно.

Сценарий 4

В сценарии 4 сертификат, используемый сервером маршрутизации и удаленного доступа на основе SSTP, отличается от сертификата, используемого веб-сервером IIS. Если VPN-клиент пытается подключиться с IP-адреса, указанного в сертификате веб-сервера IIS, клиент получает сертификат, выданный веб-сервером IIS. Это происходит во время фазы квитирования SSL в процессе соединения SSTP. Затем клиент пытается выполнить проверку крипто-привязки для этого сертификата на этапе аутентификации PPP. Но сервер маршрутизации и удаленного доступа на основе SSTP ожидает, что проверка привязки шифрования будет выполняться для сертификата, который использует сервер маршрутизации и удаленного доступа на основе SSTP. В этом случае VPN-клиент не может установить VPN-подключение к серверу маршрутизации и удаленного доступа на основе SSTP.

Затем клиент вычисляет крипто-привязку на основе сертификата 1 на этапе аутентификации PPP. Но сервер маршрутизации и удаленного доступа на основе SSTP ожидает крипто-привязку, основанную на Cert 2. В этот момент VPN-клиент не может установить VPN-подключение к серверу маршрутизации и удаленного доступа на основе SSTP из-за различий в используемых сертификатах.

Кроме того, в журнале системных событий VPN-клиента регистрируется сообщение об ошибке, похожее на следующее:

VPN-соединение на основе SSTP с сервером удаленного доступа было разорвано из-за сбоя проверки безопасности. Параметры безопасности на сервере удаленного доступа не соответствуют параметрам на этом компьютере. Свяжитесь с системным администратором сервера удаленного доступа и передайте следующую информацию:

Хэш сертификата SHA1: 0705ae2bac92bcbcbc54a11fc8c527dc0ecaf5ee

Хэш сертификата SHA256: d075f96f979fd4df20f3fdf7a5335807879ca627e5f3fc0bab7a7ac067c831c6

Чтобы обойти проблему, описанную в сценарии 4, можно заменить хэш-значение сертификата сервера маршрутизации и удаленного доступа на основе SSTP на хэш-значение сертификата веб-сервера IIS. Дополнительные сведения см. в разделе "Как изменить хэш-значение сертификата".

Как изменить хеш-значение сертификата

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

  1. Получите хеш-значение Sha256 для сертификата веб-сервера IIS.
  2. Откройте командную строку с повышенными правами на сервере VPN.
  3. В командной строке введите следующую команду и нажмите клавишу ВВОД, чтобы выдать сертификат веб-сервера IIS слушателю [::]:443:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters /v SHA256CertificateHash /t REG_BINARY /d Значение хеш-функции Sha256 для сертификата веб-сервера IIS /f

    Получите хэш-значение Sha256 для сертификата веб-сервера IIS. Вы можете получить хеш-значение из сообщения об ошибке, которое регистрируется в журнале системных событий VPN-клиента. Например, хеш-значение Sha256 может напоминать следующее хеш-значение:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters /v SHA256CertificateHash /t REG_BINARY /d d075f96f979fd4df20f3fdf7a5335807879ca627e5f3fc0bab7a7ac067c831c6 /f

Если клиенты Always On VPN настроены на использование протокола безопасного туннелирования сокетов (SSTP) со службой маршрутизации и удаленного доступа Windows Server (RRAS), администраторы могут столкнуться со сценарием, в котором клиент может успешно установить VPN-подключение с помощью SSTP. но тут же отключается. Журнал системных событий содержит запись с идентификатором события 6 из источника RasSstp, которая включает следующее сообщение об ошибке.

«VPN-соединение на основе SSTP с сервером удаленного доступа было прервано из-за сбоя проверки безопасности. Параметры безопасности на сервере удаленного доступа не соответствуют параметрам на этом компьютере. Свяжитесь с системным администратором сервера удаленного доступа и передайте следующую информацию».

Распространенные причины

Две наиболее распространенные причины этой проблемы: когда SSTP настроен для разгрузки SSL, и когда VPN-клиент находится в сети, где выполняется проверка SSL.

Разгрузка SSTP

Наиболее распространенная причина этой проблемы – разгрузка SSL, настроенная для SSTP на внешнем балансировщике нагрузки или контроллере доставки приложений (ADC). Чтобы предотвратить перехват от атаки «человек посередине», VPN-клиент отправляет хэш сертификата SSL, который использовался при установке VPN-подключения. Если эта информация не соответствует параметрам, настроенным на сервере RRAS, считается, что соединение скомпрометировано, и оно немедленно разрывается.

Проверка SSL

Другой сценарий, в котором может возникнуть эта проблема, — это когда VPN-клиент находится за сетевым устройством, настроенным для выполнения глубокой проверки пакетов SSL (DPI). В этом случае VPN-клиенты SSTP не смогут подключиться к VPN-серверу.

Разрешение

При выгрузке SSL на другое устройство сервер RRAS должен быть настроен так, чтобы знать, какой сертификат SSL предоставляется удаленным клиентам. Эта информация хранится в следующем разделе реестра.

Однако для этой записи реестра требуется двоичное значение, что затрудняет настройку вручную. Чтобы решить эту проблему, рекомендуется, чтобы тот же сертификат SSL, установленный на балансировщике нагрузки/ADC, также был установлен на сервере VPN (даже если SSL будет разгружен). Для этого сначала импортируйте сертификат SSL и закрытый ключ в хранилище сертификатов локального компьютера, затем откройте консоль управления RRAS и выполните следующие действия.

Конфигурация PowerShell

Если сертификат SSL не может быть установлен на VPN-сервере или для удаленной автоматизации этой настройки на нескольких серверах, загрузите и запустите сценарий PowerShell Enable-SstpOffload из моего репозитория GitHub здесь и выполните следующую команду.

Enable-SSTPOffload -CertificateHash [Хэш сертификата SHA256 общедоступного SSL-сертификата] -Restart

Enable-SSTPOffload -CertificateHash "C3AB8FF13720E8AD9047DD39466B3C8974E592C2FA383D4A3960714CAEF0C4F2" -Restart

У нас небольшой бизнес, и у нас есть сервер, на котором работает наша VPN на Windows Server 2012.

Наша VPN работала нормально, пока мы не перезапустили наш маршрутизатор, и похоже, что процедура перезапуска сломала VPN. Мы не уверены, совпадение это или нет. На данном этапе мы не можем подключиться к VPN ни с одного клиента. (На том же сервере есть файловый сервер, к которому мы можем получить доступ). Мы получаем это сообщение:

Ошибка 800: Удаленное подключение не установлено из-за сбоя VPN-туннелей. Сервер VPN может быть недоступен. Если это соединение пытается использовать туннель L2TP/IPsec, параметры безопасности, необходимые для согласования IPsec, могут быть настроены неправильно.

На сервере, к которому мы получили удаленный доступ, мы вошли в Диспетчер серверов > Удаленный доступ, просмотрели журнал и получили несколько ошибок. Одним из которых являются различные варианты:

Не удалось применить IP-безопасность к порту VPN0-104 из-за ошибки: не удалось найти сертификат. Соединения, использующие протокол L2TP через IPSec, требуют установки сертификата компьютера, также известного как сертификат компьютера. Звонки на этот порт приниматься не будут.

Другая ошибка:

Служба протокола безопасного туннелирования сокетов либо не смогла прочитать хэш сертификата SHA256 из реестра, либо данные недействительны. Чтобы быть действительным, хэш сертификата SHA256 должен иметь тип REG_BINARY и иметь длину 32 байта. Возможно, SSTP не сможет получить значение из реестра из-за другого системного сбоя. Подробное сообщение об ошибке приведено ниже. Соединения SSTP не будут приниматься на этом сервере. Устраните проблему и повторите попытку. Системе не удается найти указанный файл.

Мы погуглили сертификат SHA256 и просмотрели реестр в поисках этого файла, но его там нет. Никто не обращался к серверу, возможно ли, что сертификат мог быть удален сам по себе?

Еще одна вещь, которую мы попробовали, это войти в Консоль управления удаленным доступом и щелкнуть Рабочий статус. Мы получаем следующую ошибку:

Произошла неизвестная системная ошибка. Проверьте, запущена ли служба управления удаленным доступом.

Решение этой проблемы:

Включите (Start-Service ramgmtsvc) или перезапустите (Restart-Service ramgmtsvc) службу в командной строке PowerShell с повышенными привилегиями.

В результате появления этой ошибки мы много раз перезапускали службы DNS, DHCP и удаленного подключения, но это не помогло. Мы также перезапустили весь сервер, и это тоже не помогло.

SHA-2 – это набор криптографических хеш-функций, включающий SHA-224, SHA-256 и SHA-512. 256 в SHA-256 представляет размер битов хэш-вывода или дайджеста при выполнении хеш-функции. Не все программное обеспечение поддерживает каждый размер дайджеста в семействе SHA-2. В этой статье особое внимание уделяется SHA-256 и его совместимости с различными программными платформами и операционными системами. Как правило, SHA-256 поддерживается в OS X 10.5+ и Windows XP SP3+.

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

Чтобы узнать о политике GlobalSign в отношении выдачи SHA-256, а также о важных датах, установленных Microsoft, Google и Mozilla, прочитайте статью о внедрении SHA-256.

Индекс:

  1. Поддержка ОС, браузера и сервера
  2. Поддержка брандмауэра
  3. Наборы инструментов, библиотеки, платформы и т. д.
  4. Поддержка базы данных
  5. Подробная поддержка операционных систем
  6. Почтовые клиенты
  7. Подписание документа
  8. Подписание кода Windows
  9. Совместимость SafeNet iKey и eToken
  10. Мейнфрейм
  11. Поддержка Citrix
  12. Услуги


* Android имеет техническую возможность обработки сертификатов SHA-256, начиная с версии 1.0. На практике некоторые пользователи могут столкнуться с проблемами при проверке сертификатов, использующих перекрестные сертификаты (эти сертификаты цепочки помощи чередуются с корневыми). В версии 1.6 эта проблема была решена для некоторых пользователей, и проблема была решена в версии 2.2.

** Chrome поддерживает сертификаты SHA-2, начиная с версии 1.0, однако до версии 37 это зависит от операционной системы. Например, в Windows Server 2003 без MS13-095 или Windows XP SP2 Chrome не будет подключаться к страницам с использованием сертификатов SHA-2. Применение MS13-095 к Server 2003 или SP3 к Windows XP позволит Chrome поддерживать SHA-2 в этих устаревших системах.

Chrome 38+ может независимо проверять сертификаты SHA-2 даже в таких системах, как Server 2003, без применения MS13-095.

*** Apache 2.0 по умолчанию поставляется вместе с mod_ssl. Версии до 2.0 требуют ручной установки mod_ssl для любой поддержки SSL.Mod_gnutls — это альтернатива mod_ssl, использующая GnuTLS вместо библиотек OpenSSL.

**** Oracle Weblogic Server 10.3.3 и более поздние версии имеют JSSE для поддержки SSL/TLS-сертификатов и подключений. В более ранних версиях используются расширения Certicom, которые в настоящее время считаются устаревшими.

10.3.3 — первая версия, официально поддерживающая JSSE. Ее можно включить, войдя в консоль администратора и выбрав «Среда» > «Серверы» > «Имя управляемого сервера» > «Конфигурация» > «SSL» > «Дополнительно» > «Использовать JSSE SSL». Нажмите Сохранить; перезагрузите свой сервер. Версии до 10.3.3 могут включать JSSE вручную, но официально он не поддерживается Oracle.

Поддержка SHA-2 появилась в OpenSSL 0.9.8, но не включена по умолчанию с помощью SSL_library_init(). В версии 0.9.8 хеш-функции SHA-2 должны вызываться специально или с помощью OpenSSL_add_all_algorithms(), что может быть нежелательно. OpenSSL 0.9.8o включает хеш-алгоритмы SHA-2 в конфигурации по умолчанию.

* Модуль pgcrypto для PostgreSQL представил поддержку семейства хеш-алгоритмов SHA-2 в выпуске 8.1, но только для автономного модуля. В версии 8.2 функции SHA-2 модуля pgcrypto включены в ядро ​​PostgreSQL, что позволяет использовать эти хэши для PostgreSQL, даже если установленная версия OpenSSL не поддерживает их.

Примечания относительно "частичной" совместимости:
* S/MIME:

  • Outlook в Windows XP SP3 может использовать сертификаты, подписанные с помощью SHA-256, но не может проверять электронную почту, подписанную с использованием алгоритма хэширования SHA-256.
  • По умолчанию Outlook подписывает с помощью SHA1, даже если используется сертификат SHA2, хотя при желании это поведение можно изменить.


** Подписание кода:

  • Код может быть без проблем подписан сертификатом SHA2 в любой из систем, перечисленных как имеющих частичную или полную совместимость.
  • Произошла несовместимость с драйверами ядра, подписанными SHA2, на частично совместимых платформах. Драйверы ядра, подписанные с помощью сертификатов SHA2, не будут устанавливаться на системы, имеющие "частичную" совместимость.

Алгоритм хеширования подписи в самом сертификате не зависит от хэша подписи, помещенного в сообщение электронной почты. Например, Outlook 2003 на XP SP3 может использовать сертификат, подписанный с помощью SHA-256, для подписи зашифрованных сообщений электронной почты. Но подпись в электронном письме будет ограничена SHA1.

Установите для алгоритма хеширования Outlook значение SHA-1

Outlook 2003: Инструменты > Параметры > Настройки > Безопасность > Настройки > Алгоритм хеширования > SHA1

Outlook 2007, 2010, 2013: Файл > Параметры > Центр управления безопасностью > Параметры центра управления безопасностью > Безопасность электронной почты > Параметры > Алгоритм хеширования > SHA1


Примечание. Adobe Reader 8+ может размещать подписи с цифровым идентификатором, если эта функция была включена в Adobe Acrobat Professional.

Adobe Acrobat и Adobe Reader совместимы с сертификатами SHA-256 начиная с версии 8.0, но по-прежнему используют подписи SHA1 по умолчанию. Начиная с версии 9.1, Acrobat & Reader будет предпочитать SHA-256 для хэша подписи, если он доступен, в противном случае будет использоваться SHA1. Подписи SHA-2 могут быть предпочтительными в версиях до 9.1 путем внесения изменений в реестр.

Цифровые подписи, размещенные в более новых версиях Microsoft Office, могут быть несовместимы с более ранними версиями. Совместимость с предыдущими версиями можно указать вручную.

Office 2003–2010 работают с сертификатами SHA-2, но размещают подписи SHA1. Office 2013 использует SHA2 в качестве хэша подписи по умолчанию, если он доступен. Вы можете указать хэш подписи в Office 2010 и 2013 через реестр.


Office 2010 в Windows 7 требует исправления kb 2598139, чтобы добавить поддержку SHA-256 для сертификатов подписи кода.

В Windows 7 и Windows Server 2008 R2 для проверки драйверов ядра с подписью SHA-2 требуется код КБ 3033929. Это обновление недоступно для XP, Vista, 2003 и 2008.

Для получения более подробной информации о поддержке хэш-алгоритма как для сертификатов, так и для дайджестов файлов в Windows, прочитайте статью Поддержка хеш-алгоритма подписи кода Windows.

Читайте также: