IIS 7, Все еще Вручающий старый сертификат SSL
Проверьте сертификат, привязанный к сайту в IIS. Вы можете щелкнуть правой кнопкой мыши на сайте и выбрать редактировать привязки. Там вы должны увидеть привязку для порта 443, которая связана с сертификатом SSL. Это все еще может указывать на старую.
Я только что придумал. Сервер фактически находился за ISA-сервером, поэтому нам также пришлось установить новый SSL-сертификат на ISA-сервер.
У меня была такая же проблема, и я тоже проверил привязки. У меня было 2 приложения, установленных в IIS, одно использовало новый сертификат, другое - старый.
Чтобы исправить это, мне пришлось полностью удалить сертификат с сервера (затем, возможно, перезагрузить).
Из диспетчера IIS - > (Корень дерева IIS) -> значок Сертификаты сервера, выберите старый сертификат и нажмите Удалить на панели Действия.
Сначала пара моментов, которые, вероятно, одинаковы для вас
- Я пытался обновить сертификат, поскольку срок его действия истек.
- У меня несколько доменов, привязанных к одному IP. Это сертификат SAN, но это, вероятно, не имеет значения.
- Я пытался использовать централизованное хранилище сертификатов. Опять же, я думаю, что это не имеет отношения к большей части моего ответа.
- Я уже пытался обновить сертификат, но он не показывал новую дату.
- Вы, вероятно, сейчас в панике, если ваш старый сертификат уже истекший. Сделайте глубокий вдох ...
Сначала я настоятельно рекомендую зайти на https://www.digicert.com/help/ и загрузить их инструмент DigiCert. Вы также можете использовать его в Интернете.
Введите на своем веб-сайте https://example.com , и он покажет вам дату истечения срока действия и отпечаток (то, что MS называет хешем сертификата). Он выполняет поиск в реальном времени, поэтому вам не нужно беспокоиться о том, кэширует ли что-то ваш браузер (или промежуточный сервер).
Если вы используете централизованное хранилище сертификатов, вы должны быть на 100% уверены, что. pfx является последней версией, поэтому перейдите в каталог вашего магазина и выполните эту команду:
C:\WEBSITES\SSL> certutil -dump www.example.com.pfx
Это покажет вам дату истечения срока и хэш / отпечаток. Очевидно, что если эта дата истечения срока действия неправильная, вы, вероятно, просто экспортировали неправильный сертификат в файловую систему, поэтому сначала исправьте это.
Если вы используете CCS, то предполагая, что эта команда certutil дает вам ожидаемую дату истечения срока (вашего обновленного сертификата) вы можете продолжить.
Выполните команду:
netsh http show sslcert > c:\temp\certlog.txt
notepad c:\temp\certlog.txt
Скорее всего, у вас здесь много чего, поэтому его будет проще открыть в текстовом редакторе.
Вы захотите найти в этом файле НЕПРАВИЛЬНЫЙ хэш что вы получили от digicert.com (или отпечатка большого пальца, полученного от Chrome).
Для меня это дало следующее. Вы увидите, что он привязан к IP, а не к моему ожидаемому доменному имени. Это проблема. Кажется, что это (по какой-то причине я не уверен) имеет приоритет над привязкой, установленной в IIS, которую я только что обновил для example.com .
IP:port : 10.0.0.1:443
Certificate Hash : d4a17e3b57e48c1166f18394a819edf770459ac8
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
Я даже не знаю, откуда эта привязка from - У меня даже нет привязок SSL на моем сайте по умолчанию, но этому серверу несколько лет, и я думаю, что что-то просто повреждено и зависло.
Так что вы захотите его удалить.
Быть в целях безопасности вы можете сначала запустить следующую команду, чтобы убедиться, что вы удаляете только этот один элемент:
C:\Windows\system32>netsh http show sslcert ipport=10.0.0.1:443
SSL Certificate bindings:
-------------------------
IP:port : 10.0.0.1:443
Certificate Hash : d4a17e3b57e48c1166f18394a819edf770459ac8
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
Теперь мы проверили, что это «плохой» отпечаток пальца, и ожидаемую единственную запись мы можем удалить с помощью этой команды:
C:\Windows\system32>netsh http delete sslcert ipport=10.0.0.1:443
SSL Certificate successfully deleted
Надеюсь, если вы теперь вернетесь в Digicert и повторно запустите команду, она даст вам ожидаемый отпечаток сертификата. Вы должны проверить все имена SAN, если они у вас есть, чтобы быть уверенным.
Возможно, вы захотите IISRESET здесь, чтобы быть уверенным в отсутствии сюрпризов позже.
Заключительное примечание: если вы используете централизованное хранилище сертификатов и видите неустойчивое поведение, пытающееся даже определить, забирает ли он ваш сертификат оттуда или нет, не волнуйтесь - это не ваша вина. Вроде бы иногда сразу новые файлы подхватывает, а старые кеширует. Открытие и повторное сохранение привязки SSL после внесения каких-либо изменений, похоже, сбрасывает ее, но не в 100% случаев.
Удачи: -)
Я испытал это во время обновления IPv6. У меня был IIS, обеспечивающий перенаправление на случай, если кто-то попытался получить доступ к службе через HTTP, которая на самом деле не была службой на основе веб-сервера. Я обновил фактическую службу (голосовой сервер) до IPv6, однако мне не удалось обновить привязки для перенаправления, чтобы включить адреса IPv6.
Это привело к тому, что разрешения перешли к глобально привязанному сайту catch all, на котором был устаревший сертификат. Так как все ловушки были просто 404, оказалось, что сайт не работает, хотя на самом деле он попал не в тот сайт.
На случай, если кто-то до сих пор натыкаюсь на этот вопрос. Моя была решена путем перехода к
C:\inetpub\wwwroot
. Затем вы найдете файл web.config, откройте его с помощью блокнота и удалите строку с
<httpRedirect enabled="true" destination="http://foo.company.org" />
Save и попробуйте снова получить доступ к локальному или корневому сайту вашего сервера IIS.
Ответ Саймона направил меня на верный путь.
В моем случае я пытался «обновить» существующий сертификат на долго работающей Windows 2012 R2 с IIS 8.5.
Прежде всего следует отметить, что, по-видимому, рекомендуется импортировать сертификаты PFX с помощью MMC (указатель на HOWTO в Digicert), а не просто использовать значок «Сертификаты сервера» в утилита управления IIS. Почему: потому что после того, как я возился со старыми привязками из командной строки (netsh http delete sslcert), а также после удаления и повторного импорта сертификата VIA IIS Manager "Server Certificates", я продолжал получать забавную ошибку: Указанный сеанс входа в систему не существует. Возможно, он уже был прекращен. (Исключение из HRESULT: 0x80070520) (еще одна ссылка на Digicert) при попытке повторно привязать новый сертификат. И это продолжалось, несмотря на то, что я пытался снова и «разрешил экспорт», как предлагалось в статье Digicert KB. Мне нужно было импортировать новый сертификат через MMC, и тогда привязки снова начали работать.
Также: все это дело преподало мне несколько уроков о логике привязки сертификатов в сочетании с «логикой разрешения виртуального хоста». Команда netsh http show sslcert показывает вам во всей красе, какие привязки вы настроили с помощью этого единственного сертификата. Это может быть не то, что было разработано Управлением IIS - это может быть ваше собственное творение, созданное два года назад :-) В вашем IIS может быть что-то вроде:
+ Your IIS instance
+ Your default virtual host (responding to 0.0.0.0:443)
+ also responding to a particular IP address (say 1.2.3.4:443)
+ also responding to a name-based alias (www.yourname.com:443 - SNI)
+ and another name-based alias (www.someothername.net:443 - SNI)
В этом случае веб-сервер (понятно и правильно) следует несколько простых «правил разрешения».Если вы соответствуете определенному «имени» и у вас включена индикация имени сервера (SNI) в его привязке HTTPS, вы получите сертификат, привязанный к этому конкретному имени. Если у вас нет привязки к этому имени на основе SNI, вы получите сертификат на основе IP-адреса назначения, который вы использовали для связи с сервером (даже если вы использовали конкретное DNS-имя в командной строке или адресе браузера. row) - этот базовый IP-адрес в сочетании с привязкой, настроенной в вашем IIS. В-третьих, если даже IP-адрес не имеет привязки в вашем IIS, применяется привязка «по умолчанию».
Таким образом, привязки на стороне сервера аккуратно перечислены вместе в выводе netsh http show sslcert - но вы должны определить иерархию разрешений самостоятельно. Первоначально я думал, что IIS что-то кэширует, и что это проклятие командной строки показало мне «кэшированные записи». И я, вероятно, ошибался - я просто не знал о нескольких установленных вручную привязках, и я продолжал использовать какое-то другое правило, отличное от того, которое, как я думал, я только что перенастроил :-) Только представьте, сколько раз я перезапускал IIS.
Еще одно замечание: я продолжал использовать утилиту командной строки «openssl» в Linux, чтобы запросить сервер для проверки сертификата. Я продолжал использовать:
openssl s_client -connect www.mywebsite.com:443 -showcerts | openssl x509 -text -noout
Изначально я не знал, что www.mywebsite.com в этой команде просто преобразуется в IP-адрес и не запрашивается через SNI! Даже когда в отчаянии я удалил привязку сертификата на основе имени в IIS.Таким образом, я получал некоторую IP-привязку или глобальную привязку к части IIS = я получил то, что заслужил ;-) После того, как я немного потянул за волосы, меня осенило, что мне нужен какой-то аргумент для openssl, который сделает его запросить конкретный виртуальный хост на основе имени HTTPS через SNI. Аргумент для этого называется -servername:
openssl s_client -connect www.mywebsite.com:443 -servername www.mywebsite.com -showcerts | openssl x509 -text -noout
Это означает, что вы можете (ab) использовать это для таких вещей, как
openssl s_client -connect 192.168.30.41:443 -servername www.my-test-website.com -showcerts | openssl x509 -text -noout
или
openssl s_client -connect www.mymachine.net:443 -servername www.not-yet-in-dns.com -showcerts | openssl x509 -text -noout
Спасибо, что подняли эту тему. Надеюсь, мои каракули кому-то помогут ...