TLS 1.2 IIS hosted ssl отправляет ответ 403.7 в Firefox, но 200 в Postman на одном сервере

TLS 1.2 IIS hosted ssl отправляет ответ 403.7 в Firefox, но 200 в Postman на одном сервере

У меня возникла проблема с IIS на Windows Server 2019 и TLS 1.2.

Я заменил КОРНЕВОЙ УЦ, и теперь установлены новые доверенные корневые сертификаты.

Теперь IISу меня есть несколько сайтов, для которых require sslустановлено значение true.

Теперь есть два сценария использования Firefox:

GET на любом сайте, требующем TLS иот клиента(Fire Fox)отправить сертификат, выданный OLD ROOT CAи все еще действителен и http200/ok.

НО

Еслиот клиента(Firefox / Chrome и т. д. то же самое) отправляю сертификат, выданный НОВЫМ КОРНЕВЫМ ЦС (также действительный) я получаю 403.7 от сервера. (не вижу этого в браузере, он просто снова запрашивает сертификат) изображение

Я не знаю, почему здесь отображается 12 с. Ответ мгновенный и НА КЛИЕНТЕ я не вижу 403.7, я вижу сброс соединения?

изображение

Как попробовать отладить больше?

и еще самая странная вещь:

Если я делаю то же самое с тем же сертификатом, выпущенным новым корневым центром сертификации, но от почтальона я получаю 200/ok, как узнать почему?

и вторая самая странная вещь:

Если я размещаю тот же сайт require sslна другом сервере Windows Server 2019, то с обоими сертификатами все в порядке.

ТАК ЧТО ЭТО ПРОБЛЕМА ОДНОГО СЕРВЕРА С НОВЫМИ СЕРТИФИКАТОРАМИ/ЭМИТЕНТОМ.

----редактировать------

Еще одна странность:

Если я сделаю то же самое, но с сервера, через IP-адрес сервера или localhost, и отправлю ТОТ ЖЕ САМЫЙ новый сертификат, то все будет в порядке.

Итак, эта проблема возникает ТОЛЬКО когда мы заходим с браузера УДАЛЕННОГО ПК, поэтому я думаю о каких-то проблемах с Netsh?

Не знаю, что еще проверить.

а также

Ни на одной из машин, ни на клиенте, ни на сервере не установлено ни одного нового корневого центра сертификации, и в mmc>certs виден доверенный корневой центр сертификации в промежуточном состоянии, также все в порядке и т. д.

На IIS настроен только ssl-сертификат для https-привязки, который соответствует URL-адресу конечной точки, выданный новым/старым корневым CA, разницы нет - соединение сбрасывается из браузера и ok из postman. А также, если я импортирую этот новый сертификат КЛИЕНТА НА сервер, чтобы проверить цепочку, цепочка сертификатов ok и доверена.

IMHO, если все работает с локального хоста с тем же клиентским сертификатом, то настройки IIS на 100% в порядке, так что это должно быть что-то еще? Может быть, что-то с netsh? Также проверил, и все так же, как на второй машине, которая работает нормально.

Пожалуйста, посоветуйте, что еще проверить или в чем может быть проблема?

решение1

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

Для тестирования я бы выпустил новый сертификат из нового корневого центра сертификации и импортировал его в привязку ssl задействованных сайтов. Также не забудьте очистить кэш браузера и перезапустить iis после изменения сертификатов

Другим более сложным вариантом будет экспорт текущего сертификата и открытие его в виде текстового файла, декодирование его и проверка наличия в нем нового корневого центра сертификации.

Связанный контент