La PKI (public key infrastructure) Windows .NET Server supporte la définition et l'imposition des contraintes de noms, de la policy applicative, et des règles de policies d'émission, conformément aux stipulations de l'Internet Engineering Task Force (IETF) Request for Comments (RFC) 2959 (disponible à http://www.ietf.org). RFC 2459 définit des extensions de
Règles de policy de PKI .Net Server
certificats spécifiques qui contiennent des informations
précises sur la règle de policy de PKI. Pour imposer ces règles au
moment de la validation des certificats, le logiciel côté client doit comporter
du code supplémentaire. Au moment où nous écrivons ces
lignes, ce code n’existe que dans les clients Windows XP. Microsoft
pourrait fournir des outils spéciaux ou des extensions logicielles spéciales
pour les anciens clients Windows.
Vous ne pouvez appliquer des règles de contraintes de noms
qu’aux certificats CA (Certificate Authority). Ces règles définissent un
espace de nom ; tous les noms sujets de certificats que le CA ou ses
CA subordonnés émettent, doivent résider dans ces namespaces. Vous
pouvez fonder la spécification du namespace sur les noms DNS, les DN (distinguished names) X.500, les adresses e-mail ou les adresses
IP. Un CA subordonné ne peut que réduire – jamais étendre – la règle
de contraintes de noms reçues de son CA parent.
Les règles de policy d’application définissent quelles applications
peuvent utiliser un certificat particulier. Un OID (Object Identifier) identifie
une règle de policy d’application. L’extension de certificat Application
policy remplace l’extension EKU (Enhanced Key Usage) des
certificats Windows 2000.
Les règles de policies d’émission définissent les conditions sous
lesquelles un CA peut émettre un certificat. Dans .NET Server, ces
règles se trouvent dans l’extension de certificat Certificate policies.
Comme la règle de policy d’application, un OID identifie les règles de
policies d’émission. Une telle règle peut contenir des restrictions quant
à la manière dont le CA identifie l’utilisateur au moment de la
demande de certificat, ou sur la manière dont la clé privée est stockée
(par exemple, sur une carte intelligente). Le tableau A résume les trois
niveaux de règles de policies d’émission prédéfinis : bas, moyen, et
haut. Le niveau bas convient pour une règle de policies d’émission
intranet classique. Les deux autres niveaux sont destinés à des policies
d’émission pour extranet, Internet ou intranet avancé.
Comme les versions PKI Windows précédentes, la PKI .NET Server
supporte également des règles de policy de contrainte basiques. Ces
règles définissent si le sujet d’un certificat est un CA et peuvent limiter
la longueur du chemin de chaîne du certificat que le logiciel PKI utilise
pendant la validation de la chaîne.
| Niveau de policies d’émission | Identification utilisateur | Stockage des clefs privés |
| Bas | Références domaine ; accorde l’approbation automatique | Logiciel |
| Moyen | Autorité d’enregistrement ; demande l’intervention de l’administrateur ; l’émission demande généralement un face à face avec l’utilisateur |
Matériel |
| Haut | Autorité d’enregistrement ; demande l’intervention de l’administrateur ; l’émission demande généralement des vérifications supplémentaires concernant l’utilisateur |
Matériel |
Téléchargez cette ressource
Guide de Threat Intelligence contextuelle
Ce guide facilitera l’adoption d’une Threat Intelligence - renseignement sur les cybermenaces, cyberintelligence - adaptée au "contexte", il fournit des indicateurs de performance clés (KPI) pour progresser d' une posture défensive vers une approche centrée sur l’anticipation stratégique
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Analyse Patch Tuesday Mars 2026
- Une nouvelle ère de la modernisation du mainframe
- Akamai Technologies déploie sa stratégie de protection en ligne
- Baromètre channel IT : fin du cuivre, essor de UCaaS et premiers pas vers l’IA
Articles les + lus
Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
Moderniser le développement logiciel : de la fragmentation à l’intégration
Analyse Patch Tuesday Mars 2026
Une nouvelle ère de la modernisation du mainframe
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
À la une de la chaîne Tech
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
- Moderniser le développement logiciel : de la fragmentation à l’intégration
- Analyse Patch Tuesday Mars 2026
- Une nouvelle ère de la modernisation du mainframe
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
