Utilisation des certificats

Dans le cadre de la programmation de la sécurité Windows Communication Foundation (WCF), les certificats numériques X.509 sont fréquemment utilisés pour authentifier les clients et les serveurs, coder les messages et signer numériquement ces derniers. Cette rubrique contient des explications sur les fonctionnalités de certificat ainsi que des instructions permettant de les utiliser dans WCF. Elle renvoie également à d'autres rubriques qui abordent plus en détail ces différents concepts ou contiennent des instructions permettant d'effectuer des tâches courantes à l'aide de WCF et des certificats.

En bref, les certificats numériques font partie de l'infrastructure à clé publique (PKI). Cette infrastructure est en fait un système qui se compose de certificats numériques, d'autorités de certification ainsi que d'autorités d'immatriculation, lesquelles vérifient et authentifient les informations d'identification des parties impliquées dans une transaction électronique en utilisant un chiffrement à clé publique. Les autorités de certification émettent des certificats contenant un ensemble de champs qui définissent notamment les informations suivantes : sujet (entité pour laquelle le certificat est émis), dates de validité, émetteur et clé publique. Dans WCF, chacune de ces propriétés est traitée comme une revendication Claim, chaque revendication étant divisée en deux types supplémentaires : identité et droits. Pour plus d'informations, consultez Gestion des revendications et autorisation avec le modèle d'identité. Pour plus d'informations sur l'implémentation d'une infrastructure PKI, consultez les Meilleures pratiques pour implémenter une infrastructure à clé publique Microsoft Windows Server 2003 (page pouvant être en anglais).

La principale fonction d'un certificat consiste à authentifier l'identité du sujet auprès des autres parties. Les certificats contiennent également la clé publique du sujet, celui-ci conservant sa clé privée. Les clés publiques peuvent être utilisées par toutes les parties prenantes pour chiffrer un message. Cependant, les deux clés sont requises pour déchiffrer un message. Par conséquent, seuls les détenteurs de la clé privée peuvent déchiffrer le message auquel elle se rapporte. Les clés publiques peuvent être utilisées pour chiffrer les messages envoyés au propriétaire du certificat. Cependant, seul le propriétaire de la clé privée pourra déchiffrer ces messages.

Les certificats doivent être émis par une autorité de certification, c'est-à-dire le plus souvent par une partie tierce. Les domaines Windows intègrent une autorité de certification pouvant être utilisée afin d'émettre des certificats pour les ordinateurs figurant sur ces domaines.

Pour plus d'informations sur les certificats, consultez Certificats (page pouvant être en anglais).

Affichage des 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 Comment : afficher des certificats à l'aide du composant logiciel enfichable MMC. Pour plus d'informations sur les modalités d'utilisation de cet outil, consultez Vue d'ensemble Httpcfg (page pouvant être en anglais).

Magasin de certificats

Les certificats sont stockés dans des magasins. Deux emplacements de magasin majeurs existent et 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. Dans le cas contraire, vous pouvez uniquement afficher le magasin de l'utilisateur en cours.

• Magasin de l'ordinateur local. Ce magasin contient les certificats utilisés par les processus informatiques tels que ASP.NET. Utilisez cet emplacement pour y stocker les certificats qui authentifient les serveurs auprès des clients.
• Magasin de l'utilisateur en cours. Les applications interactives stockent en principe les certificats à cet emplacement pour l'utilisateur en train d'utiliser l'ordinateur. Si vous créer des applications clientes, c'est également l'emplacement que vous utiliserez en principe pour stocker les certificats qui authentifient les utilisateurs auprès des services.

Ces deux magasins sont divisés en sous-magasins. Les plus importants d'entre eux lors de la programmation avec WCF sont notamment :

• Autorités de certification racine approuvées. Vous pouvez utiliser les certificats stockés dans ce magasin pour créer une chaîne de certificats, dont l'origine remontera à un certificat d'autorité de certification figurant dans ce magasin.

  Remarque :

  L'ordinateur local approuve de manière implicite tous les certificats figurant dans ce magasin, même si ces certificats n'émanent pas d'une autorité de certification tierce approuvée. C'est pourquoi ne stockez pas de certificats dans ce magasin, à moins qu'il ne s'agisse de certificats publiés par des émetteurs dans lesquels vous entièrement confiance et à moins d'avoir pleinement conscience des conséquences d'un tel stockage.

• Personnel. Ce magasin est utilisé pour stocker les certificats associés à l'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. Les certificats stockés dans ce magasin peuvent également s'être auto-publiés et avoir été approuvés par une application.

Pour plus d'informations sur les magasins de certificats, consultez Magasins de certificats (page pouvant être en anglais).

Sélection d'un magasin

La sélection d'un magasin pour y stocker un certificat dépend de la manière dont un client ou service s'exécutent ainsi que de l'instant où ils s'exécutent. Les règles générales suivantes s'appliquent :

• Si le service correspond à un service Windows et qu'il s'exécute en mode « serveur » sans interface utilisateur sous un compte de service réseau, utilisez le magasin de l'ordinateur local. Remarque : des droits administrateur sont requis pour pouvoir stocker les certificats dans le magasin de l'ordinateur local.
• Si le service ou le client est intégré à une application qui s'exécute sous un compte d'utilisateur, utilisez alors le magasin de l'utilisateur en cours.

Accès aux magasins

Les magasins sont protégés par des listes de contrôle d'accès à l'instar des dossiers figurant sur un ordinateur. Lors de la création d'un service hébergé par les services Internet (IIS), le processus ASP.NET s'exécute sous le compte ASP.NET. Ce compte doit avoir accès au magasin contenant les certificats utilisés par le service considéré. Chacun des principaux magasins est protégé par une liste d'accès par défaut, mais cette liste peut être modifiée. Si vous créez un rôle distinct pour l'accès à un magasin donné, vous devez accorder à ce rôle des droits d'accès. Pour connaître les modalités permettant de modifier la liste d'accès à l'aide de l'outil WinHttpCertConfig.exe, consultez Comment : créer des certificats temporaires à utiliser au cours du développement. Pour plus d'informations sur l'utilisation des certificats client avec les services IIS, consultez Modalités d'appel d'un service Web à l'aide d'un certificat client dans le cadre d'une authentification d'application ASP.NET (page pouvant être en anglais).

Chaîne d'approbation et autorités de certification

Les certificats numériques sont utilisés pour authentifier les entités à l'aide d'une chaîne d'approbation. Cette chaîne se forme en partant du haut de la hiérarchie pour aller jusqu'au bas, une autorité racine figurant en haut de la hiérarchie. Vous pouvez afficher toutes chaînes de certificat à l'aide de l'outil enfichable MMC. Il vous suffit de cliquer sur le certificat de votre choix, puis de sélectionner l'onglet Chemin de certificat. Le certificat d'autorité racine figurant en haut de la chaîne de certificats est auto-publié. Cela signifie que l'émetteur et l'entité pour laquelle le certificat est publié forment une seule et même entité. Pour plus d'informations sur l'importation des chaînes de certificats pour une autorité de certificat, consultez Comment : spécifier la chaîne de certificats d'autorité de certification utilisée pour vérifier des signatures (WCF).

Remarque :
Le statut d'autorité racine approuvée peut être attribué à tout émetteur. Il suffit pour ce faire de placer le certificat de cet émetteur dans le magasin Autorités de certification racine approuvées.

Désactivation des chaînes d'approbation

Lorsque vous créez un nouveau service, il est possible que vous utilisiez un certificat non émis par un certificat racine approuvé ou que le certificat émetteur lui-même ne figure pas dans le magasin Autorités de certification racine approuvées. Vous pouvez désactiver le mécanisme assurant la vérification de la chaîne d'approbation d'un certificat uniquement à des fins de développement. Pour ce faire, affectez à la propriété CertificateValidationMode PeerTrust ou PeerOrChainTrust. L'un et l'autre des modes ci-dessus permettent de spécifier que le certificat doit s'auto-publier (approbation homologue) ou faire partie d'une chaîne d'approbation. 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 :

• <authentication> of <serviceCertificate> Element
• <peerAuthentication> Element
• <messageSenderAuthentication> element

Authentification personnalisée

La propriété CertificateValidationMode vous permet également de personnaliser les modalités d'authentification des certificats. Par défaut, le niveau a la valeur ChainTrust. Pour utiliser la valeur Custom, vous devez également affecter à l'attribut CustomCertificateValidatorType l'assembly et le type utilisés pour valider le certificat. Pour créer un validateur personnalisé, vous devez hériter de la classe X509CertificateValidator abstraite.

Lorsque vous créez un authentificateur personnalisé, la méthode la plus importante à substituer correspond à la méthode Validate. Pour obtenir un exemple d'authentification personnalisée, consultez X.509 Certificate Validator. Pour plus d'informations, consultez Informations d'identification personnalisées et validation d'informations d'identification.

Utilisation de l'outil Makecert.exe pour construire une chaîne de certificat

L'outil de création de certificat (Makecert.exe) crée des certificats X.509 ainsi que des paires de clés publique/privée. Vous pouvez enregistre les clés privées sur votre disque, puis les utiliser pour émettre et signer de nouveaux certificats, instaurant ainsi une hiérarchie de certificats sous forme de chaîne. Cet outil est conçu uniquement pour vous assister lors du développement des services et ne doit en aucun cas être utilisé pour créer des certificats devant être effectivement déployés. Lorsque vous développez un service WCF, effectuez les étapes suivantes afin de construire une chaîne d'approbation à l'aide de l'outil Makecert.exe.

Pour construire une chaîne d'approbation à l'aide de l'outil Makecert.exe

1. Créez un certificat d'autorité racine temporaire (auto-signé) à l'aide de l'outil MakeCert.exe. Enregistrez la clé privée sur le disque.

2. Utilisez ce nouveau certificat pour émettre un autre certificat contenant la clé publique.

3. Importez le certificat d'autorité racine dans le magasin Autorités de certification racine approuvées.

4. Pour des instructions pas à pas, consultez Comment : créer des certificats temporaires à utiliser au cours du développement.

Quel certificat utiliser ?

Parmi les questions les plus fréquemment posées concernant les certificats figurent notamment : quel certificat choisir et pourquoi ? La réponse à ces questions n'est pas la même que vous programmiez un service ou un client. Les informations ci-dessous contiennent des directives générales et n'offrent pas une réponse exhaustive à ces questions.

Certificats de service

La principale tâche des certificats de service consiste à authentifier le serveur auprès des clients. Lorsqu'un client authentifie un serveur, il compare d'abord la valeur du champ Objet à celle de l'URI (Uniform Resource Identifier, URI) utilisé pour contacter le service : leurs noms DNS respectifs doivent être identiques. Par exemple, si l'URI du service est « https://www.contoso.com/endpoint/ », alors le champ Sujet doit contenir la valeur « www.contoso.com ».

Remarque : ce champ peut contenir plusieurs valeurs, chacune préfixée par une initialisation spécifiant la valeur. Dans la plupart des cas, cette initialisation correspond à « CN », abréviation de « common name », en français « nom courant », par exemple, « CN = www.contoso.com ». Le champ Sujet peut également être vierge auquel cas le champ Autre nom du sujet peut contenir la valeur Nom DNS.

Remarque : la valeur du champ Rôles prévus du certificat doit contenir une valeur appropriée telle que « Authentification de serveur » ou « Authentification de client ».

Certificats de client

Les certificats de client ne sont en principe pas publiés par une autorité de certification tierce. Le magasin personnel de l'utilisateur en cours contient en principe des certificats qui y sont stockés par l'autorité racine, le rôle prévu étant « Authentification de client ». Le client peut utiliser ce genre de certificat lorsque l'authentification mutuelle requise.

Révocations en ligne et hors ligne

Validité des certificats

Chaque certificat est valable pendant une période de temps donnée appelée période de validité. Cette période est définie par les champs Valide à partir du et Valide jusqu'au d'un certificat X.509. Au cours de l'authentification, le certificat est contrôlé afin de vérifier que sa période de validité n'est pas échue.

Liste de révocation des certificats

L'autorité de certification peut à tout moment révoquer un certificat tant que sa période de validité n'est pas échue. Une telle révocation peut avoir lieu pour plusieurs raisons, notamment lorsque la clé privée du certificat est compromise.

En cas de révocation, toutes les chaînes descendant du certificat révoqué ne sont plus considérées comme valables et ne sont plus 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. Cette liste peut être consultée à l'aide des révocations en ligne ou hors connexion en affectant à la propriété RevocationMode ou DefaultRevocationMode de l'une des classes suivantes 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 <authentication> of <clientCertificate> Element (de la section serviceBehaviors section) et de <authentication> of <clientCertificate> Element (de la section endpointBehaviors section).

Méthode SetCertificate

Dans WCF, vous devez fréquemment spécifier le certificat ou l'ensemble de certificats que les services ou clients doivent utiliser pour authentifier, chiffrer ou signer numériquement les messages. Pour ce faire, il vous suffit de rédiger un programme à l'aide de la méthode SetCertificate des diverses classes représentant les certificats X.509. Les classes suivantes utilisent la méthode SetCertificate pour spécifier un certificat.

La méthode SetCertificate désigne un emplacement de magasin et y stocke un type « trouver » (paramètre x509FindType) qui spécifie un champ de certificat et la valeur de ce champ. Par exemple, le code suivant crée une instance ServiceHost et définit le certificat de service utilisé pour authentifier le service auprès des clients à l'aide de la méthode SetCertificate .

Plusieurs certificats ayant la même valeur

Un magasin peut contenir plusieurs certificats ayant le même nom de sujet. Cela signifie que si vous spécifiez que x509FindType doit correspondre à FindBySubjectName ou FindBySubjectDistinguishedName et que plusieurs certificats ont la même valeur, une exception sera levée, aucun moyen ne permettant de distinguer quel certificat doit être utilisé. Vous pouvez résoudre ce problème en affectant à x509FindType la valeur FindByThumbprint. Le champ d'empreinte contient une valeur unique qui peut être utilisée afin de trouver un certificat particulier figurant dans un magasin. Cette solution présente cependant un inconvénient : si le certificat a été révoqué ou renouvelé, la méthode SetCertificate échouera, l'empreinte du certificat n'existant plus. Si le certificat n'est plus valable, l'authentification échouera également. Pour résoudre ce problème, vous pouvez affecter au paramètre x590FindType la valeur FindByIssuerName, puis spécifier le nom de l'émetteur. Si aucun émetteur n'est requis, vous pouvez également lui affecter l'une des autres valeurs d'énumération X509FindType 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, les informations d'identification de même que les certificats, sont spécifiés sous serviceBehaviors section. Si vous programmez un client, les certificats sont spécifiés sous endpointBehaviors section.

Mappage d'un certificat à un compte utilisateur

Les services IIS et Active Directory proposent une fonctionnalité qui permet de mapper un certificat à un compte utilisateur Windows. Pour plus d'informations sur la fonctionnalité, consultez Mappage des certificats aux comptes utilisateur (page pouvant être en anglais).

Pour plus d'informations sur l'utilisation du mappage Active Directory, consultez Mappage des certificats client à l'aide du mappage du service d'annuaire (page pouvant être en anglais).

Lorsque cette fonctionnalité est activée, vous pouvez affecter à la propriété MapClientCertificateToWindowsAccount de la classe X509ClientCertificateAuthentication la valeur true. Dans la configuration, vous pouvez affecter à l'attribut mapClientCertificateToWindowsAccount de l'élément <authentication> la valeur true, comme illustré 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 représentant le compte utilisateur Windows est considéré comme un rehaussement des droits de ce compte. Une fois mappé, le jeton Windows peut en effet être utilisé pour accéder à des ressources protégées. C'est pourquoi la stratégie de domaine spécifie que le certificat X.509 doit être conforme aux règles qu'elle contient avant de pouvoir être mappé. Le package de sécurité SChannel intègre cette spécification.

Lorsque vous utilisez le .NET Framework version 3.5 ou version ultérieure, WCF s'assure que le certificat se conforme à la stratégie de domaine avant d'être mappé à un compte Windows.

Dans la première version de WCF, le mappage du certificat est effectué sans prendre en compte la stratégie de domaine. Par conséquent, avec d'anciennes applications habituées à s'exécuter sous la première version, il est possible que le mappage échoue si la fonctionnalité de mappage est activée et si le certificat X.509 n'est pas conforme à la stratégie de domaine.

Voir aussi

Référence

System.ServiceModel.Channels
System.ServiceModel.Security
System.ServiceModel
X509FindType

Autres ressources

Sécurisation des services et des clients