IIS 7 wciąż obsługuje stary certyfikat SSL

Zainstalowałem nowy certyfikat SSL w IIS7, usunąłem stary certyfikat i skonfigurowałem powiązania dla nowego certyfikatu - więc https jest teraz związany tylko z nowym certyfikatem.

Zrestartowałem IIS7 (i sam Windows 2008 Server) i sprawdziłem certyfikat za pomocą poleceń:

netsh http show sslcert

To pokazało tylko nowy certyfikat, tak jak się spodziewałem

certutil -store MY

Pokazało to również tylko nowy certyfikat, a nie stary, jak się spodziewałem

Otworzyłem też mmc i sprawdziłem tam certyfikaty i widzę tylko nowy, a nie stary.

Używam również konta z uprawnieniami administratora.

Jednak - kiedy otwieram przeglądarkę (z dowolnego komputera) i przechodzę do strony https, nadal używa on starego certyfikatu. Nawet gdy usunę stary certyfikat z przeglądarki, nadal zostanie wysłany stary, a nie nowy.

Czy ktoś może mi pomóc dowiedzieć się, gdzie popełniam błąd? Jak mogę egzorcyzmować stary certyfikat fantomowy?

Najpierw kilka punktów, które prawdopodobnie są dla ciebie takie same

• Próbowałem zaktualizować certyfikat, ponieważ wygasł.
• Mam wiele domen powiązanych z tym samym adresem IP. Zdarza się, że są certyfikatem SAN, ale prawdopodobnie nie ma to znaczenia.
• Próbowałem użyć scentralizowanego magazynu certyfikatów. Ponownie uważam, że nie ma to znaczenia dla większości mojej odpowiedzi.
• Próbowałem już zaktualizować certyfikat, ale nie wyświetlał nowej daty.
• Prawdopodobnie wpadasz w panikę, jeśli stary certyfikat wygasł. Weź głęboki oddech...

Najpierw zdecydowanie polecam https://www.digicert.com/help/pobranie i pobranie narzędzia DigiCert. Możesz także użyć go online.

Wejdź na swoją stronę internetową, https://example.coma wyświetli się data ważności i odcisk palca (to, co MS nazywa skrótem certyfikatu). Sprawdza w czasie rzeczywistym, więc nie musisz się martwić, czy Twoja przeglądarka (lub serwer pośredni) coś buforuje.

Jeśli korzystasz ze scentralizowanego magazynu certyfikatów, musisz mieć 100% pewność, że plik .pfx jest najnowszą wersją, więc przejdź do katalogu sklepu i uruchom następującą komendę:

C:\WEBSITES\SSL> certutil -dump www.example.com.pfx

Spowoduje to wyświetlenie daty ważności oraz skrótu / odcisku palca. Oczywiście, jeśli ta data wygaśnięcia jest nieprawidłowa, prawdopodobnie właśnie wyeksportowałeś niewłaściwy certyfikat do systemu plików, więc idź i napraw to najpierw.

Jeśli korzystasz z CCS, przyjęcie tej komendy certutil podaje oczekiwaną datę wygaśnięcia (zaktualizowanego certyfikatu), którą możesz kontynuować.

Uruchom polecenie:

netsh http show sslcert > c:\temp\certlog.txt
notepad c:\temp\certlog.txt

Prawdopodobnie masz tutaj wiele rzeczy, więc łatwiej jest otworzyć je w edytorze tekstu.

Będziesz chciał przeszukać ten plik w poszukiwaniu ZŁEGO skrótu, który otrzymałeś digicert.com(lub odcisk palca otrzymany z Chrom).

Dla mnie to przyniosło następujące efekty. Zobaczysz, że jest powiązany z adresem IP, a nie z moją oczekiwaną nazwą domeny. To jest problem. Wydaje się, że to (z jakiegokolwiek powodu nie jestem pewien) ma pierwszeństwo przed zestawem wiążącym w IIS, dla którego właśnie zaktualizowałem 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

Nie wiem nawet, skąd to wiązanie - nie mam nawet żadnych powiązań SSL w mojej domyślnej witrynie, ale ten serwer ma kilka lat i myślę, że coś się zepsuło.

Więc będziesz chciał go usunąć.

Aby być bezpiecznym, najpierw uruchom następujące polecenie, aby upewnić się, że usuwasz tylko ten jeden element:

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

Teraz potwierdziliśmy, że jest to „zły” odcisk palca i oczekiwany pojedynczy rekord możemy go usunąć za pomocą tego polecenia:

C:\Windows\system32>netsh http delete sslcert ipport=10.0.0.1:443

SSL Certificate successfully deleted

Mam nadzieję, że jeśli teraz wrócisz do Digicert i ponownie uruchom polecenie, otrzymasz oczekiwany odcisk palca certyfikatu. Powinieneś sprawdzić wszystkie nazwy SAN, jeśli masz jakieś, aby się upewnić.

Prawdopodobnie zechcesz tutaj IISRESET, aby upewnić się, że później nie będzie niespodzianek.

Uwaga końcowa: jeśli korzystasz ze scentralizowanego magazynu certyfikatów i widzisz nieprawidłowe zachowanie, próbujące nawet ustalić, czy pobiera ono stamtąd certyfikat, czy też nie martw się - to nie twoja wina. Czasami wydaje się, że natychmiast pobiera nowe pliki, ale buforuje stare. Otwarcie i ponowne zapisanie powiązania SSL po dokonaniu jakiejkolwiek zmiany wydaje się go resetować, ale nie w 100% przypadków.

Powodzenia :-)

Sprawdź certyfikat powiązany z witryną w IIS. Możesz kliknąć stronę prawym przyciskiem myszy i wybrać edycję powiązań. Tam powinieneś zobaczyć powiązanie dla portu 443, które jest powiązane z certyfikatem SSL. To może wciąż wskazywać na stary.

Właśnie to wypracowałem. Serwer faktycznie siedział za serwerem ISA, więc musieliśmy również zainstalować nowy certyfikat SSL na serwerze ISA.

Miałem ten sam problem i sprawdziłem również powiązania. Miałem 2 aplikacje zainstalowane w IIS, jedna używała nowego certyfikatu, jedna używała starego.

Aby to naprawić, musiałem całkowicie usunąć certyfikat z serwera (następnie ewentualnie zrestartuj komputer).

W Menedżerze usług IIS -> (katalog główny drzewa IIS) -> ikona Certyfikaty serwera wybierz stary certyfikat i kliknij opcję Usuń w okienku Akcje.

Doświadczyłem tego podczas aktualizacji IPv6. Miałem IIS zapewniające przekierowanie na wypadek, gdyby ktoś próbował uzyskać dostęp do usługi przez HTTP, która tak naprawdę nie była usługą opartą na serwerze WWW. Zaktualizowałem rzeczywistą usługę (serwer głosowy) do wersji IPv6, jednak nie udało mi się zaktualizować powiązań przekierowania w celu uwzględnienia adresów IPv6.

Spowodowało to, że rezolucje nie przełączyły się na globalnie powiązane przechwytywanie wszystkich witryn, które miały nieaktualny certyfikat. Od momentu złapania wszystkich 404 okazało się, że strona nie działała, podczas gdy w rzeczywistości trafiała na niewłaściwą stronę.

W przypadku, gdy ktoś nadal natknie się na ten problem. Mój został rozwiązany, przechodząc do

C:\inetpub\wwwroot

Następnie znajdziesz plik web.config, otwórz go za pomocą notatnika i usuń wiersz za pomocą

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

Zapisz i spróbuj ponownie, aby uzyskać dostęp do localhost lub strony głównej serwera IIS.