web-dev-qa-db-fra.com

Liste de contrôle sur la création d'une autorité de certification racine et intermédiaire hors ligne (CA)

Microsoft autorise une autorité de certification à utiliser Cryptography Next Generation (CNG) et conseille des problèmes d'incompatibilité pour les clients qui ne prennent pas en charge cette suite.

Voici une image des paramètres de cryptographie par défaut pour une autorité de certification 2008 R2. Cette machine est une autorité de certification autonome non connectée à un domaine:

Default Cryptography settings

Voici les fournisseurs installés. Les fournisseurs de GNC sont marqués d'un signe #

enter image description here

Mon intention est d'avoir une racine-CA hors ligne à usage général, puis plusieurs autorités de certification intermédiaires qui servent un objectif spécifique (MSFT uniquement vs Unix vs SmartCards, etc.)

Quels sont les paramètres idéaux pour un certificat racine avec une expiration de 5, 10 et 15 ans?

  1. CSP
  2. Certificat de signature
  3. Longueur du caractère clé

Comme il s'agit d'un RootCA, l'un des paramètres affecte-t-il le processeur à faible puissance (appareils mobiles)

encryptionwindowscertificatespublic-key-infrastructurecertificate-authority
25
goodguys_activate

Remarque: Il s'agit d'un recueil (très très long) de diverses recommandations et actions que Microsoft, le NIST et d'autres experts PKI et cryptographie très respectés ont déclaré. Si vous voyez quelque chose qui nécessite même la moindre révision, faites-le moi savoir.

Avant de commencer à configurer l'autorité de certification et ses sous-marins, il est bon de savoir que même si CryptoAPI de MSFT nécessite une racine auto-signée, certains logiciels non MSFT peuvent suivre la RFC 3280 et permettre à toute autorité de certification d'être la racine de confiance à des fins de validation. Une raison peut être que le logiciel non MSFT préfère une longueur de clé inférieure.

Voici quelques notes de configuration et des conseils sur la configuration d'un CA ROOT et des sous-marins:

Stockage de la clé privée de l'autorité de certification

Longueur de la clé

Expiration

L'algorithme et la longueur de clé peuvent avoir une incidence sur la durée de validité des certificats, car ils déterminent efficacement la durée de fissuration d'un attaquant, c'est-à-dire que plus la cryptographie est solide, plus vous serez prêt à avoir des certificats valides pendant

Une approche consiste à établir la durée de validité la plus longue dont vous aurez besoin pour les certificats d'entité finale, à la doubler pour les autorités de certification émettrices, puis à la doubler à nouveau pour l'autorité de certification racine (en deux niveaux). Avec cette approche, vous renouveleriez régulièrement chaque certificat CA lorsque la moitié de sa durée de vie a été atteinte, car un CA ne peut pas émettre de certificats dont la date d'expiration est postérieure à celle du certificat CA lui-même.

Les valeurs appropriées ne peuvent vraiment être déterminées que par votre organisation et votre politique de sécurité, mais généralement, une racine ca aurait une durée de vie de certificat de 10 ou 20 ans.

Si vous êtes préoccupé par la compatibilité, définissez la date d'expiration en dessous de 2038. Cela est dû aux systèmes qui codent les données en secondes depuis le 1er janvier 1970 sur un entier 32 bits signé. En savoir plus sur ce problème ici.

Choisir un hachage

Notamment:

  • Windows 2003 et les clients XP peuvent avoir besoin d'un correctif pour les algorithmes SHA2 qui incluent SHA256, SHA384 et SHA512. Voir plus d'informations techniques

  • Authenticode et S/MIME avec hachage SHA2 ne sont pas pris en charge sur XP ou 2003

  • "En ce qui concerne la prise en charge de SHA-224, SHA-224 offre moins de sécurité que SHA-256 mais prend la même quantité de ressources. De plus, SHA-224 n'est généralement pas utilisé par les protocoles et les applications. Les normes Suite B de la NSA ne l'incluent pas non plus." source

  • "N'utilisez la suite SHA2 nulle part dans la hiérarchie de l'autorité de certification si vous prévoyez d'avoir XP soit faites confiance au certificat, validez le certificat, utilisez le certificat dans la validation de chaîne ou recevez un certificat de l'autorité de certification." Même si XP SP3 permet la validation des certificats qui utilisent SHA2 dans la hiérarchie de l'autorité de certification et que KB 968730 autorise l'inscription limitée de certificats signés par une autorité de certification utilisant SHA2, toute utilisation de signatures discrètes bloque = XP entièrement. "( source )

Choix d'un fournisseur cryptographique

Activer la génération aléatoire de numéros de série

Depuis 2012, cela est obligatoire si vous utilisez MD5 comme hachage. C'est toujours un bonne idée si SHA1 ou supérieur est utilisé. Voir aussi ce "mode d'emploi" de Windows 2008R2 pour plus d'informations.

Créer une déclaration de pratique de certificat

Une déclaration de pratique de certificat est une déclaration des pratiques que le service informatique utilise pour gérer les certificats qu'il émet. Il décrit comment la politique de certification de l'organisation est interprétée dans le contexte de l'architecture système de l'organisation et de ses procédures de fonctionnement. Le service informatique est responsable de la préparation et de la mise à jour de l'énoncé des pratiques de certification. ( source )

REMARQUE: dans certaines situations, comme lorsque des signatures numériques sont utilisées sur des contrats contraignants, l'énoncé de pratique de certificat peut également être considéré comme une déclaration juridique concernant le niveau de sécurité fourni et les garanties utilisées pour établir et maintenir le niveau de sécurité. .

Pour obtenir de l'aide pour la rédaction d'une déclaration CPS, voici un "Job Aid" produit par Microsoft

Meilleure pratique: bien qu'il soit possible de mettre du texte de forme libre dans ce champ (voir notice ci-dessous), la solution idéale est d'utiliser une URL. Cela permet de mettre à jour la stratégie sans réémettre les certificats, cela empêche également les ballonnements inutiles du magasin de certificats.

[LegalPolicy]
OID = 1.3.6.1.4.1.311.21.43
Notice = "Legal policy statement text"
URL = "http://www.example.Microsoft.com/policy/isspolicy.asp"

Stratégies de certificat

Également connu sous le nom de politiques d'émission ou politiques d'assurance (dans MSFT), il s'agit d'un OID autodéfini qui décrit le niveau de confiance que l'on doit mettre dans votre certificat (élevé, moyen, faible, etc.) . Voir cette réponse StackExchange pour savoir comment utiliser correctement ce champ.

Assurez-vous que les politiques d'application et les politiques EKU correspondent

Stratégies d'application est une convention Microsoft facultative. Si vous émettez des certificats qui incluent à la fois la stratégie d'application et les extensions EKU, assurez-vous que les deux extensions contiennent des identificateurs d'objet identiques.

Activer la vérification CRL

Normalement, une autorité de certification Windows Server 2003 vérifie toujours la révocation de tous les certificats de la hiérarchie PKI (à l'exception du certificat d'autorité de certification racine) avant d'émettre un certificat d'entité finale. Pour désactiver cette fonctionnalité, utilisez la commande suivante sur l'autorité de certification, puis redémarrez le service de l'autorité de certification:

 certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

Point de distribution CRL

Conseils spéciaux pour les autorités de certification racine

  • Ceci est facultatif dans une autorité de certification racine et s'il est mal fait cela peut exposer votre clé privée .

  • Toute publication CRL est effectuée manuellement à partir d'un RootCA hors ligne vers toutes les autres sous-autorités de certification. Une alternative est de tiliser un câble audio pour faciliter la communication unidirectionnelle de la racine aux CA secondaires

  • Il est parfaitement acceptable que l'autorité de certification racine émette différents emplacements de liste de révocation de certificats pour chaque certificat émis à des autorités de certification subordonnées.

  • Avoir une liste de révocation de certificats à la racine est une meilleure pratique si deux PKI se font mutuellement confiance et que le mappage des stratégies est effectué. Cela permet au certificat d'être révoqué.

Obtenir la "bonne" liste de révocation de certificats est assez important, car il appartient à chaque application d'effectuer la vérification de la liste de révocation de certificats. Par exemple, l'ouverture de session par carte à puce sur les contrôleurs de domaine applique toujours la vérification de révocation et rejettera un événement d'ouverture de session si la vérification de révocation ne peut pas être effectuée ou échoue.

Remarque Si un certificat de la chaîne ne peut pas être validé ou est révoqué, la chaîne entière prend le statut de ce certificat.

  • Une autorité de certification racine auto-signée ne doit répertorier aucun CDP. La plupart des applications Windows n'activent pas l'indicateur CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT et ignorent donc le CDP ( c'est le mode de validation par défaut ). Si l'indicateur est activé et que le CDP est vide pour le certificat racine auto-signé, aucune erreur n'est renvoyée.

  • N'utilisez pas HTTPS et LDAPS. Ces URL ne sont plus prises en charge en tant que références de point de distribution. La raison en est que les URL HTTPS et LDAPS utilisent des certificats qui peuvent ou non être révoqués. Le processus de vérification de révocation peut entraîner des boucles de révocation lorsque des URL HTTPS ou LDAPS sont utilisées. Pour déterminer si le certificat est révoqué, la liste de révocation de certificats doit être récupérée. Toutefois, la liste de révocation de certificats ne peut être récupérée que si l'état de révocation des certificats utilisés par HTTPS ou LDAPS est déterminé.

  • Envisagez d'utiliser HTTP au lieu de LDAP. Bien que AD DS active la publication des listes de révocation de certificats sur tous les contrôleurs de domaine de la forêt, implémentez HTTP au lieu de LDAP pour la publication des informations de révocation. Seul HTTP permet l'utilisation de ETag et Cache-Control: Max-age En-têtes offrant une meilleure prise en charge des proxys et des informations de révocation plus opportunes. De plus, HTTP offre une meilleure prise en charge hétérogène car HTTP est pris en charge par la plupart des clients Linux, UNIX et de périphériques réseau.

  • Une autre raison de ne pas utiliser LDAP est que la fenêtre de révocation est plus petite. Lorsque vous utilisez AD LDAP pour répliquer les informations de l'autorité de certification, la fenêtre de révocation ne peut pas être inférieure au temps nécessaire à tous les sites dans AD pour obtenir la mise à jour de l'autorité de certification. Souvent, cette réplication peut prendre jusqu'à 8 heures ... soit 8 heures jusqu'à ce que l'accès d'un utilisateur de carte à puce soit révoqué. 'Todo: le nouveau temps de rafraîchissement CRL recommandé est: ?????'

  • Rendre toutes les URL hautement disponibles (aka ne pas inclure LDAP pour les hôtes externes). Windows ralentira le processus de validation jusqu'à 20 secondes et réessayez la connexion qui a échoué à plusieurs reprises au moins aussi souvent que toutes les 30 minutes. Je soupçonne que pré-extraction entraînera cela, même si l'utilisateur n'utilise pas activement le site.

  • Surveillez la taille de votre CRL. Si l'objet CRL est si volumineux que CryptoAPI n'est pas en mesure de télécharger l'objet dans le délai maximal imparti, ne erreur de "révocation hors ligne" est renvoyée et le téléchargement de l'objet est terminé.

Remarque: la distribution de CRL sur HTTP avec prise en charge ETAG peut entraîner des problèmes avec IE6 lors de l'utilisation de Windows 2003/IIS6, où la connexion TCP est constamment réinitialisée.

  • (Facultatif) Activer la plus récente CRL : cette extension non critique répertorie les émetteurs et les emplacements à partir desquels récupérer les CRL delta. Si l'attribut "Freshest CRL" n'est ni présent dans la CRL ni dans le certificat, alors la CRL de base sera traitée comme une CRL régulière, pas comme faisant partie d'une paire CRL de base/CRL delta.

L'autorité de certification Microsoft ne place pas l'extension "Freshest CRL" dans les certificats émis. Cependant, il est possible d'ajouter l'extension "Freshest CRL" à un certificat émis. Vous devez écrire du code pour l'ajouter à la demande, écrire un module de stratégie personnalisé ou utiliser certutil –setextension Sur une demande en attente. Pour plus d'informations sur l'inscription avancée aux certificats, consultez la documentation "Inscription et gestion avancées des certificats" sur le site Web de Microsoft

Avertissement Si les listes CRL delta sont activées dans une autorité de certification, la liste CRL de base et la liste CRL delta doivent être inspectées afin de déterminer l'état de révocation du certificat. Si l'un des deux, ou les deux, ne sont pas disponibles, le moteur de chaînage signale que le statut de révocation ne peut pas être déterminé et une application peut rejeter le certificat.

Dimensionnement et maintenance CRL (partitionnement CRL)

La liste de révocation de certificats augmentera de 29 octets pour chaque certificat révoqué. Par conséquent, les certificats révoqués seront supprimés de la liste de révocation de certificats lorsque le certificat atteindra sa date d'expiration d'origine.

Étant donné que le renouvellement d'un certificat d'autorité de certification entraîne la génération d'une nouvelle liste de révocation de certificats vierge, les autorités de certification émettrices peuvent envisager de renouveler l'autorité de certification avec une nouvelle clé tous les 100 à 125 Ko pour conserver une taille de liste de révocation de certificats raisonnable. Ce numéro d'émission est basé sur l'hypothèse qu'environ 10% des certificats émis seront révoqués avant leur date d'expiration naturelle. Si le taux de révocation réel ou prévu est supérieur ou inférieur pour votre organisation, ajustez la stratégie de renouvellement clé en conséquence. Plus d'informations

Envisagez également de partitionner la liste de révocation de certificats plus fréquemment si l'expiration est supérieure à 1 ou deux ans, car la probabilité de révocation augmente.

L'inconvénient est l'augmentation des temps de démarrage, car chaque certificat est validé par le serveur.

Précautions de sécurité CRL

Si vous utilisez une CRL, ne signez pas la CRL avec MD5. C'est également une bonne idée de ajouter la randomisation à la clé de signature CRL.

Accès aux informations d'autorité

Ce champ permet au sous-système de validation de certificat de télécharger des certificats supplémentaires si nécessaire s'ils ne résident pas sur l'ordinateur local.

  • Une autorité de certification racine auto-signée ne doit répertorier aucun emplacement AIA ( voir la raison ici )

  • Un maximum de cinq URL sont autorisées dans l'extension AIA pour chaque certificat de la chaîne de certificats. De plus, un maximum de 10 URL pour toute la chaîne de certificats est également pris en charge. Cette limitation du nombre d'URL a été ajoutée pour atténuer l'utilisation potentielle des références "Authority Info Access" dans les attaques par déni de service.

  • N'utilisez pas HTTP [~ # ~] s [~ # ~] et LDAP [~ # ~] s [~ # ~] . Ces URL ne sont plus prises en charge en tant que références de point de distribution. La raison en est que les URL HTTPS et LDAPS utilisent des certificats qui peuvent ou non être révoqués. Le processus de vérification de révocation peut entraîner des boucles de révocation lorsque des URL HTTPS ou LDAPS sont utilisées. Pour déterminer si le certificat est révoqué, la liste de révocation de certificats doit être récupérée. Toutefois, la liste de révocation de certificats ne peut être récupérée que si l'état de révocation des certificats utilisés par HTTPS ou LDAPS est déterminé.

Activer la validation OCSP

Le répondeur OCSP est généralement situé à: http://<fqdn of the ocsp responder>/ocsp. Cette URL doit être activée dans l'AIA. Voir ces instructions pour Windows.

Sachez que la validation OCSP complète est désactivée par défaut (même si elle doit être activée pour les certificats EV selon la spécification). De plus, l'activation de la vérification OCSP ajoute de la latence à la connexion initiale

Des systèmes plus sécurisés voudront activer la surveillance OCSP côté client ou côté serveur

Durée du cache OCSP

Toutes les actions OCSP se produisent sur le protocole HTTP et sont donc soumises aux règles de cache proxy HTTP typiques.

Plus précisément, l'en-tête Max-age Définit la durée maximale pendant laquelle un serveur proxy ou un client mettra en cache une réponse CRL ou OCSP avant d'utiliser un GET conditionnel pour déterminer si l'objet a changé. Utilisez ces informations pour configurer le serveur Web afin de définir les en-têtes appropriés. Recherchez ailleurs sur cette page les commandes spécifiques AD-IIS pour cela.

Définissez une politique dans les certificats émis

L'autorité de certification parente définit s'il faut ou non autoriser les stratégies de certificat de l'autorité de certification des sous-autorités de certification. Il est possible de définir ce paramètre lorsqu'un émetteur ou une stratégie d'application doit être inclus dans une sous-autorité de certification.

Les exemples de politiques incluent une EKU pour les cartes à puce, l'authentification ou l'authentification SSL/serveur.

  • Méfiez-vous des certificats sans l'extension Certificate Policies Car cela peut compliquer l'arborescence des politiques. Voir RFC 5280 pour plus d'informations

  • Sachez que les mappages de stratégies peuvent remplacer d'autres stratégies sur le chemin

  • Il existe une politique spéciale appelée anypolicy qui modifie le traitement

  • Il existe des extensions qui modifient anypolicy

  • Si vous utilisez des politiques de certificats, assurez-vous de les marquer comme critical sinon le valid_policy_tree Calculé devient vide, transformant la politique en un commentaire glorifié.

Surveillez l'application de la longueur DN

La spécification CCITT d'origine pour le champ OU indique qu'elle doit être limitée à 64 caractères. Normalement, l'autorité de certification applique des normes de longueur de nom x 500 sur l'extension objet des certificats pour toutes les demandes. Il est possible que les chemins d'unité d'organisation profonds dépassent les restrictions de longueur normales.

Points de distribution de certificats croisés

Cette fonctionnalité aide les environnements où deux PKI doivent être installés, un pour le matériel/logiciel hérité qui ne prend pas en charge la cryptographie moderne et un autre PKI à des fins plus modernes.

Restreindre l'EKU

Contrairement à la RFC 5280 qui stipule "en général, [sic] l'extension EKU n'apparaîtra que dans les certificats d'entité finale." C'est une bonne idée de mettre contraintes sur l'utilisation de la clé CA .

Un certificat CA autonome typique contiendra des autorisations pour créer des signatures numériques, la signature de certificat et la signature CRL en tant que valeurs clés. Cela fait partie du problème avec le problème de sécurité FLAME.

L'implémentation de la carte à puce MSFT nécessite l'une des EKU suivantes et éventuellement un correctif

  • Carte à puce Microsoft EKU
  • Cryptographie à clé publique pour l'authentification EKU du client d'authentification initiale (PKINIT), telle que définie dans la RFC 4556 PKINIT

Il a également des contraintes intéressantes autour de la validation de EKU (link tbd).

Si vous êtes intéressé à avoir des restrictions EKU, vous devriez voir cette réponse concernant les OID et ceci concernant les certificats contraints

Soyez prudent avec les contraintes de base "Path"

La contrainte de base doit décrire si le certificat est une "entité finale" ou non . Ajouter une contrainte de chemin à une autorité de certification intermédiaire peut ne pas fonctionner comme prévu car il s'agit d'une configuration peu courante et les clients peuvent ne pas la respecter.

Subordination qualifiée pour les AC intermédiaires

  • Pour limiter les types de certificats qu'un subCA peut offrir, voir ce lien , et celui-ci

  • Si une subordination qualifiée est effectuée, la révocation d'une racine signée croisée peut être difficile car les racines ne mettent pas fréquemment à jour les CRL.

Identifiant de clé d'autorité/Identifiant de clé de sujet

Remarque Si l'extension AKI d'un certificat contient un KeyID, CryptoAPI requiert que le certificat de l'émetteur contienne un SKI correspondant. Cela diffère de la RFC 3280 où la correspondance SKI et AKI est facultative . (todo: Pourquoi quelqu'un choisirait-il de mettre en œuvre cela?)

AKI matching to find key parent

Donnez à la racine et à l'autorité de certification un nom significatif

Les utilisateurs interagiront avec votre certificat lors de son importation, de l'examen des certificats importés et du dépannage. La pratique recommandée par MSFT et exigence est que la racine a un nom significatif qui identifie votre organisation et non quelque chose d'abstrait et de commun comme CA1.

Cette partie suivante s'applique aux noms des intermédiaires/subCA qui seront contraints dans un but particulier: authentification vs signature vs cryptage

Étonnamment, les utilisateurs finaux et les techniciens qui ne comprennent pas les nuances de PKI interagiront avec les noms de serveur que vous choisissez plus souvent que vous ne le pensez si vous utilisez S/MIME ou des signatures numériques (etc.).

Personnellement, je pense que c'est une bonne idée de renommer les certificats d'émission en quelque chose de plus convivial, comme "Company Signer 1" Où je peux le voir en un coup d'œil

  • De qui va venir la signature (Texas A&M ou son rival)
  • A quoi cela sert? Cryptage vs signature

Il est important de faire la différence entre un message qui a été crypté entre deux parties et celui qui a été signé. Un exemple où cela est important est de savoir si je peux faire en sorte que le destinataire répète une déclaration que je lui envoie. L'utilisateur A pourrait dire à l'utilisateur B "A, je vous dois 100 $". Si B a répondu avec un écho de ce message avec la mauvaise clé, alors ils ont effectivement notarié numériquement (vs simplement le cryptage) une dette fictive de 100 $.

Voici un exemple de boîte de dialogue utilisateur pour S/MIME . Attendez-vous à des interfaces utilisateur similaires pour les certificats basés sur Brower. Remarquez que le nom de l'émetteur n'est pas convivial.

Select a SMIME certificate.. really?

Codages alternatifs

Remarque: En parlant de noms, si un lien de la chaîne utilise un autre codage, les clients peuvent ne pas être en mesure de vérifier le champ de l'émetteur du sujet. Windows ne normalise pas ces chaînes lors d'une comparaison, assurez-vous donc que les noms de l'autorité de certification sont identiques d'un point de vue binaire (par opposition à la recommandation RFC).

Name matching to find key parent

Déploiements haute sécurité/suite B

  • Voici informations concernant les algorithmes de la suite B pris en charge dans Windows 2008 et R2

    ALGORITHM SECRET TOP SECRET

    Cryptage: Advanced Standard (AES) 128 bits 256 bits

    Signature numérique: algorithme de signature numérique à courbe elliptique (ECDSA), courbe de 256 bits. Courbe de 384 bits

    Échange de clés: courbe elliptique Diffie-Hellman (ECDH), courbe de 256 bits. Courbe de 384 bits

    Hachage: algorithme de hachage sécurisé (SHA) SHA-256 SHA-384

  • Pour la conformité de la suite B, la taille de clé ECDSA_P384#Microsoft Software Key Service Provider Ainsi que 384 Et l'algorithme de hachage SHA384 Peuvent également être sélectionnés si le niveau de classification souhaité est Top Secret. Les paramètres correspondant au niveau de classification requis doivent être utilisés. ECDSA_P521 Est également disponible en option. Bien que l'utilisation d'une courbe ECC de 521 bits puisse dépasser les exigences cryptographiques de la suite B, en raison de la taille de clé non standard, 521 ne fait pas partie de la spécification officielle de la suite B.

PKCS # 1 v2.1

Protéger les ports Microsoft CA DCOM

L'Autorité de certification Windows Server 2003 n'applique pas le cryptage sur les interfaces ICertRequest ou ICertAdmin DCOM par défaut. Normalement, ce paramètre n'est pas requis sauf dans des scénarios opérationnels spéciaux et ne doit pas être activé. Par défaut, seules les machines Windows Server 2003 prennent en charge le chiffrement DCOM sur ces interfaces. Par exemple, Windows XP n'appliqueront pas le cryptage par défaut sur la demande de certificat à une autorité de certification Windows Server 2003. source

Stockage de clé privée CNG vs stockage CSP

Si vous inscrivez le modèle de certificat v3, la clé privée va dans le stockage de clé privée CNG sur l'ordinateur client. Si vous inscrivez le modèle de certificat v2 ou v1, la clé privée va dans le stockage CSP. Les certificats seront visibles par toutes les applications dans les deux cas, mais pas par leurs clés privées.Par conséquent, la plupart des applications afficheront le certificat comme disponible, mais ne pourront pas signer ou décrypter les données avec la clé privée associée, sauf si elles prennent en charge le stockage CNG.

Vous ne pouvez pas distinguer les stockages CNG et CSP à l'aide du certificat MMC. Si vous voulez voir quel stockage un certificat particulier utilise, vous devez utiliser CERTUTIL -repairstore my * (Ou CERTUTIL -user -repairstore my *) Et jeter un œil au champ Fournisseur. S'il dit "... Key Storage Provider", alors c'est CNG alors que tous les autres fournisseurs sont CSP.

Si vous créez manuellement la demande de certificat initiale (Créer une demande personnalisée dans MMC), vous pouvez choisir entre "Stockage CNG" et "Clé héritée" où hérité signifie CSP. Ce qui suit est ma liste basée sur l'expérience de ce qui ne prend pas en charge le GNC - vous ne pouvez trouver aucune liste faisant autorité nulle part, donc cela découle de mes enquêtes au fil du temps:

  • EFS Non pris en charge dans Windows 2008/Vista, Pris en charge dans Windows 7/2008R2
  • certificats de chiffrement des utilisateurs

  • Client VPN/WiFi (EAPTLS, client PEAP)

  • Windows 2008/7 Non pris en charge avec l'authentification par certificat d'utilisateur ou d'ordinateur

  • Certificats de serveur TMG 2010 sur les écouteurs Web
  • Certificats de messagerie utilisateur Outlook 2003 pour les signatures ou le chiffrement
  • Kerberos Windows 2008/Vista- DC
  • System Center Operations Manager 2007 R2
  • System Center Configuration Manager 2007 R2
  • SQL Server 2008 R2-
  • Gestion des certificats Forefront Identity Manager 2010

Plus d'informations sur la compatibilité CNG sont listées ici (en tchèque, cependant Chrome gère bien la traduction automatique)

Cartes à puce et autorités de certification émettrices

Si vous prévoyez de donner aux utilisateurs une deuxième carte à puce pour l'authentification, utilisez une deuxième autorité de certification émettrice pour cela. Raison: exigences Windows 7

Utilisez la commande Windows CERTUTIL -viewstore -enterprise NTAuth Pour dépanner les connexions par carte à puce. Le magasin NTAuth local est le résultat du dernier téléchargement de stratégie de groupe à partir du magasin NTAuth Active Directory. Il s'agit du magasin utilisé par la connexion par carte à puce. La visualisation de ce magasin peut donc être utile lors du dépannage des échecs de connexion par carte à puce.

Mise hors service d'une arborescence PKI

Si vous déployez deux arborescences PKI, avec l'intention de mettre hors service l'arborescence héritée à un moment donné (où tous les anciens périphériques sont devenus obsolètes ou mis à niveau), il peut être judicieux de définir le champ CRL Next Update sur Null. Cela empêchera (devrait?) L'interrogation continue des nouveaux CRLS auprès des clients. Le raisonnement est qu'une fois l'ICP déclassée, il n'y aura plus d'administration et plus de certificats révoqués. Tous les certificats restants sont simplement laissés à expiration.

Plus d'informations sur le déclassement de l'ICP disponibles ici

39
goodguys_activate

Commandes spécifiques à AD CS

Il s'agit d'une liste de commandes pertinentes pour la configuration d'un serveur CA Windows 2008 R2. Je les ai supprimés de l'autre post car cette information devenait trop longue et toutes les commandes ne sont pas directement liées à la configuration d'une autorité de certification.

Il s'agit plus de la section Comment, plutôt du "quoi et pourquoi". Il inclut également des différences spécifiques aux versions entre les versions de CA (2000 vs 2003, vs 2008)

Indiquez les indicateurs de modification de la politique d'inscription

Certaines demandes du client peuvent être automatiquement supprimées en fonction de ces paramètres de serveur cachés.

C:\Users\ChrisLamont>certutil -getreg

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration:

Keys:
  Secure Email Root v1

Values:
  Active                   REG_SZ = Secure Email Root v1
  DBDirectory              REG_SZ = C:\Windows\system32\CertLog
  DBLogDirectory           REG_SZ = C:\Windows\system32\CertLog
  DBTempDirectory          REG_SZ = C:\Windows\system32\CertLog
  DBSystemDirectory        REG_SZ = C:\Windows\system32\CertLog

  DBSessionCount           REG_DWORD = 64 (100)
  LDAPFlags                REG_DWORD = 0

  DBFlags                  REG_DWORD = b0 (176)
    DBFLAGS_MAXCACHESIZEX100 -- 10 (16)
    DBFLAGS_CHECKPOINTDEPTH60MB -- 20 (32)
    DBFLAGS_LOGBUFFERSHUGE -- 80 (128)

  Version                  REG_DWORD = 40001 (262145) -- 4.1
  SetupStatus              REG_DWORD = 6001 (24577)
    SETUP_SERVER_FLAG -- 1
    SETUP_DCOM_SECURITY_UPDATED_FLAG -- 2000 (8192)
    SETUP_SERVER_IS_UP_TO_DATE_FLAG -- 4000 (16384)
CertUtil: -getreg command completed successfully.

C:\Users\ChrisLamont>certutil -getreg policy\editflags

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Secur
e Email Root v1\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditF
lags:

  EditFlags REG_DWORD = 83ee (33774)
    EDITF_REQUESTEXTENSIONLIST -- 2
    EDITF_DISABLEEXTENSIONLIST -- 4
    EDITF_ADDOLDKEYUSAGE -- 8        // <--- THIS ENTRY REMOVES A CLIENT'S Key Agreement  
    EDITF_ATTRIBUTEENDDATE -- 20 (32)
    EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
    EDITF_BASICCONSTRAINTSCA -- 80 (128)
    EDITF_ENABLEAKIKEYID -- 100 (256)
    EDITF_ATTRIBUTECA -- 200 (512)
    EDITF_ATTRIBUTEEKU -- 8000 (32768)
CertUtil: -getreg command completed successfully.

La solution consiste à exécuter la commande certutil -setreg policy\EditFlags -EDITF_ADDOLDKEYUSAGE qui à son tour met à jour

     Configuration\spatula\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags:

Comment définir une politique sur une base par autorité de certification

Pour inclure une stratégie dans les certificats émis, entrez les commandes suivantes à l'invite de commandes:

 certutil -v -setreg policy\EnableRequestExtensionlist "+2.5.29.32"
 certutil –shudown
 net start certsvc

Vous pouvez désactiver le paramètre avec

  certutil -v -setreg policy\EnableRequestExtensionlist      "-2.5.29.32"
  certutil –shudown
  net start certsvc

Comment définir la durée du cache OCSP

Les commandes suivantes vous permettent de définir, de modifier et de supprimer le paramètre d'en-tête Max-Age.

  appcmd set config /section:httpProtocol /+customHeaders.[name='cacheControlHeader',value='max-age=604800']

Pour afficher les en-têtes personnalisés httpProtocol actuels

  appcmd list config /section:httpProtocol

Comment importer des certificats d'autorité de certification hors ligne dans AD 

:
: Root CA certificates
:
certutil -dspublish -f concorp-ca-00_CorporateRootCA.crt RootCA
:
: Sub CA certificate
:
certutil -dspublish -f connoam-ca-00_IntermediateCA1.crt SubCA
:
: Root CA CRLs
: Since these are .NET CA CRLS that have the publication location as
: part of the CRL, the publication location is optional
:
:                                              |-- publication location ---|
:
certutil -dspublish -f CorporateRootCA.crl     concorp-ca-00 CorporateRootCA
:
: Sub CA CRLs
:
certutil -dspublish -f IntermediateCA1.crl     connoam-ca-00 IntermediateCA1

Comment activer PKCS # 1 v1.21

Ceci est activé lorsque le fichier CAPolicy.inf a AlternateSignatureAlgorithm=1. Assurez-vous d'être conscient des problèmes de compatibilité.

Enfin, il faut savoir que l'installation des services de certificats AD n'est pas aussi simple que d'ajouter le rôle. Vous devez vérifier cela script d'installation VBS et vous assurer que le fichier CAPolicy.inf doit être modifié selon les besoins de votre environnement

Comment définir un point de distribution de certificats croisés

Les services de certificats Windows AD activent cela dans le fichier CAPolicy.info avec le [CrossCertificateDistributionPointsExtension] entrée

Divers: différences AIA lors de la mise à niveau de Windows 2000 CA vers Windows 2003

Notez qu'il existe un changement de comportement entre les autorités de certification Windows 2000 et 2003. L'extension AKI des certificats émis par les autorités de certification Windows diffère entre Windows 2000 et Windows Server 2003. Par défaut, les informations suivantes sont stockées dans l'extension AIA des certificats émis.

  • Windows 2000 L'extension AIA des certificats émis par l'autorité de certification comprend le nom distinctif LDAP de l'autorité de certification émettrice (nom de l'émetteur), le numéro de série du certificat de l'autorité de certification émettrice et le hachage de clé de la clé publique du certificat de l'autorité de certification.

  • Windows Server 2003 L'extension AIA des certificats émis par l'autorité de certification inclut uniquement un hachage de la clé publique de l'autorité de certification émettrice, également connue sous le nom d'ID de clé.

Le changement de comportement est dû à des erreurs de chaînage pouvant survenir lors du renouvellement d'un certificat d'autorité de certification. Le comportement par défaut de Windows 2000 peut entraîner des chaînes incomplètes si le certificat CA utilisé pour signer le certificat émis n'est pas disponible pour le client. Avec le comportement par défaut de Windows Server 2003, si l'autorité de certification a été renouvelée avec la même paire de clés, tout certificat d'autorité de certification pour l'autorité de certification émettrice qui utilise la même paire de clés peut être inclus dans la chaîne de certificats.

Vous pouvez imiter l'ancien comportement en exécutant cette commande

 certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERNAME
 certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERSERIAL

Liste des certificats dans AD

Cette commande répertorie les certificats publiés dans Active Directory.

certutil -viewstore "ldap:///CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com?cACertificate?one?objectClass=certificationAuthority"

Compatibilité PKI ISIS MTT v1.1

Voir ceci KB Article for procedures , voici également une méthode CAPolicy.inf alternative pour ISIS MTT v1.1

4
goodguys_activate

un point de la liste de contrôle est souvent oublié:

  • SAUVEGARDES
  • SAUVEGARDES
  • SAUVEGARDES

esp. si vous implémentez une autorité de certification.

3
that guy from over there

J'ai manqué d'espace sur ma réponse précédente, mais je pense que ce sont des informations valides et utiles:

Révocation

Les prochaines sections traitent de la liste de révocation de certificats et des certificats, mais avant d'aller trop loin, je tiens à attirer votre attention sur un problème qui peut affecter la production et les opérations PKI: si vous pensez que votre PKI révoquera deux fois le même certificat avec le PKI de Microsoft (certificat Active Directory Services), la date de révocation sera la date de la deuxième révocation, pas la première. Mais si vous gérez des certificats sur des cartes à puce avec le produit FIM CM de Microsoft (Forefront Identity Management - Gestion des certificats), vous effectuerez de telles révocations en double. source

1
goodguys_activate