Gestion des Autorités de certification
Introduction :
Le document souligne l'importance d'une infrastructure à clé publique pour sécuriser les
communications et les transactions sur Internet. L'authentification utilisateur, la non-
répudiation, la confidentialité et l'intégrité des données sont assurées grâce à l'échange de
certificats numériques entre utilisateurs et ressources de confiance.
Infrastructure à clé publique (PKI)
Définition :
"Une infrastructure à clé publique est une combinaison d'applications et de technologies de
cryptage qui permettent aux organisations de sécuriser leurs communications et leurs
transactions commerciales. Ce type d'infrastructure repose sur l'échange de certificats
numériques entre des utilisateurs authentifiés et des ressources approuvées."
Avantages :
Confidentialité : Cryptage des données stockées et transmises.
Intégrité : Signature numérique pour détecter toute modification des données.
Non-répudiation : La signature numérique prouve l'origine des données et ne peut être
réfutée.
Disponibilité : Possibilité d'installer plusieurs Autorités de certification pour garantir la
continuité de service.
Composants :
Certificat numérique : Informations d'identification électronique utilisées pour
l'authentification.
Autorité de certification : Entité chargée d'émettre et de gérer les certificats.
Modèle de certificat : Définit le contenu et le rôle d'un certificat.
Liste de révocation de certificats : Liste des certificats révoqués avant leur date
d'expiration.
Points de distribution de l'accès aux informations de l'Autorité et de la liste de révocation
de certificats :
- Emplacements où les clients peuvent accéder aux informations de l'Autorité de
certification et aux listes de révocation de certificats.
- L'extension d'accès aux informations de l'Autorité (AIA, Authority Information
Access) indique où trouver les certificats les plus récents pour l'Autorité de
certification.
- L'extension de point de distribution de la liste de révocation de certificats (CDP, CRL
Distribution Point) indique où trouver les dernières listes CRL signées par l'Autorité
de certification.
Outils de gestion des certificats et des Autorités : Certains outils comportant à la fois
une interface utilisateur graphique et des outils de ligne de commande permettent de
gérer les certificats émis, de publier les certificats des Autorités de certification et les
listes CRL, de configurer les Autorités de certification, d'importer et d'exporter des
certificats et des clés, et de récupérer des clés privées archivées
Applications utilisant une PKI : Une infrastructure à clé publique Windows Serveur prend
en charge les types d'applications PKI suivants :
- Signatures numériques
- Ouverture de session par carte à puce
- Courrier électronique sécurisé
- Signature du code logiciel
- Sécurité IP (IPSec)
- 802.1x (authentification réseau)
- Stratégie de restriction logicielle
- Authentification Internet
- Système de fichiers EFS
Outil PKI
Les outils de gestion des certificats et des autorités sont essentiels pour administrer et
dépanner une infrastructure à clé publique (PKI). Windows Server fournit une variété de ces
outils, notamment :
Composants logiciels enfichables MMC (Microsoft Management Console) :
Modèle de certificat :
Permet la création, la modification et la gestion de tous les modèles de
certificats dans une forêt Windows Server. Principalement utilisé par
les administrateurs des AC.
Autorité de certification :
Permet la gestion des AC et des certificats qu'elles émettent. Il permet
de modifier la configuration des AC, de gérer les certificats émis et de
publier des listes de révocation de certificats.
Certificats :
Permet de gérer le magasin de certificats local pour les utilisateurs, les
ordinateurs ou les services. On peut demander, supprimer et gérer les
certificats délivrés à son compte d'utilisateur ou d'ordinateur.
Outils de ligne de commandes :
Certutil.exe :
Vous permet de créer des scripts pour automatiser les tâches de
gestion des Autorités de certification et des certificats, notamment la
gestion de l'Autorité, la publication de la liste de révocation de
certificats et des certificats des Autorités, la révocation de certificats et
la récupération de clés privées archivées
Certreq.exe :
Vous permet de créer des scripts pour automatiser les demandes de
certificats à une Autorité de certification et de générer des demandes
de certificats aux points de distribution de certificats croisés
Outils du Kit de ressources techniques :
Outil de récupération de clé (Krt.exe) :
Permet de définir des agents de récupération de clé et de
récupérer des éléments de clés privées archivées dans la base
de données de l'AC.
Outil d'état PKI (Pkiview.msc) :
Permet de valider les adresses URL des points de distribution de
la liste de révocation de certificats et des points d'accès aux
informations de l'autorité pour chaque AC de la hiérarchie
d'une organisation.
Outils de programmation :
CryptoAPI :
Une interface API avec un ensemble de fonctions
permettant aux applications de chiffrer ou de signer
numériquement des données par programmation.
CapiCOM :
Un ensemble plus petit d'interfaces API permettant aux
applications de chiffrer ou de signer numériquement des
données avec beaucoup moins de code que CryptoAPI.
Que sont les Autorités de Certification ?
Les Autorités de Certification (AC) sont des serveurs qui délivrent, gèrent et révoquent des
certificats numériques dans une infrastructure à clé publique (PKI). Ces certificats
garantissent :
- Authenticité : Vérifier l'identité d'une entité (utilisateur, ordinateur, ou service).
- Intégrité : Assurer que les informations ou communications n'ont pas été altérées.
- Non-répudiation : Preuve de l'origine des données signées.
L'AC signe les certificats numériques qu'elle délivre à l'aide de sa propre clé privée, et elle
publie les listes de révocation (CRL) contenant les certificats invalides.
Différences entre types d'Autorités de Certification
Windows Server prend en charge deux types d'AC, selon leur contexte et usage :
Différences entre types d'Autorités de Certification
Il existe plusieurs conceptions de hiérarchies d'Autorités de certification. La conception d'une
hiérarchie d'Autorités de certification dépend des besoins (usage des certificats, etc.), de la
structure, de l'emplacement et des processus d'une organisation
Hiérarchie des Autorités de Certification
Les infrastructures PKI sont souvent organisées en une hiérarchie afin de segmenter les
responsabilités et renforcer la sécurité :
Autorité racine :
- La base de la confiance dans la PKI.
- Souvent hors ligne pour limiter les risques d'altération.
- Elle délivre des certificats uniquement aux Autorités secondaires.
Autorités de stratégies (facultatives) :
- Situées entre l'AC racine et les AC émettrices.
- Définissent des règles spécifiques pour différents usages (certificats
d’authentification, chiffrement, etc.).
Autorités émettrices :
- Chargées de délivrer les certificats aux utilisateurs, ordinateurs, et services.
- Elles fonctionnent en ligne et assurent une disponibilité maximale.
Installation et configuration des Autorités de Certification
1. Le fichier CAPolicy.inf
Le fichier CAPolicy.inf permet de personnaliser l'installation d'une AC en
fournissant :
- La déclaration CPS (Certification Practice Statement) : Une déclaration relative aux
méthodes utilisées par l'Autorité de certification pour émettre des certificats. Cette
déclaration reflète la stratégie de certificat et la stratégie de sécurité de
l'organisation
- Les points de distribution des listes de révocation.
- La durée de validité et les tailles des clés des certificats.
- Les seuls paramètres obligatoires d'un fichier CAPolicy.inf sont les deux premières
lignes qui définissent la version de l'Autorité de certification.
2. Installation d'une Autorité secondaire d’entreprise
o Soumettre une demande de certificat à l'AC parent (par fichier ou en ligne).
o Installer les services de certificats, configurer la base de données, et importer
le certificat signé.
o Démarrer les services de certificats pour rendre l’AC opérationnelle.
Gestion d'une Autorité de certification
La gestion des AC est cruciale pour garantir la sécurité et le bon fonctionnement des
services PKI. Les administrateurs doivent :
- Publier et révoquer les certificats : Assurer que seuls les certificats valides sont
utilisés.
- Créer et gérer les modèles de certificats : Personnaliser les paramètres (ex. : usage,
durée).
- Publier les CRL et points d'accès : Rendre disponibles les informations sur les certificats
révoqués.
Comment les applications vérifient-elles l'état des certificats ?
Quand un certificat est présenté à une application, l'application doit d'abord déterminer la
validité du certificat avant de pouvoir utiliser ce dernier pour crypter des données ou
authentifier le sujet du certificat. Pour accomplir cette tâche, l'application doit être
configurée pour utiliser la fonctionnalité CryptoAPI de Windows Serveur. CryptoAPI fournit
tous les services nécessaires à une application pour garantir la validité d'un certificat
Processus de validation CryptoAPI:
- Détection de certificats
- Validation de chemin d'accès
- Vérification de révocation
Validation des certificats
Lorsqu'un certificat est présenté à une application, celui-ci passe plusieurs tests :
- Validité temporelle : Vérifier que la date actuelle est dans la plage de validité.
- Authenticité : Assurer que le certificat est signé par une AC approuvée.
- Vérification de révocation : Confirmer que le certificat ne figure pas dans les CRL.
- Extensions critiques : Les extensions obligatoires (ex. : Contraintes de base)
doivent être présentes et correctes.
Révocation de certificats
Un certificat peut être révoqué avant sa date d'expiration pour des raisons comme :
KeyCompromise : L’intégrité de la clé privée qui est associée au certificat est
compromise et la clé est tombée en la possession d’une personne non autorisée, par
exemple si un ordinateur portable a été volé ou une carte à puce a été perdue.
CACompromise : L’intégrité de la carte à puce ou du disque où est stockée la clé
privée de l’Autorité de certification est compromise et la carte à puce ou le disque
sont tombés en la possession d’une personne non autorisée.
AffiliationChanged : Une personne a été licenciée ou a démissionné d’une
organisation.
Superseded : Un nouveau certificat doit être publié en cas d’échec d’une carte à puce
ou de modification du nom légal d’un utilisateur.
CessationOfOperation : Si votre organisation déclasse une Autorité de certification,
utilisez ce code de révocation pour révoquer le certificat de l’Autorité.
CertificateHold : Révocation temporaire qui indique qu’une Autorité de certification
n’attestera pas de l’intégrité d’un certificat à un moment donné.
RemoveFromCRL : Si vous révoquez un certificat au motif CertificateHold, vous
pouvez lever la révocation du certificat. Ce code est propre au motif de révocation
CertificateHold, et est seulement utilisé dans les listes de révocation de certificats
delta
Unspecified : Vous pouvez révoquer un certificat sans fournir de code de révocation
spécifique.
Publication des listes CRL
Deux types de listes de révocation existent :
- Liste CRL de base : Contient tous les certificats révoqués par l'AC.
- Liste CRL delta : Contient uniquement les certificats révoqués depuis la
dernière CRL de base.
Les CRL sont publiées à des intervalles planifiés pour garantir la disponibilité et
minimiser le trafic réseau.
La période de publication de la liste CRL définit à quel moment une Autorité
publiera automatiquement une liste CRL mise à jour.
Où publier les points de publication de la liste de révocation de certificats
Après avoir installé une Autorité de certification racine, vous devez configurer deux
champs d'extension X.509 version 3, à savoir l'extension d'accès aux informations de
l'Autorité (AIA) et l'extension de point de distribution de la liste de révocation de
certificats (CDP). Ces extensions s'appliquent à tous les certificats émis par l'Autorité
racine.
Elles définissent les emplacements où les applications clientes peuvent trouver des
informations valides relatives à l'accès aux informations de l'Autorité et aux points de
distribution de la liste CRL pour l'Autorité racine.
Par contre, il y a une différence entre les Autorités hors connexion et les Autorités en
ligne : les Autorités hors connexion requièrent la publication manuelle des certificats et
des listes de révocation de certificats sur un annuaire ou un serveur Web
Points de publication :
Pour garantir que tous les ordinateurs de la forêt puissent accéder aux informations,
publiez le certificat et la liste de révocation de certificats de l’autorité de certification
racine hors connexion sur Active Directory en utilisant la commande certutil. Cette
commande place le certificat et la liste CRL de l’autorité racine dans le contexte de
configuration/appellation qui est répliqué par Active Directory vers tous les
contrôleurs de domaine de la forêt.
Externe :
Si certains de vos utilisateurs ne sont pas membres de votre organisation, mais ont
tout de même besoin d'accéder à la liste de révocation de certificats, vous devez
décider de quelle façon vous allez mettre la liste CRL à leur disposition en externe.
Pour placer le certificat et la liste de révocation de certificats de l’autorité de
certification sur des serveurs web externes, vous pouvez utiliser le protocole LDAP, le
protocole FTP (File Transfer Protocol), un emplacement de disque dur (appelé
FICHIER) ou le protocole HTTP (Hypertext Transfer Protocol). Toutefois, HTTP est le
protocole le plus répandu pour mettre les listes CRL à disposition des clients externes.
Voici quelques-unes des raisons motivant l'utilisation du protocole HTTP :
- Les requêtes LDAP nécessitent que tous les clients externes soient compatibles
avec Active Directory.
- Les clients Active Directory externes doivent disposer d’autorisations pour
pouvoir interroger Active Directory en utilisant le protocole LDAP.
- La publication HTTP ne présente aucun problème de latence.
- Si vous utilisez le protocole LDAP, les pare-feux des clients et des serveurs
doivent être configurés pour permettre l’accès à Active Directory et l’accès FTP.
- Le protocole HTTP est généralement ouvert sur les pare-feux.
- Vous pouvez également publier les certificats et les listes de révocation de
certificats sur des adresses URL FTP:// et FICHIER://.
- Toutefois, il est recommandé d’utiliser seulement des adresses URL LDAP et
HTTP, parce que ce sont les formats URL les plus couramment pris en charge à
des fins d’interopérabilité.
Sauvegarde et restauration des Autorités de Certification
Une bonne gestion PKI nécessite des sauvegardes régulières pour éviter la perte de
données critiques en cas d'incident :
- Sauvegarde de l'état du système : Inclut les clés, la base de données des
certificats, les journaux, la métabase IIS et tous les paramètres de Registre des
services de certificats
- Sauvegarde manuelle : Inclut uniquement les éléments essentiels comme les
clés, la base de données des certificats et les fichiers journaux, mais elle
n’inclut ni la métabase IIS, ni les paramètres de Registre des services de
certificats
- Remarque En plus de la sauvegarde de l'état du système, envisagez de
sauvegarder manuellement la clé privée et la clé publique de l'Autorité de
certification dans un fichier PKCS #12.