Спочатку пару балів, які, ймовірно, для вас однакові
- Я намагався оновити сертифікат, оскільки термін його дії закінчився.
- У мене кілька доменів, прив’язаних до одного 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
Ви, мабуть, тут багато матеріалів, тому простіше відкрити їх у текстовому редакторі.
Ви хочете шукати в цьому файлі хеш WRONG, який ви отримали 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% часу.
Удачі :-)
[::1]:443
тоді як оновлення cert в IIS лише оновило запис для0.0.0.0:443
. Дякую!