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 granska dem och undersöka deras egenskaper. Det här är enkelt att göra med snapin-modulen för Microsoft Management Console (MMC). För mer information, se Så här: Visa certifikat med MMC Snap-in.

Certifikatarkiv

Certifikat finns i butiker. Det finns två större butikslägen som ytterligare är indelade i underbutiker. 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 se den aktuella användarbutiken.

• 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 underbutiker. Det viktigaste av dessa när du programmerar med WCF är:

• Betrodda rotcertifikat utfä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 den här lagringsplatsen, även om certifikatet inte kommer från en betrodd tredjepartsutfä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. Den här lagringsplatsen används för certifikat som är associerade med en användare av en dator. Vanligtvis används denna lagringsplats för certifikat som utfärdats av en av de certifikatutfärdare som finns i lagringsplatsen för Betrodda rotcertifikat. 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 är värd i en Windows-tjänst, använder du det lokala datorlagret. 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, ska du använda den aktuella användarens lagring.

Åtkomstbutiker

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ärdarens certifikat länkar sedan till den certifikatutfärdaren som utfärdade det ursprungliga certifikatutfärdarens certifikat. Den här processen upprepas tills Rot-CA:s certifikat har nåtts. Rotcertifikatutfärdarens certifikat är i sig själv 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.

Inaktivera kedjeförtroende

När du skapar en ny tjänst kan du använda ett certifikat som inte har utfärdats av ett betrott rotcertifikat, eller så kan det utfärdande certifikatet självt saknas i förvaret för Betrodda rotcertifikatsutfä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:

• <autentisering>

• <peerAuthentication>

• <meddelandeavsändarauktorisering>

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 . För mer information, se Anpassade autentiseringsuppgifter och validering av autentiseringsuppgifter.

Använda PowerShell New-SelfSignedCertificate-cmdleten 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.

1. Skapa ett tillfälligt rotutfärdarcertifikat (självsignerat) med hjälp av cmdleten New-SelfSignedCertificate. Spara den privata nyckeln på disken.

2. Använd det nya certifikatet för att utfärda ett annat certifikat som innehåller den offentliga nyckeln.

3. Importera rotauktoritetscertifikatet till lagringsplatsen för Betrodda rotcertifikatutfärdare.

4. 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, där varje värde är försett med ett prefix och ett inledande tecken 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ändarlokaliseringen vanligtvis certifikat som placerats där av en rotcertifieringsmyndighet, 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>).

SetCertificate-metoden

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

En butik kan innehålla flera certifikat med samma namn. 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. Fingeravtrycksfältet innehåller ett unikt värde som kan användas för att hitta ett specifikt certifikat i ett lager. 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.

Konfigurationscertifikat

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.

Se även

• System.ServiceModel.Channels
• System.ServiceModel.Security
• System.ServiceModel
• X509FindType
• Skydda tjänster och klienter