Nouveautés des services de certificats sous Windows Server

 

Date de publication : septembre 2016

S’applique à : Windows Server 2012 R2, Windows Server 2012

Cette rubrique décrit les nouveautés et les modifications apportées à la fonctionnalité Services de certificats Active Directory (AD CS) sous R2 Windows Server 2012 et Windows Server 2012. Les services de certificats Active Directory (AD CS) fournissent des services personnalisables pour l’émission et la gestion de certificats pour infrastructure à clé publique (PKI) qui sont utilisés dans les systèmes de sécurité logiciels employant des technologies de clé publique.

Dans cette rubrique :

Sous R2 Windows Server 2012, les services de certificats offrent une meilleure prise en charge dans les domaines suivants :

Fonctionnalité/fonctionNouveauté ou améliorationDescription
Prise en charge du module de stratégie pour le service d’inscription de périphérique réseauNouveauL’utilisation d’un module de stratégie avec le service d’inscription de périphérique réseau assure une meilleure sécurité afin que les utilisateurs et les périphériques puissent demander des certificats à partir d’Internet.
Attestation de clé TPMNouveauL’attestation de la clé de module de plateforme sécurisée (TPM) permet à l’autorité de certification de vérifier que la clé privée est protégée par un module de plateforme sécurisée basé sur le matériel.
Windows PowerShell pour les services de certificatsNouveauDe nouvelles applets de commande Windows PowerShell sont disponibles pour la sauvegarde et la restauration.

Prise en charge du module de stratégie pour le service d’inscription de périphérique réseau

Le service de rôle AD CS, service d’inscription de périphérique réseau, est conçu pour des réseaux sécurisés et des administrateurs approuvés. L’inscription permet ainsi d’utiliser un mot de passe unique ou même aucun mot de passe pour demander plusieurs certificats. En outre, aucune authentification n’est demandée pour la valeur de nom d’objet fournie. Toutefois, R2 Windows Server 2012 prend en charge un module de stratégie pour le service d’inscription de périphérique réseau, qui fournit une authentification supplémentaire qui facilite l’exécution de ce service de rôle dans un réseau de périmètre. Cette configuration prend en charge le scénario Apportez votre propre appareil (BYOD) grâce auquel les périphériques mobiles, tels que ceux qui exécutent iOS et Android, et les ordinateurs qui ne sont pas membres du domaine peuvent désormais utiliser le service d’inscription de périphérique réseau pour demander des certificats utilisateur et ordinateur à partir d’Internet. Ce système est parfois appelé inscription OTA (over-the-air).

R2 Windows Server 2012 n’est pas fourni avec un module de stratégie. Vous devez l’installer séparément, à partir d’un fournisseur de logiciels qui propose un module de stratégie, ou vous devez écrire votre propre module de stratégie. Si vous installez un module de stratégie d’un fournisseur de logiciels, il s’agit généralement d’une société qui fournit la gestion des périphériques mobiles. Par exemple, System Center 2012 R2 Configuration Manager fournit un module de stratégie requis pour le déploiement des profils de certificat.

Pour plus d'informations, voir les ressources suivantes :

Attestation de clé TPM

L’attestation de la clé de module de plateforme sécurisée (TPM) permet à l’autorité de certification de vérifier que la clé privée est protégée par un module de plateforme sécurisée basé sur le matériel et que ce module est approuvé par l’autorité de certification. Cette fonctionnalité empêche l’exportation du certificat vers un périphérique non autorisé et peut lier l’identité de l’utilisateur au périphérique.

Tous les modules TPM possèdent une paire de clés de type EK (Endorsement Key) qui est unique pour chaque module. Dans certains cas, les modules TPM possèdent un certificat de paire de clés de type EK (Endorsement Key) qui les associe à l’AC émettrice du fabricant. Tous les modules de plateforme sécurisée ne prennent pas en charge l’attestation, mais s’ils le font, vous pouvez choisir de valider l’attestation de la clé à l’aide de la paire de clés ou à l’aide d’un certificat de la paire de clés de type EK.

Pour utiliser l’attestation de clé TPM, le système d’exploitation client doit être Windows 8.1 ou R2 Windows Server 2012. Pour configurer l’attestation de clé du module de plateforme sécurisée, utilisez un modèle de certificat version 4 avec une autorité de certification d’entreprise et configurez les paramètres de l’onglet Attestation de clé. Ne sélectionnez pas l’option Ne pas stocker de certificat et de demandes dans la base de données de l’autorité de certification sous l’onglet Serveur des propriétés du modèle de certificat, car cette configuration n’est pas prise en charge avec l’attestation de clé du module de plateforme sécurisée. En outre, les autorités de certification autonomes et l’inscription par le web ne prennent pas en charge l’attestation de clé du module de plateforme sécurisée.

Lorsque vous configurez l’attestation de clé TPM, vous pouvez choisir d’augmenter les niveaux d’assurance en spécifiant comment valider la paire de clés qui est intégrée dans le module de plateforme sécurisée par le fabricant :

  • Informations d’identification de l’utilisateur. Aucune autre configuration n’est requise sur l’autorité de certification.

  • Certificat de la paire de clés de type EK (Endorsement Key). Vous devez ajouter les certificats racines et de l’AC émettrice pour le module de plateforme sécurisée aux magasins de nouveaux certificats sur l’autorité de certification. Les magasins de nouveaux certificats sont EKCA pour le magasin intermédiaire et EKRROT pour le magasin racine.

  • Paire de clés de type EK (Endorsement Key). Vous devez ajouter chaque paire de clés des modules de plateforme sécurisée à une liste approuvée (liste EKPUB).

System_CAPS_ICON_tip.jpg Astuce


Si les paramètres de l’onglet Attestation de clé ne sont pas disponibles, vérifiez les paramètres suivants :

  • Sous l’onglet Compatibilité : l’Autorité de certification est définie sur Windows Server 2012 R2 et le Destinataire du certificat est défini sur Windows 8.1 / Windows Server 2012 R2.
  • Sous l’onglet Traitement de la demande : les cases Autoriser l’exportation de la clé privée et Archiver la clé privée de chiffrement du sujet ne doivent pas être cochées.
  • Sous l’onglet Chiffrement : la Catégorie de fournisseur est définie sur Fournisseur de stockage de clés et le Nom d’algorithme est défini sur RSA. En outre, l’option La demande doit utiliser l’un des fournisseurs suivants doit est définie sur Fournisseur de chiffrement de plateforme Microsoft.

Pour plus d'informations, voir les ressources suivantes :

Windows PowerShell pour les services de certificats

De nouvelles applets de commande Windows PowerShell sont disponibles sous R2 Windows Server 2012. Vous pouvez utiliser ces applets de commande pour sauvegarder et restaurer une base de données d’autorité de certification.

Nom de l’applet de commandeNouveauté ou améliorationDescription
Backup-CARoleServiceNouveauSauvegarde la base de données d’autorité de certification.
Restore-CARoleServiceNouveauRestaure la base de données d’autorité de certification.

Pour plus d’informations sur ces applets de commande, consultez les pages Backup-CARoleService et Restore-CARoleService.

Pour utiliser ces applets de commande dans un scénario de migration, consultez les sections suivantes de la page Guide de migration des services de certificats Active Directory pour Windows Server 2012 R2 :

Sous Windows Server 2012, les services de certificats Active Directory offrent une meilleure prise en charge dans les domaines suivants :

Intégration au Gestionnaire de serveur

Le Gestionnaire de serveur fournit une interface utilisateur graphique centralisée pour l’installation et la gestion du rôle serveur AD CS et des six services de rôle.

Quels avantages cette modification procure-t-elle ?

Le rôle serveur AD CS et les services associés sont intégrés au Gestionnaire de serveur, ce qui vous permet d’installer le service de rôle AD CS à partir du menu Gérer via Ajouter des rôles et des fonctionnalités. Une fois que le rôle serveur est ajouté, AD CS s’affiche dans le tableau de bord du Gestionnaire de serveur comme l’un des rôles pouvant être gérés. Vous disposez ainsi d’un emplacement central à partir duquel vous pouvez déployer et gérer AD CS et ses services de rôle. En outre, le nouveau Gestionnaire de serveur vous permet de gérer plusieurs serveurs à partir d’un emplacement et vous pouvez voir les services de rôle AD CS installés sur chaque serveur, passer en revue les événements associés et effectuer des tâches de gestion sur chaque serveur. Pour plus d’informations sur le fonctionnement du nouveau Gestionnaire de serveur, consultez la page Gérer plusieurs serveurs distants avec le Gestionnaire de serveur.

En quoi le fonctionnement est-il différent ?

Pour ajouter le rôle de serveur AD CS, vous pouvez utiliser le lien Ajouter des rôles et des fonctionnalités dans le menu Gérer du Gestionnaire de serveur. Le flux d’installation des services AD CS est semblable à celui de la version antérieure, sauf en ce qui concerne la division du processus d’installation binaire et du processus de configuration. Auparavant, l’installation et la configuration étaient assurées via un Assistant unique. Dans le nouveau mode d’installation, vous installez d’abord les fichiers binaires, puis vous pouvez lancer l’Assistant de configuration des services AD CS pour configurer les services de rôle pour lesquels les fichiers binaires sont déjà installés. Pour supprimer le rôle de serveur AD CS, vous pouvez utiliser le lien Ajouter des rôles et fonctionnalités dans le menu Gérer.

Fonctionnalités de gestion et de déploiement sous Windows PowerShell

Tous les services de rôle AD CS peuvent être configurés ou leurs configurations peuvent être supprimées à l’aide des applets de commande Windows PowerShell de déploiement des services AD CS. Ces nouvelles applets de commande de déploiement sont décrites à la page Vue d’ensemble des applets de commande de déploiement des services AD CS. L’applet de commande d’administration des services AD CS vous permet de gérer le service de rôle Autorité de certification. Les nouvelles applets de commande d’administration sont décrites à la page Vue d’ensemble des applets de commande d’administration des services AD CS.

Quels avantages cette modification procure-t-elle ?

Vous pouvez utiliser Windows PowerShell pour créer le script de déploiement d’un service de rôle AD CS et gérer le service de rôle Autorité de certification.

En quoi le fonctionnement est-il différent ?

Vous pouvez utiliser le Gestionnaire de serveur ou les applets de commande Windows PowerShell pour déployer les services de rôle AD CS.

Tous les services de rôle AD CS exécutés sur n’importe quelle version

Vous pouvez installer tous les services de rôle AD CS sous Windows Server 2012 et R2 Windows Server 2012, quelle qu’en soit la version.

Quels avantages cette modification procure-t-elle ?

Contrairement aux versions précédentes, vous pouvez installer les rôles AD CS sur n’importe quelle version de Windows Server 2012 ou R2 Windows Server 2012.

En quoi le fonctionnement est-il différent ?

Sous Windows Server 2008 R2, les différents services de rôle (appelés auparavant composants) nécessitaient différentes versions de système d’exploitation, comme décrit à la page Vue d’ensemble des services de certificats Active Directory. Sous Windows Server 2012 ou R2 Windows Server 2012, les six services de rôle fonctionnent normalement, quelle que soit la version de Windows Server 2012 ou R2 Windows Server 2012. La seule différence tient au fait que les services AD CS (avec les six services de rôle) peuvent être installés sur n’importe quelle version de Windows Server 2012 ou R2 Windows Server 2012.

Tous les services de rôle des services AD CS peuvent être exécutés sur une installation minimale.

Les six services de rôle AD CS de Windows Server 2012 et R2 Windows Server 2012 peuvent être installés et exécutés à l’aide de Server Core ou des options d’installation d’interface minimale du serveur.

Quels avantages cette modification procure-t-elle ?

Contrairement aux versions précédentes, vous pouvez désormais exécuter tous les services de rôle AD CS sur Server Core ou sur les options d’installation d’interface minimale du serveur sous Windows Server 2012 ou R2 Windows Server 2012.

En quoi le fonctionnement est-il différent ?

Vous pouvez à présent déployer facilement les services de rôle AD CS à l’aide du Gestionnaire de serveur ou des applets de commande Windows PowerShell en local sur l’ordinateur ou à distance via le réseau. De plus, Windows Server 2012 ou R2 Windows Server 2012 propose plusieurs options d’installation qui permettent même une installation au moyen d’une interface graphique utilisateur avec, par la suite, la possibilité de basculer vers une installation Server Core ou d’interface serveur minimale. Pour plus d’informations sur les options d’installation, consultez la page Options d’installation de Windows Server.

Prise en charge du renouvellement basé sur les clés

Les services Web d’inscription de certificats est une fonctionnalité qui a été ajoutée à Windows 7 et Windows Server 2008 R2. Cette fonctionnalité permet l’émission de demandes de certificats en ligne depuis des domaines de services de domaine Active Directory (AD DS) non approuvés ou même depuis des ordinateurs qui ne sont pas membres d’un domaine. Sous Windows Server 2012 et R2 Windows Server 2012, les services AD CS reposent sur les services Web Inscription de certificats en offrant en outre la possibilité de renouveler automatiquement les certificats des ordinateurs qui font partie des domaines AD DS non approuvés ou qui n’appartiennent à aucun domaine.

Quels avantages cette modification procure-t-elle ?

Les administrateurs n’ont plus besoin de renouveler manuellement les certificats pour les ordinateurs qui sont membres de groupes de travail ou peut-être d’une forêt ou d’un domaine AD DS différent.

En quoi le fonctionnement est-il différent ?

Les services Web d’inscription de certificats continuent de fonctionner comme avant mais, désormais, les ordinateurs qui se trouvent à l’extérieur du domaine peuvent renouveler leurs certificats en utilisant leur certificat existant pour authentification.

Pour plus d’informations, consultez la page Renouvellement basé sur les clés. Il existe également deux guides de laboratoire de test qui illustrent l’utilisation de ce renouvellement basé sur les clés :

  1. Guide de laboratoire de test : description du renouvellement basé sur les clés

  2. Mini-module de guide de laboratoire de test : inscription de certificats inter-forêts à l’aide des services Web Inscription de certificats

Compatibilité du modèle de certificat

Sous Windows Server 2012 et R2 Windows Server 2012, les services AD CS contiennent des modèles de certificat de version 4. Ces modèles comportent plusieurs différences par rapport aux versions des modèles antérieures. Les modèles de certificats de version 4 :

  • prennent en charge les fournisseurs de services de chiffrement (CSP) et les fournisseurs de services de clés (KSP) ;

  • peuvent être paramétrés pour demander un renouvellement avec la même clé ;

  • ne peuvent être utilisés que sous Windows 8, Windows 8.1, Windows Server 2012 et R2 Windows Server 2012 ;

  • indiquent l’autorité de certification et les systèmes d’exploitation clients de certificats minimaux qui peuvent utiliser le modèle.

Pour aider les administrateurs à distinguer les fonctionnalités prises en charge par les différentes versions de système d’exploitation, l’onglet Compatibilité a été ajouté à l’onglet des propriétés de modèle de certificat.

Quels avantages cette modification procure-t-elle ?

Les nouveaux modèles de certificat version 4 offrent des fonctionnalités supplémentaires, telles que la possibilité d’imposer le renouvellement avec la même clé (uniquement accessible aux clients des certificats Windows 8, Windows 8.1, Windows Server 2012 et R2 Windows Server 2012). Le nouvel onglet Compatibilité permet aux administrateurs de définir différentes combinaisons de versions de système d’exploitation pour l’autorité de certification et d’afficher uniquement les paramètres compatibles avec ces versions de clients.

En quoi le fonctionnement est-il différent ?

L’onglet Compatibilité s’affiche dans l’interface utilisateur des propriétés de modèle de certificat. Cet onglet vous permet de sélectionner l’autorité de certification minimale et les versions minimales du système d’exploitation du client de certificat. La configuration de l’onglet Compatibilité remplit les fonctions suivantes :

  • Elle marque les options comme non disponibles dans les propriétés des modèles de certificats en fonction des versions de système d’exploitation clients de certificats et de l’autorité de certification sélectionnées.

  • Pour les modèles version 4, elle identifie les versions de système d’exploitation en mesure d’utiliser le modèle.

Les clients antérieurs à Windows 8 et Windows Server 2012 ne peuvent pas tirer parti des nouveaux modèles de version 4.

System_CAPS_ICON_note.jpg Remarque


L’onglet Compatibilité affiche le message suivant : Il se peut que ces paramètres n’empêchent pas les systèmes d’exploitation plus anciens d’utiliser ce modèle. Cette déclaration signifie que les paramètres de compatibilité n’ont aucun effet restrictif sur les modèles de version 1, 2 ou 3 et que l’inscription peut continuer comme avant. Par exemple, sous l’onglet Compatibilité, si la version minimale du système d’exploitation client est définie sur Windows Vista avec un modèle de version 2, cela signifie qu’un client de certificat Windows XP pourra toujours s’inscrire à un certificat en utilisant le modèle de version 2.

Pour plus d’informations sur ces modifications, consultez la page Options et versions de modèles de certificat.

Prise en charge du renouvellement des certificats avec la même clé

Sous Windows Server 2012 et Windows Server 2012, les services AD CS permettent de configurer un certificat de manière à le renouveler avec la même clé. Cela permet de maintenir le niveau d’assurance de la clé d’origine pendant toute sa durée de vie.Windows Server 2012 et Windows Server 2012 prennent en charge la génération de clés protégées par le module de plateforme sécurisée (TPM) via des fournisseurs de stockage de clés (KSP) basés sur le module TPM. L’avantage de l’utilisation d’un fournisseur KSP basé sur le module TPM est une vraie non-exportabilité des clés sauvegardées par le mécanisme anti-martèlement des modules TPM. Les administrateurs peuvent configurer des modèles de certificat de telle sorte que Windows 8, Windows 8.1, Windows Server 2012 et R2 Windows Server 2012 accordent la priorité aux fournisseurs KSP basés sur le module TPM pour la génération de clés. Par ailleurs, en utilisant le renouvellement avec la même clé, les administrateurs peuvent être assurés que la clé reste toujours sur le module TPM après le renouvellement.

System_CAPS_ICON_note.jpg Remarque


La saisie incorrecte à de trop nombreuses reprises du code confidentiel active la logique anti-martèlement du module TPM. une logique anti-martèlement est une méthode matérielle ou logicielle qui rend une attaque en force sur un code confidentiel plus difficile et coûteuse, car les saisies de code confidentiel sont refusées tant qu’un certain délai ne s’est pas écoulé ;

Quels avantages cette modification procure-t-elle ?

Cette fonctionnalité permet à un administrateur de mettre en application le renouvellement avec la même clé, ce qui peut réduire les coûts administratifs (lorsque les clés sont renouvelées automatiquement) et renforcer la sécurité des clés (lorsque les clés sont stockées en utilisant des fournisseurs KSP basés sur le module TPM).

En quoi le fonctionnement est-il différent ?

Les clients qui reçoivent des certificats issus de modèles configurés en vue d’un renouvellement avec la même clé doivent renouveler leurs certificats avec la même clé, faute de quoi, le renouvellement échoue. De même, cette option n’est accessible qu’aux clients de certificat Windows 8, Windows 8.1, Windows Server 2012 et R2 Windows Server 2012.

System_CAPS_ICON_note.jpg Remarque

Si l’option Renouveler avec la même clé est activée sur un modèle de certificat et qu’un archivage des clés ultérieur (Archiver la clé privée de chiffrement du sujet) est également activé, les certificats renouvelés ne seront pas archivés. Pour en savoir plus sur cette situation et comment l’atténuer, consultez la page Archivage des clés et renouvellement avec la même clé.

Prise en charge des noms de domaines internationaux

Les noms internationaux sont des noms qui contiennent des caractères qui ne peuvent pas être représentés au format ASCII. Sous Windows Server 2012 et R2 Windows Server 2012, les services AD CS prennent en charge les noms de domaine internationaux dans plusieurs scénarios.

Quels avantages cette modification procure-t-elle ?

Les scénarios sur les noms de domaines internationaux suivants sont à présent pris en charge

  • Inscription de certificats pour les ordinateurs avec des noms de domaines internationaux

  • Génération et envoi d’une demande de certificat avec un nom de domaine international en utilisant l’outil en ligne de commande certreq.exe

  • Publication des listes de révocation des certificats (CRL) et du protocole OCSP (Online Certificate Status Protocol) sur des serveurs avec des noms de domaines internationaux

  • L’interface utilisateur Certificat prend en charge les noms de domaine internationaux

  • Le composant logiciel enfichable MMC Certificat autorise également les noms de domaine internationaux dans les Propriétés du certificat

En quoi le fonctionnement est-il différent ?

Comme décrit précédemment, la prise en charge des noms de domaines internationaux est limitée.

Sécurité accrue activée par défaut sur le service de rôle Autorité de certification

Lorsqu’une demande de certificat est réceptionnée par une autorité de certification, celle-ci peut imposer le chiffrement de la requête via RPC_C_AUTHN_LEVEL_PKT, comme décrit dans l’article Constantes au niveau de l’authentification. Dans Windows Server 2008 R2 et les versions antérieures, ce paramètre n’est pas activé par défaut pour l’autorité de certification. Dans une autorité de certification Windows Server 2012 ou R2 Windows Server 2012, ce paramètre de sécurité renforcée est activé par défaut.

Quels avantages cette modification procure-t-elle ?

L’autorité de certification applique la sécurité renforcée dans les demandes qui lui sont envoyées. Ce niveau plus élevé de sécurité exige que les paquets demandant un certificat soient chiffrés pour ne pas être interceptés ni lus. Si ce paramètre n’est pas activé, toute personne ayant accès au réseau peut lire les paquets échangés avec l’autorité de certification en utilisant un analyseur réseau. Cela signifie que des informations accessibles pourraient être considérées comme une violation de la confidentialité, par exemple les noms d’ordinateurs ou utilisateurs demandeurs, les types de certificats pour lesquels ils sont inscrits, les clés publiques impliquées, etc. Dans une forêt ou un domaine, la fuite de ces données peut ne pas être un problème pour la plupart des organisations. Toutefois, si des personnes malveillantes accèdent au trafic réseau, les informations sur la structure interne de la société et l’activité peuvent être recueillies et utilisées pour des attaques d’ingénierie sociale ou d’hameçonnage plus ciblées.

Les commandes permettant d’activer le niveau de sécurité renforcée de RPC_C_AUTHN_LEVEL_PKT pour les autorités de certification Windows Server 2003, Windows Server 2003 R2, Windows Server 2008 ou Windows Server 2008 R2 sont les suivantes :

certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST
Pour redémarrer l’autorité de certification :
net stop certsvc
net start certsvc

Si vous disposez toujours d’ordinateurs clients Windows XP qui doivent demander des certificats auprès d’une autorité de certification avec le paramètre activé, vous avez deux possibilités :

  1. Effectuez la mise à niveau des clients Windows XP vers un système d’exploitation plus récent.

  2. Réduisez le niveau de sécurité de l’autorité de certification en exécutant les commandes suivantes :

    Pour réduire le niveau de sécurité de l’autorité de certification à des fins de compatibilité avec les clients Windows XP
    1. certutil -setreg CA\InterfaceFlags -IF_ENFORCEENCRYPTICERTREQUEST

    2. net stop certsvc

    3. net start certsvc

En quoi le fonctionnement est-il différent ?

Les clients Windows XP ne sont pas compatibles avec ce paramètre de sécurité renforcée activé par défaut pour une autorité de certification Windows Server 2012 ou R2 Windows Server 2012. Si nécessaire, vous pouvez abaisser le niveau de sécurité du paramètre comme décrit précédemment.

Reconnaissance des sites AD DS pour les services AD CS et les clients PKI

Sous Windows 8, Windows 8.1, Windows Server 2012 et R2 Windows Server 2012, les services de certificats peuvent être configurés pour utiliser des sites AD DS (services de domaine Active Directory) afin d’optimiser les demandes des clients relatives aux services de certificats. Cette fonctionnalité n’est pas activée par défaut sur l’autorité de certification ni sur les ordinateurs clients d’infrastructure à clé publique (PKI).

System_CAPS_ICON_note.jpg Remarque


Pour plus d’informations sur l’activation de la reconnaissance des sites AD DS, consultez l’article TechNet Wiki Reconnaissance des sites AD DS pour les services AD CS et les clients PKI.

Quels avantages cette modification procure-t-elle ?

Cette modification permet aux clients de certificats Windows 8, Windows 8.1, Windows Server 2012 et R2 Windows Server 2012 de rechercher une autorité de certification sur leur site AD DS local.

En quoi le fonctionnement est-il différent ?

Lors de l’inscription pour un certificat basé sur un modèle, le client demande aux services AD DS le modèle et les objets de l’autorité de certification. Le client utilise ensuite un appel de fonction DsGetSiteName pour obtenir son propre nom de site. Pour les autorités de certification dont l’attribut msPKI-Site-Name est déjà défini, le client des services de certificats calcule le coût du lien de site AD DS du site client vers chaque site de l’autorité de certification cible. Un appel de fonction DsQuerySitesByCost est utilisé pour effectuer ce calcul. Le client des services de certificats utilise les coûts de site retournés pour classer par priorité les autorités de certification qui accordent au client l’autorisation Inscrire et prennent en charge le modèle de certificat approprié. Plus le coût est élevé, plus les autorités de certification sont contactées en dernier (uniquement si les anciennes autorités de certification ne sont pas disponibles).

System_CAPS_ICON_note.jpg Remarque


Une autorité de certification peut ne retourner aucun coût de site si l’attribut msPKI-Site-Name n’est pas défini sur l’autorité de certification. Si aucun coût de site n’est disponible pour une autorité de certification particulière, le coût le plus élevé possible lui est affecté.

Format PFX avec protection de groupe

Auparavant, un format standard PKCS#12 (également appelé PFX) était uniquement protégé par un mot de passe dont les limites étaient les suivantes :

  • Difficile à automatiser

  • Pas très sûr, car un administrateur utilisait généralement un mot de passe faible

  • Difficile à partager entre plusieurs utilisateurs

Windows 8, Windows 8.1, Windows Server 2012 et R2 Windows Server 2012 peuvent protéger les clés de certificat et les clés privées associées en combinant un format PFX existant avec une nouvelle fonctionnalité de protection des données. Cela permet de chiffrer le contenu du fichier PFX avec une clé appartenant à un groupe ou à un individu, au lieu de recourir à une protection avec un mot de passe.

System_CAPS_ICON_note.jpg Remarque

Quels avantages cette modification procure-t-elle ?

Grâce à cette fonctionnalité, les administrateurs pourront :

  • Déployer, gérer et dépanner les certificats à distance et dans les différentes batteries de serveurs à l’aide de Windows PowerShell.

  • Partager en toute sécurité des certificats et des clés entre les batteries de serveurs exécutant Windows Server 2012 ou R2 Windows Server 2012, à l’aide des API Windows.

Les versions antérieures de Windows peuvent utiliser ce PFX, car en interne, le système d’exploitation attribue un mot de passe aléatoire. Le mot de passe est inclus dans le PFX et il est protégé par un ensemble d’identificateurs de sécurité (SID) avec l’API de protection des données. Tout utilisateur ayant accès au PFX peut voir ce mot de passe et le partager avec des versions précédentes de Windows.

En quoi le fonctionnement est-il différent ?

Un fichier PFX peut à présent être protégé à l’aide d’un principal de sécurité au lieu d’un simple mot de passe. L’interface utilisateur pour l’exportation du certificat a été mise à jour pour permettre la sélection d’un principal de sécurité lors de l’exportation.

Notifications du cycle de vie du certificat

Sous Windows 8, Windows 8.1, Windows Server 2012 et R2 Windows Server 2012, les certificats fournissent des notifications de cycle de vie dans le magasin MY à partir des niveaux d’API d’inscription de certificat et de Windows PowerShell. Les notifications concernent l’expiration, la suppression, la création, le renouvellement, le remplacement, l’imminence d’une expiration, l’archivage et l’exportation. Les administrateurs et les développeurs peuvent gérer (afficher, installer, copier, demander et supprimer) des certificats et leurs clés privées associées à distance, à l’aide de Windows PowerShell. Cette fonctionnalité permet à un script ou un exécutable de se lancer en réponse à une notification de cycle de vie du certificat.

System_CAPS_ICON_note.jpg Remarque

Quels avantages cette modification procure-t-elle ?

Pour les développeurs de charge de travail du serveur et d’applications qui utilisent des certificats dans leurs produits, l’intégration avec le cycle de vie du certificat sous Windows 8, Windows 8.1, Windows Server 2012 et R2 Windows Server 2012 est facile et fiable, et peut également être effectuée à distance. Les développeurs peuvent développer des applications qui se reconfigurent dès qu’un certificat est renouvelé ou remplacé par un autre (par inscription automatique ou par une action de script ou manuelle d’un administrateur). L’investissement nécessaire à l’intégration avec les interfaces de gestion de certificat est très faible.

Pour un administrateur qui gère les applications utilisant des certificats, les certificats de Windows 8, Windows 8.1, Windows Server 2012 et R2 Windows Server 2012 sont automatiquement utilisés par ces applications. En effet, les applications s’intègrent avec les notifications de certificat de Windows 8, Windows 8.1, Windows Server 2012 et R2 Windows Server 2012 ou lorsque le script de l’administrateur est déclenché par un événement de certificat.

En quoi le fonctionnement est-il différent ?

Les notifications peuvent dorénavant être activées pour alerter les administrateurs système avant que les certificats n’expirent.

Clés privées de l’autorité de certification incluses dans l’image de sauvegarde de l’état du système

La fonctionnalité de sauvegarde de Windows Server peut être installée sur l’autorité de certification pour créer une sauvegarde de l’état du système incluant les clés privées de l’autorité de certification.

En quoi le fonctionnement est-il différent ?

Sous Windows Server 2012 et R2 Windows Server 2012, la fonctionnalité de sauvegarde de l’état du système sauvegarde automatiquement la clé privée de l’autorité de certification lorsqu’un administrateur ou un opérateur de sauvegarde utilise la fonctionnalité de sauvegarde de Windows Server pour effectuer une sauvegarde de l’état du système.

En quoi le fonctionnement est-il différent ?

La fonctionnalité de sauvegarde de Windows Server inclut désormais les clés privées de l’autorité de certification.

System_CAPS_ICON_tip.jpg Astuce

Afficher: