Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Pour programmer la sécurité windows Communication Foundation (WCF), les certificats numériques X.509 sont couramment utilisés pour authentifier les clients et les serveurs, chiffrer et signer numériquement des messages. Cette rubrique explique brièvement les fonctionnalités de certificat numérique X.509 et explique comment les utiliser dans WCF, et inclut des liens vers des rubriques qui expliquent ces concepts plus loin ou qui montrent comment effectuer des tâches courantes à l’aide de WCF et de certificats.
En bref, un certificat numérique fait partie d’une infrastructure à clé publique (PKI), qui est un système de certificats numériques, d’autorités de certification et d’autres autorités d’inscription qui vérifient et authentifient la validité de chaque partie impliquée dans une transaction électronique par le biais de l’utilisation du chiffrement à clé publique. Une autorité de certification émet des certificats et chaque certificat a un ensemble de champs qui contiennent des données, telles que l’objet (l’entité à laquelle le certificat est émis), les dates de validité (lorsque le certificat est valide), l’émetteur (l’entité qui a émis le certificat) et une clé publique. Dans WCF, chacune de ces propriétés est traitée comme un Claim, et chaque revendication est divisée en deux types : identité et droit. Pour plus d’informations sur les certificats X.509, consultez certificats de clé publique X.509. Pour plus d’informations sur les revendications et l’autorisation dans WCF, consultez Gestion des revendications et des autorisations avec le modèle d’identité. Pour plus d’informations sur l’implémentation d’une infrastructure à clé publique, consultez Infrastructure à clé publique d’entreprise avec Windows Server 2012 R2 Active Directory Certificate Services.
La fonction principale d’un certificat consiste à authentifier l’identité du propriétaire du certificat auprès d’autres personnes. Un certificat contient la clé publique du propriétaire, tandis que le propriétaire conserve la clé privée. La clé publique peut être utilisée pour chiffrer les messages envoyés au propriétaire du certificat. Seul le propriétaire a accès à la clé privée, de sorte que seul le propriétaire peut déchiffrer ces messages.
Les certificats doivent être émis par une autorité de certification, qui est souvent un émetteur tiers de certificats. Sur un domaine Windows, une autorité de certification est incluse qui peut être utilisée pour émettre des certificats à des ordinateurs sur le domaine.
Afficher les certificats
Si vous souhaitez utiliser des certificats, vous devrez souvent les afficher et examiner leurs propriétés au préalable. Pour ce faire, il vous suffit d'utiliser l'outil enfichable MMC (Microsoft Management Console). Pour plus d’informations, consultez la page Affichage de certificats à l’aide du composant logiciel enfichable MMC.
Magasins de certificats
Les certificats sont trouvés dans les magasins. Deux principaux emplacements de magasin existent qui sont divisés en sous-magasins. Si vous disposez des droits administrateur sur un ordinateur, vous pouvez afficher ces deux principaux magasins à l'aide de l'outil enfichable MMC. Les non-administrateurs peuvent afficher uniquement l'espace de stockage utilisateur actuel.
Magasin d’ordinateurs local. Il contient les certificats accessibles par les processus de machine, tels que ASP.NET. Utilisez cet emplacement pour stocker des certificats qui authentifient le serveur auprès des clients.
Magasin de l’utilisateur actuel. Les applications interactives placent généralement des certificats ici pour l’utilisateur actuel de l’ordinateur. Si vous créez une application cliente, c’est là que vous placez généralement des certificats qui authentifient un utilisateur auprès d’un service.
Ces deux magasins sont divisés en sous-magasins. Les plus importantes de ces opérations lors de la programmation avec WCF sont les suivantes :
Autorités de certification racine approuvées. Vous pouvez utiliser les certificats de ce magasin pour créer une chaîne de certificats, qui peut être retracée vers un certificat d’autorité de certification dans ce magasin.
Importante
L’ordinateur local approuve implicitement tout certificat placé dans ce magasin, même si le certificat ne provient pas d’une autorité de certification tierce approuvée. Pour cette raison, n’placez aucun certificat dans ce magasin, sauf si vous approuvez entièrement l’émetteur et comprenez les conséquences.
Personnel. Ce magasin est utilisé pour les certificats associés à un utilisateur d’un ordinateur. Ce magasin est en principe utilisé pour stocker les certificats publiés par l'un des certificats d'autorité de certification stockés dans le magasin Autorités de certification racine approuvées. Alternativement, un certificat trouvé ici peut être auto-délivré et approuvé par une application logicielle.
Pour plus d’informations sur les magasins de certificats, consultez Magasins de certificats.
Sélectionner un magasin
La sélection de l’emplacement de stockage d’un certificat dépend de la façon et du moment où le service ou le client s’exécute. Les règles générales suivantes s’appliquent :
Si le service WCF est hébergé dans un service Windows, utilisez le magasin d’ordinateurs local . Notez que les privilèges d’administrateur sont requis pour installer des certificats dans le magasin d’ordinateurs local.
Si le service ou le client est une application qui s’exécute sous un compte d’utilisateur, utilisez le magasin de l’utilisateur actuel.
Accéder aux magasins
Les magasins sont protégés par des listes de contrôle d’accès (ACL), tout comme les dossiers sur un ordinateur. Lors de la création d’un service hébergé par Internet Information Services (IIS), le processus ASP.NET s’exécute sous le compte ASP.NET. Ce compte doit avoir accès au magasin qui contient les certificats qu’un service utilise. Chacun des magasins principaux est protégé par une liste d’accès par défaut, mais les listes peuvent être modifiées. Si vous créez un rôle distinct pour accéder à un magasin, vous devez accorder cette autorisation d’accès au rôle. Pour savoir comment modifier la liste d’accès à l’aide de l’outil WinHttpCertConfig.exe, consultez Comment : créer des certificats temporaires à utiliser pendant le développement.
Chaîne de confiance et d’autorités de certification
Les certificats sont créés dans une hiérarchie où chaque certificat individuel est lié à l’autorité de certification qui a émis le certificat. Ce lien est vers le certificat de l’autorité de certification. Le certificat de l’autorité de certification crée un lien vers l’autorité de certification qui a émis le certificat de l’autorité de certification d’origine. Ce processus est répété jusqu’à ce que le certificat de l’autorité de certification racine soit atteint. Le certificat de l’autorité de certification racine est intrinsèquement approuvé.
Les certificats numériques sont utilisés pour authentifier une entité en s’appuyant sur cette hiérarchie, également appelée chaîne d’approbation. Vous pouvez afficher la chaîne de n’importe quel certificat à l’aide du composant logiciel enfichable MMC en double-cliquant sur n’importe quel certificat, puis en cliquant sur l’onglet Chemin du certificat . Pour plus d’informations sur l’importation de chaînes de certificats pour une autorité de certification, consultez Guide pratique pour spécifier la chaîne de certificats d’autorité de certification utilisée pour vérifier les signatures.
Remarque
N’importe quel émetteur peut être désigné comme autorité racine approuvée en plaçant le certificat de l’émetteur dans le magasin de certificats d’autorité racine approuvé.
Désactiver la confiance de la chaîne
Lors de la création d'un nouveau service, vous pouvez utiliser un certificat qui n'est pas émis par une autorité de certification racine approuvée, ou le certificat d'émission lui-même peut ne pas se trouver dans le magasin des autorités de certification racines approuvées. À des fins de développement uniquement, vous pouvez désactiver temporairement le mécanisme qui vérifie la chaîne d’approbation d’un certificat. Pour ce faire, définissez la propriété sur CertificateValidationMode, PeerTrust ou PeerOrChainTrust. Chaque mode spécifie que le certificat peut être auto-émis (confiance entre pairs) ou une partie d'une chaîne de confiance. Vous pouvez définir la propriété de n'importe laquelle des classes suivantes.
Vous pouvez également définir la propriété à l’aide de la configuration. Les éléments suivants sont utilisés pour spécifier le mode de validation :
Authentification personnalisée
La CertificateValidationMode propriété vous permet également de personnaliser la façon dont les certificats sont authentifiés. Par défaut, le niveau est défini sur ChainTrust. Pour utiliser la Custom valeur, vous devez également définir l’attribut CustomCertificateValidatorType sur un assembly et un type utilisé pour valider le certificat. Pour créer un validateur personnalisé, vous devez hériter de la classe abstraite X509CertificateValidator .
Lors de la création d’un authentificateur personnalisé, la méthode la plus importante à remplacer est la Validate méthode. Pour obtenir un exemple d’authentification personnalisée, consultez l’exemple de validateur de certificat X.509 . Pour plus d’informations, consultez La validation des informations d’identification et des informations d’identification personnalisées.
Utiliser l’applet de commande PowerShell New-SelfSignedCertificate pour créer une chaîne de certificats
L’applet de commande PowerShell New-SelfSignedCertificate crée des certificats X.509 et des paires clé privée/clé publique. Vous pouvez enregistrer la clé privée sur le disque, puis l’utiliser pour émettre et signer de nouveaux certificats, simulant ainsi une hiérarchie de certificats chaînés. L’applet de commande est destinée à être utilisée uniquement comme aide lors du développement de services et ne doit jamais être utilisée pour créer des certificats pour le déploiement réel. Lors du développement d’un service WCF, procédez comme suit pour créer une chaîne d’approbation avec l’applet de commande New-SelfSignedCertificate.
Créez un certificat d’autorité racine temporaire (auto-signé) à l’aide de l’applet de commande New-SelfSignedCertificate. Enregistrez la clé privée sur le disque.
Utilisez le nouveau certificat pour émettre un autre certificat qui contient la clé publique.
Importez le certificat d'autorité racine dans le magasin Autorités de certification racine approuvées.
Pour obtenir des instructions pas à pas, consultez Guide pratique pour créer des certificats temporaires à utiliser pendant le développement.
Quel certificat utiliser ?
Les questions courantes sur les certificats sont le certificat à utiliser et pourquoi. La réponse dépend de la programmation d’un client ou d’un service. Les informations suivantes fournissent une orientation générale et ne constituent pas une réponse exhaustive à ces questions.
Certificats de service
Les certificats de service ont la tâche principale d’authentification du serveur auprès des clients. L’une des vérifications initiales lorsqu’un client authentifie un serveur consiste à comparer la valeur du champ Objet à l’URI (Uniform Resource Identifier) utilisé pour contacter le service : le DNS des deux doit correspondre. Par exemple, si l’URI du service est http://www.contoso.com/endpoint/ alors le champ Objet doit également contenir la valeur www.contoso.com.
Notez que le champ peut contenir plusieurs valeurs, chacune précédée d’une initialisation pour indiquer la valeur. Le plus souvent, l’initialisation est « CN » pour le nom commun, par exemple CN = www.contoso.com. Il est également possible que le champ Objet soit vide, auquel cas le champ Autre nom de l’objet peut contenir la valeur dns Name .
Notez également que la valeur du champ Objectifs prévus du certificat doit inclure une valeur appropriée, telle que « Authentification du serveur » ou « Authentification du client ».
Certificats de client
Les certificats clients ne sont généralement pas émis par une autorité de certification tierce. Au lieu de cela, le magasin personnel de l’emplacement utilisateur actuel contient généralement des certificats placés par une autorité racine, avec l’objectif prévu de l'« authentification du client ». Le client peut utiliser un tel certificat lorsque l’authentification mutuelle est requise.
Révocation en ligne et révocation hors connexion
Validité du certificat
Chaque certificat est valide uniquement pour une période donnée, appelée période de validité. La période de validité est définie par les champs Valide du et Valide jusqu'au d'un certificat X.509. Pendant l’authentification, le certificat est vérifié pour déterminer si le certificat est toujours dans la période de validité.
Liste de révocation de certificats
À tout moment pendant la période de validité, l’autorité de certification peut révoquer un certificat. Cela peut se produire pour de nombreuses raisons, comme une compromission de la clé privée du certificat.
Lorsque cela se produit, toutes les chaînes qui descendent du certificat révoqué ne sont pas valides et ne sont pas approuvées pendant les procédures d’authentification. Pour savoir quels certificats sont révoqués, chaque émetteur publie une liste de révocation de certificats horodatée. La liste peut être vérifiée à l’aide de la révocation en ligne ou de la révocation hors connexion en définissant la propriété RevocationMode ou DefaultRevocationMode des classes suivantes sur l’une des valeurs d’énumération X509RevocationMode : X509ClientCertificateAuthentication, X509PeerCertificateAuthentication, X509ServiceCertificateAuthentication, et les classes IssuedTokenServiceCredential. La valeur par défaut de toutes les propriétés est Online.
Vous pouvez également définir le mode dans la configuration à l’aide de l’attribut revocationMode de l’authentification <> (des comportements de service <serviceBehaviors>) et de l’authentification <> (des comportements de point de terminaison <endpointBehaviors>).
Méthode SetCertificate
Dans WCF, vous devez souvent spécifier un certificat ou un ensemble de certificats qu’un service ou un client doit utiliser pour authentifier, chiffrer ou signer numériquement un message. Pour ce faire, vous pouvez utiliser la SetCertificate méthode de différentes classes qui représentent des certificats X.509. Les classes suivantes utilisent la SetCertificate méthode pour spécifier un certificat.
La SetCertificate méthode fonctionne en désignant un emplacement de magasin et un magasin, un type « find » (x509FindType paramètre) qui spécifie un champ du certificat et une valeur à rechercher dans le champ. Par exemple, le code suivant crée une ServiceHost instance et définit le certificat de service utilisé pour authentifier le service auprès des clients avec la SetCertificate méthode.
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")
Plusieurs certificats avec la même valeur
Un magasin peut contenir plusieurs certificats portant le même nom d’objet. Cela signifie que si vous spécifiez que le x509FindType certificat est FindBySubjectName ou FindBySubjectDistinguishedName, et que plusieurs certificats ont la même valeur, une exception est levée, car il n’existe aucun moyen de distinguer le certificat requis. Vous pouvez atténuer ce problème en définissant x509FindType sur FindByThumbprint. Le champ d’empreinte numérique contient une valeur unique qui peut être utilisée pour rechercher un certificat spécifique dans un magasin. Toutefois, cela présente son propre inconvénient : si le certificat est révoqué ou renouvelé, la SetCertificate méthode échoue car l’empreinte numérique est également supprimée. Ou, si le certificat n’est plus valide, l’authentification échoue. Pour atténuer cela, il faut régler le paramètre x590FindType sur FindByIssuerName et spécifier le nom de l’émetteur. Si aucun émetteur particulier n’est requis, vous pouvez également définir l’une des autres X509FindType valeurs d’énumération, telles que FindByTimeValid.
Certificats dans la configuration
Vous pouvez également définir des certificats à l’aide de la configuration. Si vous créez un service, des identifiants, y compris des certificats, sont spécifiés dans <serviceBehaviors>. Lorsque vous programmez un client, les certificats sont spécifiés sous endpointBehaviors<>.
Mapper un certificat à un compte d’utilisateur
Une fonctionnalité d’IIS et d’Active Directory est la possibilité de mapper un certificat à un compte d’utilisateur Windows. Pour plus d’informations sur la fonctionnalité, consultez Mapper des certificats à des comptes d’utilisateur.
Pour plus d’informations sur l’utilisation du mappage Active Directory, consultez Mappage des certificats clients à l’aide du mappage du service d’annuaire.
Avec cette fonctionnalité activée, vous pouvez définir la MapClientCertificateToWindowsAccount propriété de la X509ClientCertificateAuthentication classe sur true. Dans la configuration, vous pouvez définir l’attribut mapClientCertificateToWindowsAccount de l’élément <d’authentification> sur true, comme indiqué dans le code suivant.
<serviceBehaviors>
<behavior name="MappingBehavior">
<serviceCredentials>
<clientCertificate>
<authentication certificateValidationMode="None" mapClientCertificateToWindowsAccount="true" />
</clientCertificate>
</serviceCredentials>
</behavior>
</serviceBehaviors>
Le mappage d’un certificat X.509 au jeton qui représente un compte d’utilisateur Windows est considéré comme une élévation de privilèges, car, une fois mappé, le jeton Windows peut être utilisé pour accéder aux ressources protégées. Par conséquent, la stratégie de domaine nécessite que le certificat X.509 soit conforme à sa stratégie avant le mappage. Le package de sécurité SChannel applique cette exigence.
Lors de l’utilisation de .NET Framework 3.5 ou versions ultérieures, WCF garantit que le certificat est conforme à la stratégie de domaine avant qu’il ne soit mappé à un compte Windows.
Dans la première version de WCF, le mappage est effectué sans consulter la stratégie de domaine. Par conséquent, il est possible que les anciennes applications utilisées pour fonctionner lors de l’exécution sous la première version échouent si le mappage est activé et que le certificat X.509 ne répond pas à la stratégie de domaine.