Arbeta med certifikat
För att programmera WCF-säkerhet (Windows Communication Foundation) används X.509-digitala certifikat ofta för att autentisera klienter och servrar, kryptera och digitalt signera meddelanden. Det här avsnittet beskriver kort funktionerna för digitala X.509-certifikat och hur du använder dem i WCF, och innehåller länkar till ämnen som förklarar dessa begrepp ytterligare eller som visar hur du utför vanliga uppgifter med hjälp av WCF och certifikat.
I korthet är ett digitalt certifikat en del av en offentlig nyckelinfrastruktur (PKI), som är ett system med digitala certifikat, certifikatutfärdare och andra registreringsmyndigheter som verifierar och autentiserar giltigheten för varje part som deltar i en elektronisk transaktion med hjälp av kryptering med offentlig nyckel. En certifikatutfärdare utfärdar certifikat och varje certifikat har en uppsättning fält som innehåller data, till exempel ämne (den entitet som certifikatet utfärdas till), giltighetsdatum (när certifikatet är giltigt), utfärdare (entiteten som utfärdade certifikatet) och en offentlig nyckel. I WCF bearbetas var och en av dessa egenskaper som en Claim, och varje anspråk delas ytterligare in i två typer: identitet och rättighet. Mer information om X.509-certifikat finns i Certifikat för offentliga X.509-nycklar. Mer information om anspråk och auktorisering i WCF finns i Hantera anspråk och auktorisering med identitetsmodellen. Mer information om hur du implementerar en PKI finns i Enterprise PKI med Windows Server 2012 R2 Active Directory Certificate Services.
Den primära funktionen för ett certifikat är att autentisera identiteten för certifikatets ägare till andra. Ett certifikat innehåller ägarens offentliga nyckel , medan ägaren behåller den privata nyckeln. Den offentliga nyckeln kan användas för att kryptera meddelanden som skickas till certifikatets ägare. Endast ägaren har åtkomst till den privata nyckeln, så endast ägaren kan dekryptera dessa meddelanden.
Certifikat måste utfärdas av en certifikatutfärdare, som ofta är utfärdare av certifikat från tredje part. I en Windows-domän ingår en certifikatutfärdare som kan användas för att utfärda certifikat till datorer i domänen.
Visa certifikat
För att arbeta med certifikat är det ofta nödvändigt att visa dem och undersöka deras egenskaper. Det här är enkelt att göra med snapin-modulen för Microsoft Management Console (MMC). Mer information finns i Så här visar du certifikat med MMC-snapin-modulen.
Certifikatarkiv
Certifikat finns i arkiv. Det finns två större butiksplatser som är ytterligare indelade i underlager. Om du är administratör på en dator kan du visa båda de större butikerna med hjälp av MMC-snapin-verktyget. Icke-administratörer kan bara visa det aktuella användararkivet.
Det lokala datorarkivet. Detta innehåller de certifikat som används av datorprocesser, till exempel ASP.NET. Använd den här platsen om du vill lagra certifikat som autentiserar servern till klienter.
Det aktuella användararkivet. Interaktiva program placerar vanligtvis certifikat här för datorns aktuella användare. Om du skapar ett klientprogram är det här du vanligtvis placerar certifikat som autentiserar en användare till en tjänst.
Dessa två butiker är ytterligare indelade i underlager. Det viktigaste av dessa när du programmerar med WCF är:
Betrodda rotcertifikatutfärdare. Du kan använda certifikaten i det här arkivet för att skapa en kedja med certifikat som kan spåras tillbaka till ett certifikatutfärdarcertifikat i det här arkivet.
Viktigt!
Den lokala datorn litar implicit på alla certifikat som placeras i det här arkivet, även om certifikatet inte kommer från en betrodd tredjepartscertifikatutfärdare. Därför ska du inte placera något certifikat i det här arkivet om du inte helt litar på utfärdaren och förstår konsekvenserna.
Personligt. Det här arkivet används för certifikat som är associerade med en användare av en dator. Vanligtvis används det här arkivet för certifikat som utfärdats av ett av certifikatutfärdarcertifikaten som finns i arkivet Betrodda rotcertifikatutfärdare. Alternativt kan ett certifikat som finns här vara självutfärdat och betrott av ett program.
Mer information om certifikatarkiv finns i Certifikatarkiv.
Välj en butik
Om du väljer var ett certifikat ska lagras beror det på hur och när tjänsten eller klienten körs. Följande allmänna regler gäller:
Om WCF-tjänsten finns i en Windows-tjänst använder du det lokala datorarkivet. Observera att administratörsbehörigheter krävs för att installera certifikat i det lokala datorarkivet.
Om tjänsten eller klienten är ett program som körs under ett användarkonto använder du det aktuella användararkivet.
Åtkomstlager
Butiker skyddas av åtkomstkontrollistor (ACL: er), precis som mappar på en dator. När du skapar en tjänst som hanteras av Internet Information Services (IIS) körs ASP.NET processen under ASP.NET-kontot. Det kontot måste ha åtkomst till det arkiv som innehåller certifikaten som en tjänst använder. Vart och ett av de viktigaste butikerna skyddas med en standardåtkomstlista, men listorna kan ändras. Om du skapar en separat roll för att få åtkomst till ett arkiv måste du ge rollen åtkomstbehörighet. Information om hur du ändrar åtkomstlistan med hjälp av verktyget WinHttpCertConfig.exe finns i How to: Create Temporary Certificates for Use During Development (Så här skapar du tillfälliga certifikat för användning under utveckling).
Kedjeförtroende och certifikatutfärdare
Certifikat skapas i en hierarki där varje enskilt certifikat är länkat till certifikatutfärdare som utfärdade certifikatet. Den här länken är till certifikatutfärdarcertifikatet. Certifikatutfärdarcertifikatet länkar sedan till certifikatutfärdare som utfärdade den ursprungliga certifikatutfärdarcertifikatutfärdarcertifikatet. Den här processen upprepas tills rotcertifikatutfärdarcertifikatet har nåtts. Rotcertifikatutfärdarcertifikatutfärdarcertifikatet är i sig betrott.
Digitala certifikat används för att autentisera en entitet genom att förlita sig på den här hierarkin, även kallat en förtroendekedja. Du kan visa valfritt certifikatskedja med hjälp av MMC-snapin-modulen genom att dubbelklicka på valfritt certifikat och sedan klicka på fliken Certifikatsökväg . Mer information om hur du importerar certifikatkedjor för en certifikatutfärdare finns i Så här anger du certifikatkedjan för certifikatutfärdare som används för att verifiera signaturer.
Kommentar
Alla utfärdare kan utses till betrodd rotutfärdare genom att placera utfärdarens certifikat i certifikatarkivet för betrodd rotutfärdare.
Inaktivera kedjeförtroende
När du skapar en ny tjänst kanske du använder ett certifikat som inte har utfärdats av ett betrott rotcertifikat, eller så kanske det utfärdande certifikatet inte finns i arkivet Betrodda rotcertifikatutfärdare. Endast i utvecklingssyfte kan du tillfälligt inaktivera den mekanism som kontrollerar förtroendekedjan för ett certifikat. Om du vill göra detta anger du CertificateValidationMode egenskapen till antingen PeerTrust eller PeerOrChainTrust. Endera läget anger att certifikatet antingen kan vara självutfärdat (peer-förtroende) eller en del av en förtroendekedja. Du kan ange egenskapen på någon av följande klasser.
Du kan också ange egenskapen med hjälp av konfigurationen. Följande element används för att ange valideringsläget:
Anpassad autentisering
Med CertificateValidationMode egenskapen kan du också anpassa hur certifikat autentiseras. Som standard är nivån inställd på ChainTrust. Om du vill använda Custom värdet måste du också ange CustomCertificateValidatorType attributet till en sammansättning och typ som används för att verifiera certifikatet. Om du vill skapa en anpassad validator måste du ärva från den abstrakta X509CertificateValidator klassen.
När du skapar en anpassad autentisering är Validate metoden den viktigaste metoden att åsidosätta. Ett exempel på anpassad autentisering finns i X.509 Certificate Validator-exemplet . Mer information finns i Validering av anpassade autentiseringsuppgifter och autentiseringsuppgifter.
Använda cmdleten PowerShell New-SelfSignedCertificate för att skapa en certifikatkedja
PowerShell New-SelfSignedCertificate-cmdleten skapar X.509-certifikat och privata nyckel/offentliga nyckelpar. Du kan spara den privata nyckeln på disken och sedan använda den för att utfärda och signera nya certifikat, vilket simulerar en hierarki med länkade certifikat. Cmdleten är endast avsedd att användas som ett hjälpmedel vid utveckling av tjänster och bör aldrig användas för att skapa certifikat för faktisk distribution. När du utvecklar en WCF-tjänst använder du följande steg för att skapa en förtroendekedja med cmdleten New-SelfSignedCertificate.
Skapa ett tillfälligt rotcertifikat (självsignerat) med hjälp av cmdleten New-SelfSignedCertificate. Spara den privata nyckeln på disken.
Använd det nya certifikatet för att utfärda ett annat certifikat som innehåller den offentliga nyckeln.
Importera rotcertifikatutfärdarcertifikatet till arkivet Betrodda rotcertifikatutfärdare.
Stegvisa instruktioner finns i Så här skapar du tillfälliga certifikat för användning under utveckling.
Vilket certifikat ska användas?
Vanliga frågor om certifikat är vilka certifikat som ska användas och varför. Svaret beror på om du programmerar en klient eller tjänst. Följande information innehåller en allmän riktlinje och är inte ett uttömmande svar på dessa frågor.
Tjänstcertifikat
Tjänstcertifikat har den primära uppgiften att autentisera servern till klienter. En av de första kontrollerna när en klient autentiserar en server är att jämföra värdet för fältet Ämne med den URI (Uniform Resource Identifier) som används för att kontakta tjänsten: DNS för båda måste matcha. Om till exempel tjänstens URI är http://www.contoso.com/endpoint/måste fältet Ämne också innehålla värdet www.contoso.com.
Observera att fältet kan innehålla flera värden, var och en prefix med en initiering för att ange värdet. Oftast är initieringen "CN" för eget namn, till exempel CN = www.contoso.com. Det är också möjligt att fältet Ämne är tomt, i vilket fall fältet Alternativt ämnesnamn kan innehålla DNS-namnvärdet .
Observera också att värdet för fältet Avsedda syften i certifikatet ska innehålla ett lämpligt värde, till exempel "Serverautentisering" eller "Klientautentisering".
Klientcertifikat
Klientcertifikat utfärdas vanligtvis inte av en tredjepartscertifikatutfärdare. I stället innehåller det personliga arkivet för den aktuella användarplatsen vanligtvis certifikat som placerats där av en rotutfärdare, med syftet "Klientautentisering". Klienten kan använda ett sådant certifikat när ömsesidig autentisering krävs.
Återkallning online och offlineåterkallning
Certifikatets giltighet
Varje certifikat är endast giltigt under en viss tidsperiod, så kallad giltighetsperiod. Giltighetsperioden definieras av fälten Giltig från och Giltig till i ett X.509-certifikat. Under autentiseringen kontrolleras certifikatet för att avgöra om certifikatet fortfarande är inom giltighetsperioden.
Lista över återkallade certifikat
När som helst under giltighetsperioden kan certifikatutfärdare återkalla ett certifikat. Detta kan inträffa av många orsaker, till exempel en kompromiss mellan certifikatets privata nyckel.
När detta inträffar är alla kedjor som kommer från det återkallade certifikatet också ogiltiga och är inte betrodda under autentiseringsprocedurerna. För att ta reda på vilka certifikat som återkallas publicerar varje utfärdare en tids- och datumstämplad lista över återkallade certifikat (CRL). Listan kan kontrolleras med antingen onlineåterkallning eller offlineåterkallning genom att ange RevocationMode egenskapen eller DefaultRevocationMode för följande klasser till något av X509RevocationMode uppräkningsvärdena: X509ClientCertificateAuthentication, X509PeerCertificateAuthentication, X509ServiceCertificateAuthenticationoch klasserna IssuedTokenServiceCredential . Standardvärdet för alla egenskaper är Online.
Du kan också ange läget i konfigurationen revocationMode med hjälp av attributet för både autentiseringen><< (för serviceBehaviors>) och autentiseringen>< (för <endpointBehaviors).>
Metoden SetCertificate
I WCF måste du ofta ange ett certifikat eller en uppsättning certifikat som en tjänst eller klient ska använda för att autentisera, kryptera eller digitalt signera ett meddelande. Du kan göra detta programmatiskt med hjälp SetCertificate av metoden för olika klasser som representerar X.509-certifikat. Följande klasser använder SetCertificate metoden för att ange ett certifikat.
Metoden SetCertificate fungerar genom att ange en butiksplats och lagringsplats, en "find"-typ (x509FindType parameter) som anger ett fält i certifikatet och ett värde som ska hittas i fältet. Följande kod skapar till exempel en ServiceHost instans och anger tjänstcertifikatet som används för att autentisera tjänsten till klienter med SetCertificate metoden .
Uri baseAddress = new Uri("http://cohowinery.com/services");
ServiceHost sh = new ServiceHost(typeof(CalculatorService), baseAddress );
sh.Credentials.ServiceCertificate.SetCertificate(
StoreLocation.LocalMachine, StoreName.My,
X509FindType.FindBySubjectName, "cohowinery.com");
Dim baseAddress As New Uri("http://cohowinery.com/services")
Dim sh As New ServiceHost(GetType(CalculatorService), baseAddress)
sh.Credentials.ServiceCertificate.SetCertificate( _
StoreLocation.LocalMachine, StoreName.My, _
X509FindType.FindBySubjectName, "cohowinery.com")
Flera certifikat med samma värde
Ett arkiv kan innehålla flera certifikat med samma ämnesnamn. Det innebär att om du anger att x509FindType är FindBySubjectName eller FindBySubjectDistinguishedName, och fler än ett certifikat har samma värde genereras ett undantag eftersom det inte finns något sätt att särskilja vilket certifikat som krävs. Du kan minimera detta genom att ange x509FindType till FindByThumbprint. Tumavtrycksfältet innehåller ett unikt värde som kan användas för att hitta ett specifikt certifikat i ett arkiv. Detta har dock en egen nackdel: om certifikatet återkallas eller förnyas SetCertificate misslyckas metoden eftersom tumavtrycket också är borta. Om certifikatet inte längre är giltigt misslyckas autentiseringen. Du kan minimera detta genom att ange parametern x590FindType till FindByIssuerName och ange utfärdarens namn. Om ingen viss utfärdare krävs kan du också ange något av de andra X509FindType uppräkningsvärdena, till exempel FindByTimeValid.
Certifikat i konfiguration
Du kan också ange certifikat med hjälp av konfigurationen. Om du skapar en tjänst anges autentiseringsuppgifter, inklusive certifikat, under serviceBehaviors>.< När du programmerar en klient anges certifikat under endpointBehaviors>.<
Mappa ett certifikat till ett användarkonto
En funktion i IIS och Active Directory är möjligheten att mappa ett certifikat till ett Windows-användarkonto. Mer information om funktionen finns i Mappa certifikat till användarkonton.
Mer information om hur du använder Active Directory-mappning finns i Mappa klientcertifikat med katalogtjänstmappning.
Med den här funktionen aktiverad kan du ange MapClientCertificateToWindowsAccount egenskapen för X509ClientCertificateAuthentication klassen till true. I konfigurationen mapClientCertificateToWindowsAccount kan du ange attributet för autentiseringselementet><till true, enligt följande kod.
<serviceBehaviors>
<behavior name="MappingBehavior">
<serviceCredentials>
<clientCertificate>
<authentication certificateValidationMode="None" mapClientCertificateToWindowsAccount="true" />
</clientCertificate>
</serviceCredentials>
</behavior>
</serviceBehaviors>
Mappning av ett X.509-certifikat till token som representerar ett Windows-användarkonto anses vara en behörighetshöjning eftersom Windows-token kan användas när den har mappats för att få åtkomst till skyddade resurser. Därför kräver domänprincipen att X.509-certifikatet följer principen innan den mappas. SChannel-säkerhetspaketet tillämpar det här kravet.
När du använder .NET Framework 3.5 eller senare versioner ser WCF till att certifikatet överensstämmer med domänprincipen innan det mappas till ett Windows-konto.
I den första versionen av WCF görs mappningen utan att du rådfrågar domänprincipen. Därför är det möjligt att äldre program som tidigare fungerade när de kördes under den första versionen misslyckas om mappningen är aktiverad och X.509-certifikatet inte uppfyller domänprincipen.