Dela via


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:

Skärmbild av en webbläsarsida som visar meddelandet, anslutningen för den här webbplatsen är inte säker.

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:

Två skärmbilder av dialogrutan Certifikat. Man har ingen privat nyckel. Den andra visar ett meddelande om att den privata nyckeln motsvarar certifikatet.

Å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"

Skärmbild av kommandokonsolen som visar certutil-syntaxen.

Om associationen lyckas visas följande fönster:

Skärmbild av kommandokonsolen som visar ett meddelande om att kommandot har slutförts.

I det här exemplet 906c9825e56a13f1017ea40eca770df4c24cb735 är tumavtrycket för certifikatet. Följ dessa steg för att hämta tumavtrycket:

  1. Öppna certifikatet.
  2. Välj fliken Information.
  3. Bläddra nedåt för att hitta tumavtrycksavsnittet.
  4. Välj tumavtrycksavsnittet och markera texten under det.
  5. Gör en Ctrl+A och sedan Ctrl+C för att markera och kopiera den.

Skärmbild av dialogrutan Certifikat som visar fliken Information. Tumavtrycksvärdet är markerat.

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:

  1. 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.

  2. 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. 
    
  3. Kontrollera om webbplatsen fungerar med ett testcertifikat.

  4. Ta en säkerhetskopia av det befintliga certifikatet och ersätt det sedan med ett självsignerat certifikat.

  5. 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.

  6. Å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).

  7. Lös felet genom att följa dessa steg för att kontrollera certifikatets användningstyp:

    1. Öppna certifikatet.
    2. Välj fliken Information.
    3. Välj Redigera egenskaper.
    4. 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.

    Skärmbild som visar en del av dialogrutan Certifikategenskaper där aktivera alla syften för det här certifikatet har valts.

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

  1. 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"
    
  2. Om det finns en annan process som lyssnar på porten kontrollerar du varför den processen använder den porten.

  3. 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

  1. 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.

  2. 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
    
  3. 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:

Skärmbild av fönstret Visningsfilter som visar spårningsögonblicksbilden.

Här är en ögonblicksbild av nätverksspårning av ett arbetsscenario:

Skärmbild av fönstret Visningsfilter som visar en ögonblicksbild av en lyckad spårning.

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.

Mer information