Felsöka SSL-relaterade problem (servercertifikat)
Gäller för: Internet Information Services
Översikt
Den här artikeln hjälper dig att felsöka SSL-problem (Secure Sockets Layer) som endast gäller IIS (Internet Information Services). Den omfattar servercertifikat som används för serverautentisering, inte klientcertifikat.
Om avsnittet Klientcertifikat är inställt på Kräv och du stöter på problem är den här artikeln inte den du bör referera till. Den här artikeln är avsedd att endast felsöka problemet med SSL Server-certifikat.
Det är viktigt att veta att varje certifikat består av en offentlig nyckel (används för kryptering) och en privat nyckel (används för dekryptering). Den privata nyckeln är endast känd för servern.
Standardporten för HTTPS är 443. Det förutsätts att du är väl insatt i SSL Handshake och serverautentiseringsprocessen under SSL-handskakningen.
Verktyg som används i den här felsökaren
De verktyg som används för att felsöka de olika scenarierna är:
- Network Monitor 3.4
- Wireshark
Scenarier
Du ser följande felmeddelande när du surfar på en webbplats via HTTPS:
Det första kravet som måste kontrolleras är om webbplatsen är tillgänglig via HTTP. Om det inte är det finns det förmodligen ett separat problem som inte beskrivs i den här artikeln. Innan du använder den här felsökaren måste du ha webbplatsen i drift på HTTP.
Anta nu att webbplatsen är tillgänglig via HTTP och att det tidigare felmeddelandet visas när du försöker bläddra över HTTPS. Felmeddelandet visas eftersom SSL-handskakningen misslyckades. Det kan finnas många orsaker som beskrivs i de närmaste scenarierna.
Scenario 1
Kontrollera om servercertifikatet har den privata nyckel som motsvarar det. Se följande skärmbild av dialogrutan Certifikat:
Åtgärd
Om den privata nyckeln saknas måste du hämta ett certifikat som innehåller den privata nyckeln, som i huvudsak är en . PFX-fil . Här är ett kommando som du kan försöka köra för att associera den privata nyckeln med certifikatet:
C:\>certutil - repairstore my "906c9825e56a13f1017ea40eca770df4c24cb735"
Om associationen lyckas visas följande fönster:
I det här exemplet 906c9825e56a13f1017ea40eca770df4c24cb735
är tumavtrycket för certifikatet. Följ dessa steg för att hämta tumavtrycket:
- Öppna certifikatet.
- Välj fliken Information.
- Bläddra nedåt för att hitta tumavtrycksavsnittet.
- Välj tumavtrycksavsnittet och markera texten under det.
- Gör en Ctrl+A och sedan Ctrl+C för att markera och kopiera den.
Kommentar
Kommandot certutil
kanske inte alltid lyckas. Om detta misslyckas måste du hämta ett certifikat som innehåller den privata nyckeln från certifikatutfärdare (CA).
Scenario 2
I det här scenariot bör du tänka på att du har ett servercertifikat som innehåller den privata nyckeln installerad på webbplatsen. Men du fortsätter att se felet som visas i scenario 1. Du kan fortfarande inte komma åt webbplatsen via HTTPS.
Åtgärd
Om du har ett certifikat som innehåller den privata nyckeln men inte kan komma åt webbplatsen kan du också se följande SChannel-varning i systemhändelseloggarna:
Event Type: Error
Event Source: Schannel
Event Category: None
Event ID: 36870
Date: 2/11/2012
Time: 12:44:55 AM
User: N/A
Computer:
Description: A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x80090016.
Den här händelsen eller felet indikerar att det uppstod ett problem med att hämta certifikatets privata nyckel. Lös varningen genom att följa dessa steg:
Kontrollera behörigheterna för mappen MachineKeys . Alla privata nycklar lagras i mappen MachineKeys , så se till att du har de behörigheter som krävs.
Om behörigheterna är på plats och problemet fortfarande inte är åtgärdat kan det uppstå ett problem med certifikatet. Det kan ha skadats. Du kan se en felkod för
0x8009001a
i följande SChannel-händelselogg:Event Type: Error Event Source: Schannel Event Category: None Event ID: 36870 Date: 2/11/2012 Time: 12:44:55 AM User: N/A Computer: A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x8009001a.
Kontrollera om webbplatsen fungerar med ett testcertifikat.
Ta en säkerhetskopia av det befintliga certifikatet och ersätt det sedan med ett självsignerat certifikat.
Prova att komma åt webbplatsen med HTTPS.
Om det fungerar skadades certifikatet som användes tidigare och måste ersättas med ett nytt arbetscertifikat. Ibland är problemet kanske inte med certifikatet utan hos utfärdaren. Under verifieringen av certifikatkedjan kan du se felet
CERT_E_UNTRUSTEDROOT (0x800b0109)
om rotcertifikatutfärdarcertifikatet inte är en betrodd rot.Åtgärda det här felet genom att lägga till certifikatutfärdarcertifikatet i det betrodda rotcertifikatutfärdararkivet under Mitt datorkonto på servern. Under verifieringen av certifikatkedjan kan du också få felet
-2146762480(0x800b0110)
.Lös felet genom att följa dessa steg för att kontrollera certifikatets användningstyp:
- Öppna certifikatet.
- Välj fliken Information.
- Välj Redigera egenskaper.
- Under fliken Allmänt kontrollerar du att alternativet Aktivera alla syften för det här certifikatet är markerat och viktigast av allt bör serverautentiseringen finnas i listan.
Scenario 3
De två första scenarierna hjälper till att kontrollera certifikatets integritet. När du har bekräftat att det inte finns några problem med certifikatet löses ett stort problem. Men vad händer om webbplatsen fortfarande inte är tillgänglig via HTTPS? Kontrollera HTTPS-bindningarna på webbplatsen och ta reda på vilken port och IP-adress den lyssnar på.
Åtgärd
Kör följande kommando för att se till att ingen annan process lyssnar på SSL-porten som används av webbplatsen.
netstat -ano" or "netstat -anob"
Om det finns en annan process som lyssnar på porten kontrollerar du varför den processen använder den porten.
Prova att ändra kombinationen AV IP-port för att kontrollera om webbplatsen är tillgänglig.
Scenario 4
Nu kan du vara säker på att du har ett korrekt fungerande certifikat installerat på webbplatsen och att det inte finns någon annan process med hjälp av SSL-porten för den här webbplatsen. Du kan dock fortfarande se felet "Sidan kan inte visas" när du öppnar webbplatsen via HTTPS. När en klient ansluter och initierar en SSL-förhandling söker HTTP.sys igenom SSL-konfigurationen efter det "IP:Port"-par som klienten är ansluten till. Den HTTP.sys SSL-konfigurationen måste innehålla en certifikathash och namnet på certifikatarkivet innan SSL-förhandlingen lyckas. Problemet kan bero på HTTP.SYS SSL Listener
.
Certifikatshash som registrerats med HTTP.sys kan vara NULL eller innehålla ogiltigt GUID.
Åtgärd
Kör följande kommando:
netsh http show ssl
Här är exempel på arbets- och icke-arbetsscenarier:
Arbetsscenario
Konfiguration Inställning IP:port 0.0.0.0:443 Certifikatets hash c09b416d6b 8d615db22 64079d15638e96823d Program-ID:t {4dc3e181-e14b-4a21-b022-59fc669b0914} Namn på certifikatarkiv Min Verifiera återkallning av klientcertifikat Aktiverat Återkallningstid för färskhet 0 Tidsgräns för URL-hämtning 0 ...... ...... Scenario som inte fungerar
Konfiguration Inställning IP:port 0.0.0.0:443 Certifikatets hash Program-ID:t {00000000-0000-0000-0000-000000000000} CertStoreName Min Verifiera återkallning av klientcertifikat 0 Återkallningstid för färskhet 0 Tidsgräns för URL-hämtning 0 ...... ...... Hash-värdet som visas i arbetsscenariot är tumavtrycket för ditt SSL-certifikat. Observera att GUID:et är helt noll i ett scenario som inte fungerar. Du kan se att hashen antingen har ett visst värde eller är tom. Även om du tar bort certifikatet från webbplatsen och sedan kör
netsh http show ssl
, kommer webbplatsen fortfarande att lista GUID som alla 0s. Om du ser GUID:t som {0000...............000}, uppstår ett problem.Ta bort den här posten genom att köra följande kommando:
netsh http delete sslcert ipport=<IP Address>:<Port>
Till exempel:
netsh http delete sslcert ipport=0.0.0.0:443
Om du vill ta reda på om några IP-adresser visas öppnar du en kommandotolk och kör sedan följande kommando:
netsh http show iplisten
Om kommandot returnerar en lista med IP-adresser tar du bort varje IP-adress i listan med hjälp av följande kommando:
netsh http delete iplisten ipaddress=<IP Address>
Kommentar
Starta om IIS efter detta med hjälp av
net stop http /y
kommandot .
Scenario 5
Trots allt detta kan du, om du fortfarande inte kan bläddra på webbplatsen på HTTPS, samla in en nätverksspårning antingen från klienten eller servern. Filtrera spårningen med "SSL eller TLS" för att titta på SSL-trafik.
Här är en ögonblicksbild av nätverksspårning av ett scenario som inte fungerar:
Här är en ögonblicksbild av nätverksspårning av ett arbetsscenario:
Det här är metoden för hur du tittar på en nätverksspårning. Du måste expandera bildruteinformationen och se vilket protokoll och chiffer som har valts av servern. Välj "Server Hello" i beskrivningen för att visa informationen.
I det icke-fungerande scenariot konfigurerades klienten att endast använda TLS 1.1 och TLS 1.2. IIS-webbservern har dock konfigurerats för stöd tillS TLS 1.0, så handskakningen misslyckades.
Kontrollera registernycklarna för att avgöra vilka protokoll som är aktiverade eller inaktiverade. Här är sökvägen:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
AktiveradDWORD ska vara inställd på 1. Om det är inställt på 0 inaktiveras protokollet.
SSL 2.0 är till exempel inaktiverat som standard.