Назад | Перейти на главную страницу

IIS 7 все еще обслуживает старый сертификат SSL

Я установил новый сертификат SSL в IIS7, удалил старый сертификат и настроил привязки для нового сертификата, поэтому https теперь привязан только к новому сертификату.

Я перезапустил IIS7 (и сам Windows 2008 Server) и проверил сертификат с помощью команд:

netsh http show sslcert

Это показало только новый сертификат, как я и ожидал.

certutil -store MY

Это также показало только новый сертификат, а не старый, как я ожидал.

Я также открыл mmc и проверил сертификаты там, и я вижу только новый, а не старый.

Я также использую учетную запись с правами администратора.

Однако когда я открываю браузер (с любого компьютера) и перехожу на сайт https, он все еще использует старый сертификат. Даже когда я удаляю старый сертификат из браузера, он все равно отправляет старый, а не новый.

Может ли кто-нибудь помочь мне разобраться, где я ошибаюсь? Как я могу изгнать старый фантомный сертификат?

Сначала пара моментов, которые, вероятно, одинаковы для вас

  • Я пытался обновить сертификат, потому что срок его действия истек.
  • У меня несколько доменов, привязанных к одному 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

Я даже не знаю, откуда взялась эта привязка - у меня даже нет привязок 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% случаев.

Удачи :-)

Проверьте сертификат, привязанный к сайту в IIS. Вы можете щелкнуть правой кнопкой мыши по сайту и выбрать редактировать привязки. Там вы должны увидеть привязку для порта 443, которая связана с сертификатом SSL. Это все еще может указывать на старую.

Я просто решил это. Сервер фактически находился за сервером ISA, поэтому нам также пришлось установить новый сертификат SSL на сервер ISA.

У меня была такая же проблема, и я тоже проверил привязки. У меня было 2 приложения, установленных в IIS, одно использовало новый сертификат, другое - старый.

Чтобы исправить это, мне пришлось полностью удалить сертификат с сервера (затем, возможно, перезагрузить).

В диспетчере IIS -> (корень дерева IIS) -> значок «Сертификаты сервера» выберите старый сертификат и нажмите «Удалить» на панели «Действия».

Я испытал это во время обновления IPv6. У меня был IIS, обеспечивающий перенаправление на случай, если кто-то пытался получить доступ к службе через HTTP, которая на самом деле не была службой на основе веб-сервера. Я обновил фактическую службу (голосовой сервер) до IPv6, однако мне не удалось обновить привязки для перенаправления, чтобы включить адреса IPv6.

Это привело к тому, что разрешения перешли к глобально привязанному сайту catch all, на котором был устаревший сертификат. Поскольку все уловки были просто 404, оказалось, что сайт не работает, хотя на самом деле он попал не на тот сайт.

Ответ Саймона направил меня на верный путь.

В моем случае я пытался «обновить» существующий сертификат на долго работающей 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

Спасибо, что подняли эту тему. Надеюсь, моя каракули кому-то поможет ...

На случай, если кто-то все еще наткнется на эту проблему. Моя была решена путем перехода к

C:\inetpub\wwwroot

Затем вы найдете файл web.config, откройте его с помощью блокнота и удалите строку с

<httpRedirect enabled="true" destination="http://foo.company.org" />

Сохраните и попробуйте снова получить доступ к локальному или корневому сайту вашего сервера IIS.