#ssl
#ssl
Вопрос:
Я поддерживаю приложение, которое использует Owin для размещения HTTP-интерфейса на локальном хосте. Это работает уже много лет, но начиная с Windows 11 связанный сертификат отображается как ERR_SSL_KEY_USAGE_INCOMPATIBLE. Это верно как для Chrome, так и для Edge. Сертификат не изменился и отлично работает в Windows 10 (протестирован до 20H2).
Если я создам новый сертификат, используя Windows 11, проблема исчезнет. Сравнивая старый сертификат с новым сертификатом, я не могу определить причину, по которой он не будет работать.
Использование ключа нерабочего сертификата: неотрицание, шифрование ключа, шифрование данных, соглашение о ключе (78) Улучшено: проверка подлинности сервера (1.3.6.1.5.5.7.3.1)
Использование ключа рабочего сертификата: цифровая подпись, шифрование ключа (a0) Улучшено: проверка подлинности клиента (1.3.6.1.5.5.7.3.2) Проверка подлинности сервера (1.3.6.1.5.5.7.3.1)
Кто-нибудь знает, что может быть не так со старым сертификатом, из-за которого Windows 11 и только Windows 11 отклоняют его?
РЕДАКТИРОВАТЬ:
Спасибо @Steffen Ullrich! То, что вы сказали, определенно было тем толчком, который мне был нужен. Но вы бы сказали, что это мой ответ?
В Windows 10 со старым сертификатом я использовал Chrome, чтобы выяснить: соединение с этим сайтом зашифровано и аутентифицировано с использованием TLS 1.2, ECDHE_RSA с P-384 и AES_256_GCM.
В Windows 11 с новым сертификатом я вижу: соединение с этим сайтом зашифровано и аутентифицировано с использованием TLS 1.3, X25519 и AES_256_GCM.
Я уже отключил TLS 1.3 через настройки браузера, но, очевидно, это не сработало. Я использовал реестр для отключения TLS 1.3, и теперь исходный сертификат работает! (Подключение с помощью TLS 1.2 так же, как Win 10).
Покопавшись, я обнаружил следующее: https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-11
Это показывает, что указанный выше набор шифров НЕ поддерживается TLS 1.3. Я всегда подозревал, что это проблема с TLS 1.3, я просто не мог на нее указать.
Итак, я буду продвигаться вперед со своими новыми сертификатами, поскольку они «лучше», но, по крайней мере, я знаю почему.
Ответ №1:
Я предполагаю, что метод обмена ключами изменился. Шифрование ключа подходит для обмена ключами RSA, который уже давно устарел, но мог использоваться в вашем коде. Вместо этого для обмена ключами DH требуется цифровая подпись (как в современном ECDHE). Посмотрите, какие способы использования ключей требуются для каждого метода обмена ключами?.
Старый сертификат подходил только для устаревшего обмена ключами RSA, новый сертификат подходит как для ECDHE, так и для обмена ключами RSA. Мне меньше интересно, почему старый сертификат не работает, мне больше интересно, почему он не сломался раньше, поскольку обмен ключами RSA уже давно устарел.
Комментарии:
1. Это, по крайней мере, серьезное преимущество. Что я могу посмотреть здесь? Там нет никакого реального «кода», кроме того, что MS делает в Owin для размещения сайта. По сути, это просто сертификат SSL, поэтому доступ к локальной службе можно получить из браузера, обслуживаемого по протоколу SSL. Может быть, раздел реестра?
2. @ChadM: я ничего не знаю о Owin и о том, как его можно настроить. Поэтому я не знаю, почему он ранее убедился, что используется обмен ключами RSA.
3. Отвечая на мой собственный вопрос, но TLDR; Win 11 вызывал TLS 1.3, хотя я отключил его в браузере. Новый сертификат поддерживает TLS 1.3, старый — нет, я полагаю, из-за того, что вы говорите. Используя реестр для полного отключения TLS 1.3, старый сертификат работает так, как ожидалось.
4. @ChadM: «Новый сертификат поддерживает TLS 1.3, старый нет» — в TLS 1.3 удалена поддержка обмена ключами RSA. Вот почему старый сертификат больше не работает. Мне все еще интересно, почему это сработало с Win10, возможно, потому, что вы там тоже отключили TLS 1.3.
5. Я не могу сказать, что я в шоке. Это также может сводиться к тому, как . NET обрабатывает вещи. Раньше мы сталкивались с проблемами, когда по умолчанию нам требовался протокол TLS 1.2. Если приложение не было скомпилировано с определенным . Сетевые версии, тогда TLS 1.2 не будет вариантом, даже если во время выполнения у вас был более новый .NET. Параметры реестра переопределяют поведение. Я должен предположить, что здесь происходит что-то подобное. В Windows 10 был добавлен TLS 1.3, где, поскольку Windows 11 начинается с TLS 1.3. Мне пришлось добавить разделы реестра SCHANNEL для TLS 1.3, чтобы отключить его в Win 11. Для Win 10 может потребоваться их явное присутствие?
Ответ №2:
Я решил эту проблему, создав новый самосертификат и перестроив тот же домен с новым самосертификатом.
Я надеюсь, что это будет полезно для вас.