Inclure les directives d'émission (Issuance Policies) pour la Trusted Platform (TPM) Key Attestation dans un certificat d'autorité de certification

Si l'on installe une autorité de certification émettrice (Issuing CA) et que l'on ne demande pas explicitement une politique d'émission (Issuance Policy), le certificat d'autorité de certification qui en résulte ne contient pas de politique d'émission.

Si l'on souhaite inclure les directives d'émission (Issuance Policies) pour Trusted Platform (TPM) Key Attestation dans le certificat d'autorité de certification, il faut procéder comme suit.

Continuer la lecture de « Die Ausstellungsrichtlinien (Issuance Policies) für Trusted Platform (TPM) Key Attestation in ein Zertifizierungsstellen-Zertifikat aufnehmen »

Déterminer et exporter un certificat d'approbation du module TPM (Trusted Platform Module)

Si l'on souhaite utiliser la Trusted Platform Module (TPM) Key Attestation, on a l'option d'attester le TPM entre autres par le biais du certificat d'endossement (EkCert). La manière d'obtenir cette information est décrite ci-dessous.

Continuer la lecture de « Ermitteln und Exportieren eines Trusted Platform Module (TPM) Endorsement Zertifikats »

Déterminer la somme de contrôle (hash) d'une clé d'endossement Trusted Platform (TPM)

Si l'on souhaite utiliser l'attestation de clé du Trusted Platform Module (TPM), on a l'option d'attester le TPM entre autres par la clé d'endossement (EkPub). La manière d'obtenir cette information est décrite ci-dessous.

Continuer la lecture de « Die Prüfsumme (Hash) eines Trusted Platform (TPM) Endorsement Key ermitteln »

Utilisations étendues des clés (Extended Key Usages) et politiques d'émission (Issuance Policies) fréquemment utilisées

Voici une liste des utilisations de clés étendues (Extended Key Usage) et des politiques d'émission (Issuance Policies) fréquemment utilisées dans la pratique pour restreindre les certificats d'autorité de certification.

Continuer la lecture de « Häufig verwendete erweiterte Schlüsselverwendungen (Extended Key Usages) und Ausstellungsrichtlinien (Issuance Policies) »

La connexion via carte à puce échoue avec le message d'erreur "The revocation status of the authentication certificate could not be determined".

Supposons le scénario suivant :

  • Un utilisateur dispose d'un Connexion par carte à puce et se connecte au domaine Active Directory avec ce certificat.
  • La connexion échoue. Le message d'erreur suivant est renvoyé à l'utilisateur sur son ordinateur :
The revocation status of the authentication certificate could not be determined.
Continuer la lecture de « Die Anmeldung via Smartcard schlägt fehl mit Fehlermeldung „The revocation status of the authentication certificate could not be determined.“ »

Renouveler les certificats d'autorité d'enregistrement (RA) pour le service d'enregistrement des périphériques réseau (NDES)

Lorsque NDES est en service depuis un certain temps (typiquement deux ans), on est confronté au défi de renouveler les certificats Registration Authority (RA). Ce processus n'est malheureusement pas forcément résolu de manière intuitive et est donc décrit plus en détail dans cet article.

Continuer la lecture de « Die Registration Authority (RA) Zertifikate für den Registrierungsdienst für Netzwerkgeräte (NDES) erneuern »

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 de « Der Registrierungsdienst für Netzwerkgeräte (NDES) protokolliert die Fehlermeldung „The Network Device Enrollment Service cannot retrieve one of its required certificates (0x80070057). The parameter is incorrect.“ »

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 de « Erstellen einer virtuellen Smartcard in einem Hyper-V Gastsystem »

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 de « Domänencontroller-Zertifikatvorlagen und Smartcard Anmeldung »

(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 de « (Neu-) Installieren der Microsoft Standard Zertifikatvorlagen »

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 de « Angriffsvektor auf den Active Directory Verzeichnisdienst über den Smartcard Logon Mechanismus »

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 de « Grundlagen: Einschränken der erweiterten Schlüsselverwendung (Extended Key Usage, EKU) in Zertifizierungsstellen-Zertifikaten »

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 de « Welche Schlüssellängen sollten für Zertifizierungsstellen und Zertifikate verwendet werden? »

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 de « Erzeugen einer RFC 2818 konformen Zertifikatanforderung für SSL Zertifikate »

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 de « Gerätevorlage für den Registrierungsdienst für Netzwerkgeräte (NDES) konfigurieren »
fr_FRFrançais