Utilisation des certificats
Pour programmer la sécurité relative à WCF (Windows Communication Foundation), les certificats numériques X.509 sont couramment utilisés pour authentifier les clients et les serveurs, ainsi que pour chiffrer et signer numériquement les messages. Cette rubrique décrit brièvement les fonctionnalités des certificats numériques X.509 et leur utilisation dans WCF. Elle inclut également des liens vers les rubriques qui présentent ces concepts de manière plus détaillée, ou qui montrent comment effectuer les tâches courantes à l’aide de WCF et des certificats.
En bref, un certificat numérique fait partie d’une infrastructure PKI (infrastructure à clé publique). Il s’agit d’un système composé de certificats numériques, d’autorités de certification et d’autorités d’inscription qui permettent de vérifier et d’authentifier la validité de chaque partie impliquée dans une transaction électronique grâce à l’utilisation d’un chiffrement à clé publique. Une autorité de certification émet des certificats qui comportent un ensemble de champs contenant des données telles que le sujet (entité pour laquelle le certificat est émis), les dates de validité (période de validité du certificat), l’émetteur (entité qui a émis le certificat) et la clé publique. Dans WCF, chacune de ces propriétés est traitée en tant que 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 la notion d’autorisation dans WCF, consultez Gestion des revendications et autorisation avec le modèle d’identité. Pour plus d’informations sur l’implémentation d’une infrastructure de clé publique (PKI), consultez PKI d’entreprise avec les services de certificats Active Directory Windows Server 2012 R2.
La principale fonction d’un certificat est d’authentifier l’identité du propriétaire du certificat auprès des autres parties. Un certificat contient la clé publique du propriétaire, alors que le propriétaire conserve la clé privée. 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, qui est souvent un émetteur de certificats tiers. 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.
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 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 la machine locale. Ce magasin contient les certificats utilisés par les processus informatiques tels qu’ASP.NET. Utilisez cet emplacement pour y stocker les certificats qui authentifient les serveurs auprès des clients.
Magasin de l’utilisateur actuel. 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 pour 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.
Important
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.
Sélectionner 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 WCF est hébergé dans un service Windows, utilisez le magasin machine locale. 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 une application qui s’exécute sous un compte d’utilisateur, utilisez le magasin utilisateur actuel.
Accéder 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 Internet Information Services (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 apprendre à modifier la liste d’accès à l’aide de l’outil WinHttpCertConfig.exe, consultez Guide pratique pour créer des certificats temporaires à utiliser au cours du développement.
Chaîne d'approbation et autorités de certification
Les certificats sont créés selone une hiérarchie où chaque certificat individuel est lié à l'autorité de certification qui l'a émis. Ce lien renvoie au 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 se répète jusqu'à ce que le certificat de l'autorité de certification racine soit atteint. Le certificat de l'autorité de certification racine est approuvé de manière inhérente.
Les certificats numériques sont utilisés pour authentifier une entité en s’appuyant sur cette hiérarchie, également appelée chaîne de confiance. Vous pouvez afficher la chaîne de du certificat de votre choix à l’aide du composant logiciel enfichable MMC en double-cliquant sur le certificat, puis en cliquant sur l’onglet Chemin de 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.
Notes
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ésactiver la chaîne 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é CertificateValidationModePeerTrust 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 :
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 Validateur de certificat X.509. Pour plus d’informations, consultez Informations d’identification personnalisées et validation d’informations d’identification.
Utilisation de l’a cmdlet PowerShell New-SelfSignedCertificate pour générer une chaîne de certificats
L’applet de commande PowerShell New-SelfSignedCertificate crée des certificats X.509 ainsi que des paires clé publique/clé 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. L’applet de commande est destinée à être utilisée uniquement pour vous assister lors du développement de services et ne doit en aucun cas être utilisée pour créer des certificats devant être effectivement déployés. Quand vous développez un service WCF, effectuez les étapes suivantes pour générer 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 ce nouveau certificat pour émettre un autre certificat contenant 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 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. Quand un client authentifie un serveur, il compare d’abord la valeur du champ Sujet à celle de l’URI (Uniform Resource Identifier) utilisé pour contacter le service : les DNS respectifs doivent correspondre. Par exemple, si l’URI du service est http://www.contoso.com/endpoint/, le champ Subject doit également 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 » (« nom courant »), par exemple CN = www.contoso.com. Il est également possible que le champ Sujet soit vide. Dans ce cas, le champ Autre nom de l’objet peut contenir la valeur Nom DNS.
Notez également que le champ Rôles prévus du certificat doit contenir une valeur appropriée, par exemple « Authentification du serveur » ou « Authentification du client ».
Certificats clients
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 un certificat lorsque l’authentification mutuelle est requise.
Révocations en ligne et hors ligne
Validité des certificats
Chaque certificat est valide uniquement pour 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 de certificat
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 CRL (liste de révocation de certificats) horodatée et daté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 l’élément <authentication> (de <serviceBehaviors>) et de l’élément <authentication> (de <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, 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 de ServiceHost et définit le certificat de service utilisé pour authentifier le service auprès des clients à l’aide de la méthode SetCertificate.
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 ayant la même valeur
Un magasin peut contenir plusieurs certificats ayant le même nom de sujet. En d’autres termes, si vous spécifiez que x509FindType a la valeur FindBySubjectName ou FindBySubjectDistinguishedName, et si plusieurs certificats ont la même valeur, une exception est levée, car il est impossible de distinguer le certificat nécessaire. 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, notamment les certificats, sont spécifiées sous <serviceBehaviors>. Quand vous programmez un client, les certificats sont spécifiés sous <endpointBehaviors>.
Mapper un certificat à un compte d’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 Mapper des certificats aux comptes d’utilisateurs.
Pour plus d’informations sur l’utilisation du mappage Active Directory, consultez Mappage des certificats clients à l’aide du mappage du service d’annuaire.
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 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 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 applique cette exigence.
Quand vous utilisez .NET Framework 3.5 ou une version ultérieure, WCF vérifie que le certificat est conforme à la stratégie de domaine avant qu’il soit mappé à un compte Windows.
Dans la première version de WCF, le mappage est effectué sans prise en compte de 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.