Zertifikat-Benutzung – Page 19

Le service d'enregistrement des périphériques réseau (NDES) consigne le message d'erreur "The Network Device Enrollment Service cannot retrieve one of its required certificates (0x80070057). The parameter is incorrect".

Supposons le scénario suivant :

Un serveur NDES est configuré sur le réseau.
L'erreur HTTP 500 (Internal Server Error) est signalée lors de l'appel de la page web de demande NDES (mscep) et de la page web d'administration NDES (certsrv/mscep_admin).
Les événements n 2 et 10 enregistré dans le journal des événements de l'application :

The Network Device Enrollment Service cannot be started (0x80070057). The parameter is incorrect.

The Network Device Enrollment Service cannot retrieve one of its required certificates (0x80070057). The parameter is incorrect.

Continuer la lecture

Création d'une carte à puce virtuelle dans un système invité Hyper-V

Pour les environnements de test, il est souvent utile de pouvoir travailler avec des cartes à puce. Voici un petit guide sur la manière de mettre en place une carte à puce virtuelle dans un invité Hyper-V à l'aide d'un module de plate-forme de confiance (TPM) virtualisé.

Continuer la lecture

Modèles de certificats de contrôleur de domaine et inscription par carte à puce

Pour que les contrôleurs de domaine puissent traiter les inscriptions par carte à puce, ils ont besoin de certificats qui fournissent cette fonction.

Continuer la lecture

(Ré)installation des modèles de certificats Microsoft Standard

Il peut y avoir des cas où il est nécessaire d'installer les modèles de certificats Microsoft standard avant d'installer la première autorité de certification intégrée à Active Directory (Enterprise Certification Authority) ou de réinstaller les modèles, par exemple parce qu'ils ont été endommagés ou modifiés d'une autre manière.

Continuer la lecture

Vecteur d'attaque sur le service d'annuaire Active Directory via le mécanisme de connexion par carte à puce

Pour simplifier, on peut réduire la cryptographie à clé publique à l'hypothèse que la partie privée de chaque paire de clés n'est connue que de son propriétaire.

Une autorité de certification est responsable de l'identification correcte des utilisateurs, des ordinateurs ou des ressources. Les certificats qu'elle délivre bénéficient donc d'un statut de confiance, car tous les participants supposent que leur clé privée n'est connue que d'elle.

Si un attaquant parvient à prendre connaissance de la clé privée d'une autorité de certification, ou au moins d'effectuer des signatures au moyen de la clé privéeL'intégrité de l'autorité de certification n'est plus garantie.

Continuer la lecture

Principes de base : limiter l'utilisation de la clé étendue (Extended Key Usage, EKU) dans les certificats d'autorité de certification

Une mesure de durcissement judicieuse pour les organismes de certification consiste à limiter les certificats d'organismes de certification, de sorte qu'ils ne puissent être utilisés que pour les certificats effectivement délivrés. utilisation étendue des clés (Extended Key Usage) devient familier.

En cas de compromission de l'autorité de certification, le dommage est alors (tout de même) limité aux Extended Key Usages définis.

Le Smart Card Logon Extended Key Usage, intéressant pour de nombreuses attaques (en relation avec l'adhésion de l'autorité de certification à NTAuthCertificates) ne serait alors présent que dans le certificat d'autorité de certification de l'autorité de certification qui délivre effectivement de tels certificats.

Continuer la lecture

Quelles sont les longueurs de clé à utiliser pour les autorités de certification et les certificats ?

Lors de la planification d'une infrastructure à clé publique, la question se pose naturellement de savoir quelles longueurs de clé il convient de choisir pour les certificats d'autorité de certification et les certificats finaux.

Continuer la lecture

Génération d'une demande de certificat conforme à la RFC 2818 pour les certificats SSL

Google est très actif avec le projet Chromium et les produits basés sur ce dernier, tels que Google Chrome et Microsoft Edge ont commencé à appliquer la loi sur la protection des données adoptée en 2000. RFC 2818 et de ne plus faire confiance aux certificats qui ne satisfont plus au RFC.

Pour nous, la phrase suivante est d'une grande acuité :

Si une extension subjectAltName de type dNSName est présente, elle DOIT être utilisée comme identité. Sinon, le champ Nom commun (le plus spécifique) dans le champ Sujet du certificat DOIT être utilisé. Bien que l'utilisation du nom commun soit une pratique existante, elle est dépréciée et les autorités de certification sont encouragées à utiliser le dNSName à la place.
https://tools.ietf.org/html/rfc2818

Continuer la lecture

Configurer un modèle de périphérique pour le service d'enregistrement des périphériques réseau (NDES)

Par défaut, le service d'enregistrement des périphériques réseau (Network Device Enrollment Service, NDES) demande des certificats à partir du modèle "IPsec (Offline Request)". Ce modèle de certificat date de l'époque de Windows 2000 et ne peut pas être modifié. C'est pourquoi il est recommandé de modifier les paramètres par défaut et d'utiliser ses propres modèles de certificats, qui répondent aux exigences personnelles.

Continuer la lecture

Activer le SSL (Secure Sockets Layer) pour le service d'enregistrement des périphériques réseau (NDES)

Dans la configuration standard, le Network Device Enrollment Service (NDES) n'accepte que les connexions non cryptées via HTTP. Il est conseillé de configurer au moins la page web d'administration de NDES pour HTTP via TLS (HTTPS) afin de rendre plus difficile l'enregistrement du trafic réseau. Vous trouverez ci-dessous des instructions à ce sujet.

Pour un examen plus approfondi de la nécessité d'utiliser SSL, voir l'article "Faut-il utiliser HTTPS pour le service d'enregistrement des périphériques réseau (NDES) ?„ .

Continuer la lecture

Utiliser ses propres modèles de certificats d'autorité d'enregistrement (RA) pour le service d'enregistrement des périphériques réseau (NDES)

Le service d'inscription des périphériques réseau (Network Device Enrollment Service, NDES) utilise deux modèles de certificats pour sa fonction interne afin de fonctionner comme une autorité d'inscription (Registration Authority, RA). Ceux-ci sont publiés sur l'autorité de certification configurée pendant la configuration des rôles du service NDES et des certificats sont demandés :

CEP Encryption
Agent d'inscription Exchange (demande hors ligne)

Ces modèles de certificats sont des modèles standard issus du monde Windows 2000 (modèles de la version 1), c'est-à-dire qu'ils ne peuvent pas être modifiés. De plus, le modèle Exchange Enrollment Agent (Offline Request) est marqué comme modèle utilisateur, c'est-à-dire que pendant la configuration des rôles NDES, le certificat est demandé dans le contexte de l'utilisateur qui l'installe et est ensuite importé dans le magasin de la machine. Les choses se compliquent ici au plus tard lorsque les certificats doivent être renouvelés au bout de deux ans.

Il est donc préférable d'utiliser ses propres modèles de certificats pour NDES. Ceux-ci peuvent par exemple être adaptés en ce qui concerne la longueur de la clé. Il est également possible d'utiliser des modules de sécurité matériels (HSM) de cette manière. Il est même possible de configurer un renouvellement automatique.

Continuer la lecture

Les contrôleurs de domaine ne vérifient pas l'utilisation étendue de la clé lors de la connexion par carte à puce.

Quiconque souhaite utiliser la fonction Smartcard Logon dans l'entreprise a tout intérêt à veiller à ce que la sécurité de son autorité de certification soit aussi renforcée que possible. Cela implique quelques mesures essentielles :

Suppression de tous les certificats d'autorité de certification inutiles de l'objet NTAuthCertificates dans Active DirectoryChaque autorité de certification qui se trouve dans ce magasin est autorisée à émettre des certificats de connexion de carte à puce dans l'Active Directory pour l'ensemble de la structure.
Utiliser la subordination qualifiéeLimiter les certificats d'autorité de certification afin de ne leur faire confiance que pour les extended key usages effectivement délivrés. En cas de compromission de l'autorité de certification, le dommage est alors limité à ces Extended Key Usages. Le "Smart Card Logon" Extended Key Usage ne serait alors présent que dans le certificat d'autorité de certification de l'autorité de certification qui délivre effectivement de tels certificats.

Ce qui est intéressant dans ces réflexions, c'est que les contrôleurs de domaine ne vérifient pas du tout les Extended Key Usages lors de la connexion via carte à puce.

Continuer la lecture

Quelles conditions doivent être remplies du côté de l'infrastructure pour que les inscriptions par carte à puce soient possibles ?

Pour qu'une inscription par carte à puce réussisse, certaines conditions doivent être remplies dans l'environnement Active Directory :

Continuer la lecture

Suppression des extensions spécifiques à ADCS des certificats

Si l'on utilise Active Directory Certificates, on remarque que les certificats des autorités de certification et les certificats qu'elles émettent comportent certaines extensions qui ne sont pas définies dans les RFC pertinents et qui sont spécifiques à AD CS.

Continuer la lecture

Règles de pare-feu requises pour Active Directory Certificate Services

Si l'on implémente une autorité de certification intégrée à Active Directory, il est souvent nécessaire de planifier les règles de pare-feu à créer sur le réseau. Voici une liste des règles de pare-feu nécessaires et des éventuels pièges à éviter.

Continuer la lecture