IIS 7 offre ancora un vecchio certificato SSL


27

Ho installato un nuovo certificato SSL in IIS7, rimosso il vecchio certificato e impostato i bind per il nuovo certificato, quindi https ora è associato solo al nuovo certificato.

Ho riavviato IIS7 (e lo stesso Windows 2008 Server) e controllato il certificato usando i comandi:

netsh http show sslcert

Questo ha mostrato solo il nuovo certificato, come mi aspettavo

certutil -store MY

Ciò ha anche mostrato solo il nuovo certificato e non quello vecchio, come mi aspettavo

Ho anche aperto mmc e verificato i certificati lì e vedo solo quello nuovo e non quello vecchio.

Sto anche utilizzando un account con privilegi di amministratore.

Tuttavia, quando apro un browser (da qualsiasi computer) e vado sul sito https, utilizza ancora il vecchio certificato. Anche quando rimuovo il vecchio certificato dal browser, viene comunque inviato quello vecchio e non quello nuovo.

Qualcuno può aiutarmi a capire dove sto sbagliando? Come posso esorcizzare il vecchio certificato fantasma?

Risposte:


28

Innanzitutto un paio di punti che probabilmente sono uguali per te

  • Stavo cercando di aggiornare un certificato perché è scaduto.
  • Ho più domini associati allo stesso IP. Capita di essere un certificato SAN ma è probabilmente irrilevante.
  • Stavo cercando di utilizzare l'archivio certificati centralizzato. Ancora una volta penso che questo sia irrilevante per la maggior parte della mia risposta.
  • Avevo già tentato di aggiornare il certificato ma non mostrava la nuova data.
  • Probabilmente sei nel panico adesso se il tuo vecchio certificato è già scaduto. Fai un respiro profondo...

Per prima cosa consiglierei vivamente di andare https://www.digicert.com/help/e scaricare il loro strumento DigiCert. Puoi anche usarlo online.

Entra nel tuo sito web https://example.come ti mostrerà la data di scadenza e l'identificazione personale (ciò che MS chiama l'hash del certificato). Esegue una ricerca in tempo reale, quindi non devi preoccuparti se il tuo browser (o server intermedio) sta memorizzando nella cache qualcosa.

Se stai utilizzando l'archivio certificati centralizzato, devi essere sicuro al 100% che il file .pfx sia l'ultima versione, quindi vai alla directory del tuo negozio ed esegui questo comando:

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

Questo ti mostrerà la data di scadenza e l'hash / l'identificazione personale. Ovviamente se questa data di scadenza è errata, è possibile che tu abbia esportato il certificato errato nel filesystem, quindi vai prima a risolverlo.

Se si utilizza CCS, supponendo che questo comando certutil fornisca la data di scadenza prevista (del certificato aggiornato), è possibile procedere.

Esegui il comando:

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

Probabilmente hai un sacco di cose qui, quindi è più facile aprirlo in un editor di testo.

Ti consigliamo di cercare in questo file l'hash ERRATO che hai ottenuto digicert.com(o l'impronta digitale che hai ottenuto da Chrome).

Per me questo ha prodotto quanto segue. Vedrai che è associato a un IP e non al mio nome di dominio previsto. Questo è il problema. Sembra che questo (per qualsiasi motivo non sia sicuro) abbia la precedenza sull'associazione impostata in IIS per cui ho appena aggiornato 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

Non so nemmeno da dove provenga questo legame - non ho nemmeno alcun legame SSL sul mio sito predefinito, ma questo server ha qualche anno e penso che qualcosa sia appena stato corrotto e bloccato.

Quindi ti consigliamo di eliminarlo.

Per essere al sicuro, ti consigliamo di eseguire prima il comando seguente per assicurarti di eliminare solo questo elemento:

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

Ora abbiamo verificato che questa è la "cattiva" identificazione personale e ci aspettiamo che sia possibile eliminarla con questo comando:

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

SSL Certificate successfully deleted

Spero che se ora torni a Digicert e riesegui il comando, ti darà l'identificazione personale del certificato prevista. Dovresti controllare tutti i nomi SAN se ne hai uno solo per essere sicuro.

Probabilmente voglio IISRESET qui per essere sicuro senza sorprese più tardi.

Nota finale: se stai utilizzando l'archivio certificati centralizzato e stai riscontrando un comportamento irregolare nel tentativo di determinare anche se sta ritirando il certificato da lì o non preoccuparti, non è colpa tua. A volte sembra raccogliere immediatamente nuovi file, ma memorizzarli nella cache. L'apertura e il salvataggio del binding SSL dopo aver apportato qualsiasi tipo di modifica sembra reimpostarlo, ma non il 100% delle volte.

In bocca al lupo :-)


3
Sei un Simon tra i Simons. Nel nostro caso, si è scoperto che il nostro server aveva "memorizzato nella cache" il certificato scaduto, [::1]:443mentre l'aggiornamento del certificato in IIS ha aggiornato solo il record per 0.0.0.0:443. Grazie!
tuespetre,

1
Ciò ha risolto il mio problema con più domini sullo stesso IP; non utilizzando un archivio certificati centralizzato.
Chris F Carroll,

1
Ho dovuto usarlo alcune volte. Il software di gestione dell'hosting web PLESK rovina occasionalmente le associazioni dei certificati e alla fine ho bisogno dei comandi netsh sopra per rimuovere l'associazione offensiva. Non sono sicuro di quali versioni siano tutte interessate, ma sto utilizzando la versione corrente di PLESK Onyx su Windows Server 2016.
BenSwayne,

Nel mio caso era per nome host e porta. Quindi, per filtrare ed eliminare in base al nome host, i comandi sarebbero: "netsh http show sslcert hostnameport = www.example.com: 443" e "netsh http delete sslcert hostnameport = www.example.com: 443"
Karthik Jayapal

14

Controllare il certificato associato al sito in IIS. È possibile fare clic con il pulsante destro del mouse sul sito e scegliere Modifica collegamenti. Lì dovresti vedere un'associazione per la porta 443 associata a un certificato SSL. Questo potrebbe ancora indicare quello vecchio.


Ho controllato e il certificato nei collegamenti per la porta 443 è il nuovo certificato, non quello vecchio. Grazie per il tuo suggerimento
joechip

1
Strano, non ho mai avuto questo successo. Anche se non rimuovo mai i vecchi certificati. Come sei sicuro di ottenere ancora il vecchio certificato? Sta mostrando che è scaduto?
Tatas,

Sì, nel browser è possibile controllare i dettagli del certificato (data di scadenza, ecc.) Ed è quello vecchio che IIS7 sta servendo.
joechip

1
Ho visto questo con - Chrome. Chrome memorizza nella cache il vecchio certificato e lo mostra all'utente.
TomTom,

3

L'ho appena capito. Il server si trovava effettivamente dietro un server ISA, quindi dovevamo anche installare il nuovo certificato SSL sul server ISA.


3

Ho avuto lo stesso problema e ho controllato anche gli attacchi. Avevo installato 2 app in IIS, una utilizzava il nuovo certificato, una utilizzava il vecchio.

Per risolvere, ho dovuto rimuovere completamente il certificato dal server (quindi eventualmente un riavvio).

Da Gestione IIS -> (radice dell'albero IIS) -> icona Certificati server, selezionare il vecchio certificato e fare clic su Rimuovi nel riquadro Azioni.


1
Allo stesso modo avevamo effettivamente un sito STOPPED aggiuntivo che faceva riferimento al vecchio certificato e una volta aggiornato quel sito per utilizzare quello nuovo, il sito live effettivo ha iniziato a mostrare il nuovo certificato!
Azione Dan

1

L'ho sperimentato durante un aggiornamento IPv6. Ho avuto IIS fornendo un reindirizzamento nel caso in cui qualcuno avesse tentato di accedere a un servizio via HTTP che non era in realtà un servizio basato su web server. Ho aggiornato il servizio effettivo (un server vocale) con IPv6, tuttavia non sono riuscito ad aggiornare i binding per il reindirizzamento per includere gli indirizzi IPv6.

Ciò ha comportato il failover delle risoluzioni su un sito vincolato a livello globale che catturava tutti i siti che avevano il certificato obsoleto. Dato che le catture erano semplicemente dei 404, sembrava che il sito non funzionasse, quando in realtà stava colpendo il sito sbagliato.


0

Nel caso in cui qualcuno dovesse ancora imbattersi in questo problema. Il mio è stato risolto andando a

C:\inetpub\wwwroot

Quindi troverai un file web.config, aprilo usando il blocco note e rimuovi la linea con

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

Salvare e riprovare ad accedere all'host locale o al sito principale del server IIS.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.