Недавно мой сайт SSL IIS 7.5 начал отказываться от соединений после перезагрузки. Как ни странно, проблему можно решить, привязав сайт к другому сертификату и вернувшись к правильному.
В случае сбоя wirehark показывает, что клиент отправляет различные пакеты приветствия SSL (TLS 1.0, 1.1, 1.2), а сервер отвечает TCP RST. При работе клиент hello практически идентичен (одинаковые шифры / сжатие / SNI). Такое же поведение отображается для IE и Chrome (содержимое немного отличается, но мгновенный RST является обычным явлением). Это указывает на то, что, скорее всего, это что-то на стороне сервера.
Моя единственная подсказка - случайное событие SChannel с идентификатором 36870 «Произошла фатальная ошибка при попытке доступа к закрытому ключу учетных данных сервера SSL. Код ошибки, повторно полученный из криптографического модуля, - 0x8009030d. Состояние внутренней ошибки - 1001.» Проверка моих библиотек 0x8009030d - это «SEC_E_UNKNOWN_CREDENTIALS», а 1001, скорее всего, MSG_FILE_NOT_FOUND.
На основании этого я проверил разрешения для папки Crypto / RSA для kb278381 и нашел их, как и ожидалось. Я принудительно использовал наследование для базовых папок, но никаких изменений в поведении не произошло.
Будем признательны за любые подсказки о том, где искать дальше!
Я бы предположил, что это что-то сбрасывает разрешения для указанной вами папки, скорее всего, это политика безопасности через групповую политику. (С подозрением относитесь ко всему, что сбрасывает права доступа к папке).
Кроме того, просто мысль - расположение закрытых ключей изменилось с тех пор, как CryptoAPI стал Crypto Next Generation, поэтому вы также можете проверить папки ProgramData на предмет изменений разрешений.
Вы можете получить разрешения закрытого ключа сертификата непосредственно через MMC сертификата, поэтому, если вы управляете разрешениями закрытого ключа, а) вы наверняка увидите правильные разрешения ключа * и б) вы можете получить подсказку о том, что вызвало проблему. .
* фактический пробег может быть больше в зеркале