Werken met certificaten
Voor het programmeren van WCF-beveiliging (Windows Communication Foundation), worden digitale X.509-certificaten vaak gebruikt voor het verifiëren van clients en servers, versleutelen en digitaal ondertekenen van berichten. In dit onderwerp wordt kort uitgelegd wat de functies van digitale X.509-certificaten zijn en hoe u deze kunt gebruiken in WCF, en bevat koppelingen naar onderwerpen die deze concepten verder uitleggen of die laten zien hoe u algemene taken kunt uitvoeren met WCF en certificaten.
Kortom, een digitaal certificaat maakt deel uit van een openbare-sleutelinfrastructuur (PKI), een systeem van digitale certificaten, certificeringsinstanties en andere registratieautoriteiten die de geldigheid verifiëren en verifiëren van elke partij die betrokken is bij een elektronische transactie via het gebruik van openbare-sleutelcryptografie. Een certificeringsinstantie geeft certificaten uit en elk certificaat heeft een set velden die gegevens bevatten, zoals onderwerp (de entiteit waaraan het certificaat is verleend), geldigheidsdatums (wanneer het certificaat geldig is), verlener (de entiteit die het certificaat heeft uitgegeven) en een openbare sleutel. In WCF worden deze eigenschappen verwerkt als een Claim, en elke claim wordt verder onderverdeeld in twee typen: identiteit en recht. Zie X.509 Public Key Certificates voor meer informatie over X.509-certificaten. Zie Claims en autorisatie beheren met het identiteitsmodel voor meer informatie over claims en autorisatie in WCF. Zie Enterprise PKI met Windows Server 2012 R2 Active Directory Certificate Services voor meer informatie over het implementeren van een PKI.
De primaire functie van een certificaat is het verifiëren van de identiteit van de eigenaar van het certificaat aan anderen. Een certificaat bevat de openbare sleutel van de eigenaar, terwijl de eigenaar de persoonlijke sleutel behoudt. De openbare sleutel kan worden gebruikt om berichten te versleutelen die naar de eigenaar van het certificaat worden verzonden. Alleen de eigenaar heeft toegang tot de persoonlijke sleutel, zodat alleen de eigenaar deze berichten kan ontsleutelen.
Certificaten moeten worden uitgegeven door een certificeringsinstantie, die vaak een externe verlener van certificaten is. In een Windows-domein is een certificeringsinstantie opgenomen die kan worden gebruikt om certificaten uit te geven aan computers in het domein.
Certificaten weergeven
Als u met certificaten wilt werken, is het vaak nodig om ze te bekijken en hun eigenschappen te onderzoeken. Dit wordt eenvoudig gedaan met de module Microsoft Management Console (MMC). Zie Instructies voor meer informatie : Certificaten weergeven met de MMC-module.
Certificaatarchieven
Certificaten zijn te vinden in winkels. Er bestaan twee belangrijke winkellocaties die verder zijn onderverdeeld in subarchieven. Als u de beheerder bent op een computer, kunt u beide hoofdarchieven weergeven met behulp van de MMC-module. Niet-beheerders kunnen alleen het huidige gebruikersarchief bekijken.
Het lokale computerarchief. Dit bevat de certificaten die worden geopend door computerprocessen, zoals ASP.NET. Gebruik deze locatie om certificaten op te slaan die de server verifiëren bij clients.
Het huidige gebruikersarchief. Interactieve toepassingen plaatsen hier doorgaans certificaten voor de huidige gebruiker van de computer. Als u een clienttoepassing maakt, plaatst u doorgaans certificaten die een gebruiker verifiëren bij een service.
Deze twee winkels zijn verder onderverdeeld in subarchieven. De belangrijkste van deze zijn bij het programmeren met WCF:
Vertrouwde basiscertificeringsinstanties. U kunt de certificaten in dit archief gebruiken om een keten van certificaten te maken, die kan worden teruggezet naar een certificeringsinstantiecertificaat in dit archief.
Belangrijk
De lokale computer vertrouwt impliciet elk certificaat dat in dit archief is geplaatst, zelfs als het certificaat niet afkomstig is van een vertrouwde certificeringsinstantie van derden. Plaats daarom geen certificaat in dit archief, tenzij u de uitgever volledig vertrouwt en de gevolgen begrijpt.
Persoonlijk. Dit archief wordt gebruikt voor certificaten die zijn gekoppeld aan een gebruiker van een computer. Dit archief wordt meestal gebruikt voor certificaten die zijn uitgegeven door een van de certificeringsinstantiecertificaten die zijn gevonden in het archief vertrouwde basiscertificeringsinstanties. Een certificaat dat hier wordt gevonden, kan ook zelf worden uitgegeven en vertrouwd door een toepassing.
Zie Certificaatarchieven voor meer informatie over certificaatarchieven.
Een winkel selecteren
Wanneer u selecteert waar een certificaat moet worden opgeslagen, is afhankelijk van hoe en wanneer de service of client wordt uitgevoerd. De volgende algemene regels zijn van toepassing:
Als de WCF-service wordt gehost in een Windows-service, gebruikt u het archief van de lokale computer . Beheerdersbevoegdheden zijn vereist voor het installeren van certificaten in het lokale computerarchief.
Als de service of client een toepassing is die wordt uitgevoerd onder een gebruikersaccount, gebruikt u de huidige gebruikersopslag .
Toegangsarchieven
Winkels worden beveiligd door toegangsbeheerlijsten (ACL's), net zoals mappen op een computer. Wanneer u een service maakt die wordt gehost door Internet Information Services (IIS), wordt het ASP.NET proces uitgevoerd onder het ASP.NET-account. Dat account moet toegang hebben tot het archief dat de certificaten bevat die een service gebruikt. Elk van de belangrijkste winkels is beveiligd met een standaardtoegangslijst, maar de lijsten kunnen worden gewijzigd. Als u een afzonderlijke rol maakt voor toegang tot een archief, moet u die roltoegangsmachtiging verlenen. Zie Voor meer informatie over het wijzigen van de toegangslijst met behulp van het hulpprogramma WinHttpCertConfig.exe: Tijdelijke certificaten maken voor gebruik tijdens de ontwikkeling.
Vertrouwensrelatie en certificeringsinstanties van de keten
Certificaten worden gemaakt in een hiërarchie waarin elk afzonderlijk certificaat is gekoppeld aan de CA die het certificaat heeft uitgegeven. Deze koppeling is naar het certificaat van de CA. Het certificaat van de CA wordt vervolgens gekoppeld aan de CA die het oorspronkelijke CA-certificaat heeft uitgegeven. Dit proces wordt herhaald totdat het certificaat van de basis-CA is bereikt. Het certificaat van de basis-CA wordt inherent vertrouwd.
Digitale certificaten worden gebruikt om een entiteit te verifiëren door te vertrouwen op deze hiërarchie, ook wel een vertrouwensketen genoemd. U kunt de keten van een certificaat weergeven met behulp van de MMC-module door te dubbelklikken op een certificaat en vervolgens op het tabblad Certificaatpad te klikken. Zie Procedure voor meer informatie over het importeren van certificaatketens voor een certificeringsinstantie : De certificeringsinstantiecertificaatketen opgeven die wordt gebruikt om handtekeningen te verifiëren.
Notitie
Elke verlener kan een vertrouwde basisinstantie worden aangewezen door het certificaat van de verlener in het certificaatarchief van de vertrouwde basisinstantie te plaatsen.
Ketenvertrouwen uitschakelen
Wanneer u een nieuwe service maakt, gebruikt u mogelijk een certificaat dat niet is uitgegeven door een vertrouwd basiscertificaat, of het verlenende certificaat zelf bevindt zich mogelijk niet in het archief vertrouwde basiscertificeringsinstanties. Alleen voor ontwikkelingsdoeleinden kunt u tijdelijk het mechanisme uitschakelen waarmee de vertrouwensketen voor een certificaat wordt gecontroleerd. Hiervoor stelt u de CertificateValidationMode
eigenschap in op of PeerTrust
PeerOrChainTrust
. In beide modus wordt aangegeven dat het certificaat zelf kan worden uitgegeven (peer trust) of een deel van een vertrouwensketen. U kunt de eigenschap instellen op een van de volgende klassen.
U kunt de eigenschap ook instellen met behulp van configuratie. De volgende elementen worden gebruikt om de validatiemodus op te geven:
Aangepaste verificatie
Met de CertificateValidationMode
eigenschap kunt u ook aanpassen hoe certificaten worden geverifieerd. Standaard is het niveau ingesteld op ChainTrust
. Als u de Custom waarde wilt gebruiken, moet u ook het CustomCertificateValidatorType
kenmerk instellen op een assembly en het type dat wordt gebruikt om het certificaat te valideren. Als u een aangepaste validator wilt maken, moet u overnemen van de abstracte X509CertificateValidator klasse.
Bij het maken van een aangepaste verificator is de belangrijkste methode die moet worden overschreven de Validate methode. Zie het X.509 Certificate Validator-voorbeeld voor een voorbeeld van aangepaste verificatie. Zie Aangepaste referentie- en referentievalidatie voor meer informatie.
De Cmdlet New-SelfSignedCertificate van PowerShell gebruiken om een certificaatketen te bouwen
Met de Cmdlet New-SelfSignedCertificate van PowerShell worden X.509-certificaten en persoonlijke sleutel-/openbare-sleutelparen gemaakt. U kunt de persoonlijke sleutel opslaan op de schijf en deze vervolgens gebruiken om nieuwe certificaten uit te geven en te ondertekenen, waardoor een hiërarchie van gekoppelde certificaten wordt gesimpliceerd. De cmdlet is alleen bedoeld voor gebruik als hulpmiddel bij het ontwikkelen van services en mag nooit worden gebruikt voor het maken van certificaten voor de daadwerkelijke implementatie. Bij het ontwikkelen van een WCF-service gebruikt u de volgende stappen om een vertrouwensketen te bouwen met de cmdlet New-SelfSignedCertificate.
Maak een tijdelijk basisinstantiecertificaat (zelfondertekend) met behulp van de cmdlet New-SelfSignedCertificate. Sla de persoonlijke sleutel op de schijf op.
Gebruik het nieuwe certificaat om een ander certificaat uit te geven dat de openbare sleutel bevat.
Importeer het basiscertificeringsinstantiecertificaat in het archief vertrouwde basiscertificeringsinstanties.
Zie Voor stapsgewijze instructies : Tijdelijke certificaten maken voor gebruik tijdens de ontwikkeling.
Welk certificaat moet worden gebruikt?
Veelgestelde vragen over certificaten zijn welk certificaat moet worden gebruikt en waarom. Het antwoord is afhankelijk van of u een client of service programmeert. De volgende informatie bevat een algemene richtlijn en is geen volledig antwoord op deze vragen.
Servicecertificaten
Servicecertificaten hebben de primaire taak om de server te verifiëren bij clients. Een van de eerste controles wanneer een client een server verifieert, is door de waarde van het veld Onderwerp te vergelijken met de URI (Uniform Resource Identifier) die wordt gebruikt om contact op te maken met de service: de DNS van beide moet overeenkomen. Als de URI van de service bijvoorbeeld is http://www.contoso.com/endpoint/
, moet het veld Onderwerp ook de waarde www.contoso.com
bevatten.
Houd er rekening mee dat het veld meerdere waarden kan bevatten, elk voorafgegaan door een initialisatie om de waarde aan te geven. Meestal is de initialisatie 'CN' voor algemene naam, CN = www.contoso.com
bijvoorbeeld. Het is ook mogelijk dat het veld Onderwerp leeg is. In dat geval kan het veld Alternatieve naam voor onderwerp de waarde van de DNS-naam bevatten.
Let ook op de waarde van het veld Beoogde doeleinden van het certificaat moet een geschikte waarde bevatten, zoals 'Serververificatie' of 'Clientverificatie'.
Clientcertificaten
Clientcertificaten worden doorgaans niet uitgegeven door een externe certificeringsinstantie. In plaats daarvan bevat het persoonlijke archief van de huidige gebruikerslocatie doorgaans certificaten die daar zijn geplaatst door een basisinstantie, met het beoogde doel 'Clientverificatie'. De client kan een dergelijk certificaat gebruiken wanneer wederzijdse verificatie vereist is.
Online intrekken en offline intrekken
Geldigheid van certificaat
Elk certificaat is alleen geldig voor een bepaalde periode, de geldigheidsperiode genoemd. De geldigheidsperiode wordt gedefinieerd door de velden Geldig van en Geldig in de velden van een X.509-certificaat. Tijdens de verificatie wordt het certificaat gecontroleerd om te bepalen of het certificaat nog binnen de geldigheidsperiode valt.
Certificaatintrekkingslijst
Op elk moment tijdens de geldigheidsperiode kan de certificeringsinstantie een certificaat intrekken. Dit kan om verschillende redenen gebeuren, zoals een inbreuk op de persoonlijke sleutel van het certificaat.
Wanneer dit gebeurt, zijn alle ketens die afstammen van het ingetrokken certificaat ook ongeldig en worden ze niet vertrouwd tijdens verificatieprocedures. Om erachter te komen welke certificaten worden ingetrokken, publiceert elke verlener een tijd- en datumstempellijst voor certificaatintrekkingslijst (CRL). De lijst kan worden gecontroleerd met behulp van onlineintrekking of offlineintrekking door de RevocationMode
of DefaultRevocationMode
eigenschap van de volgende klassen in te stellen op een van de X509RevocationMode opsommingswaarden: X509ClientCertificateAuthentication, X509PeerCertificateAuthentication, X509ServiceCertificateAuthenticationen de IssuedTokenServiceCredential klassen. De standaardwaarde voor alle eigenschappen is Online
.
U kunt de modus ook instellen in de configuratie met behulp van het revocationMode
kenmerk van zowel de <verificatie> (van de <serviceBehaviors>) als de <verificatie> (van de< endpointBehaviors).>
De methode SetCertificate
In WCF moet u vaak een certificaat of set certificaten opgeven die een service of client moet gebruiken om een bericht te verifiëren, te versleutelen of digitaal te ondertekenen. U kunt dit programmatisch doen met behulp van de SetCertificate
methode van verschillende klassen die X.509-certificaten vertegenwoordigen. De volgende klassen gebruiken de SetCertificate
methode om een certificaat op te geven.
De SetCertificate
methode werkt door een winkellocatie aan te wijzen en op te slaan, een zoektype (x509FindType
parameter) dat een veld van het certificaat aangeeft en een waarde die in het veld moet worden gevonden. Met de volgende code wordt bijvoorbeeld een ServiceHost exemplaar gemaakt en wordt het servicecertificaat ingesteld dat wordt gebruikt voor het verifiëren van de service voor clients met de SetCertificate
methode.
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")
Meerdere certificaten met dezelfde waarde
Een archief kan meerdere certificaten met dezelfde onderwerpnaam bevatten. Dit betekent dat als u opgeeft dat het x509FindType
is FindBySubjectName of FindBySubjectDistinguishedName, en meer dan één certificaat dezelfde waarde heeft, er een uitzondering wordt gegenereerd omdat er geen manier is om te onderscheiden welk certificaat is vereist. U kunt dit beperken door de instelling in x509FindType
te stellen op FindByThumbprint. Het vingerafdrukveld bevat een unieke waarde die kan worden gebruikt om een specifiek certificaat in een archief te vinden. Dit heeft echter een eigen nadeel: als het certificaat wordt ingetrokken of vernieuwd, mislukt de SetCertificate
methode omdat de vingerafdruk ook is verdwenen. Als het certificaat niet meer geldig is, mislukt de verificatie. U kunt dit verhelpen door de x590FindType
parameter FindByIssuerName in te stellen en de naam van de verlener op te geven. Als er geen bepaalde verlener is vereist, kunt u ook een van de andere X509FindType opsommingswaarden instellen, zoals FindByTimeValid.
Certificaten in configuratie
U kunt certificaten ook instellen met behulp van configuratie. Als u een service maakt, worden referenties, inclusief certificaten, opgegeven onder de serviceBehaviors>.< Wanneer u een client programmeert, worden certificaten opgegeven onder de <endpointBehaviors>.
Een certificaat toewijzen aan een gebruikersaccount
Een functie van IIS en Active Directory is de mogelijkheid om een certificaat toe te wijzen aan een Windows-gebruikersaccount. Zie Certificaten toewijzen aan gebruikersaccounts voor meer informatie over de functie.
Zie Clientcertificaten toewijzen met Directory-servicetoewijzing voor meer informatie over het gebruik van Active Directory-toewijzing.
Als deze mogelijkheid is ingeschakeld, kunt u de MapClientCertificateToWindowsAccount eigenschap van de X509ClientCertificateAuthentication klasse instellen op true
. In de configuratie kunt u het mapClientCertificateToWindowsAccount
kenmerk van het <verificatie-element>true
instellen op, zoals wordt weergegeven in de volgende code.
<serviceBehaviors>
<behavior name="MappingBehavior">
<serviceCredentials>
<clientCertificate>
<authentication certificateValidationMode="None" mapClientCertificateToWindowsAccount="true" />
</clientCertificate>
</serviceCredentials>
</behavior>
</serviceBehaviors>
Het toewijzen van een X.509-certificaat aan het token dat een Windows-gebruikersaccount vertegenwoordigt, wordt beschouwd als uitbreiding van bevoegdheden, omdat het Windows-token na toewijzing kan worden gebruikt om toegang te krijgen tot beveiligde resources. Daarom vereist domeinbeleid het X.509-certificaat om te voldoen aan het beleid voordat het wordt toegewezen. Dit vereiste wordt afgedwongen door het SChannel-beveiligingspakket .
Wanneer u .NET Framework 3.5 of hoger gebruikt, zorgt WCF ervoor dat het certificaat voldoet aan het domeinbeleid voordat het wordt toegewezen aan een Windows-account.
In de eerste release van WCF wordt toewijzing uitgevoerd zonder het domeinbeleid te raadplegen. Daarom is het mogelijk dat oudere toepassingen die worden gebruikt bij het uitvoeren onder de eerste release, mislukken als de toewijzing is ingeschakeld en het X.509-certificaat niet voldoet aan het domeinbeleid.