Integration OpenCA W2k PKI

Intégration d’une PKI tierce(OpenCA)
dans un domaine Windows 2000.
P a s c a l G a c h e t –E I V D
pascal.gachet@eivd.ch
décembre 2002
Intégration d’une PKI tiers dans un domaine Windows 2000 - 2 –
Résumé
Ce document décrit de manière générale, les différentes étapes permettant l’intégration d’une
PKI non-Microsoft dans un domaine Windows 2000, en vue d’une authentification smart
card logon basée sur pkinit.
De manière spécifique, la PKI réellement intégrée dans le domaine Windows 2000 est le
produit OpenCA qui utilise largement les fonctionnalités cryptographies d’OpenSSL.
Tables des matières
Résumé..................................................................................... 2
1 Introduction......................................................................... 3
2 Pré-requis............................................................................ 4
2.1 Publication du certificat root dans le fichier Ntauth ......................... 4
2.2 Ajout de la CA root à la liste Entrepri se trust list ............................. 7
2.3 Génération du certificat pour le contrôleur de domaine. ................... 8
2.4 Création d’un nouveau rôle « kdc » ................................................ 10
2.4.1 Définition d’une politique de certificat pour le rôle kdc ........... 11
2.4.2 Ajout des extensions spécifiques à un contrôleur de domaine
microsoft. 11
2.5 Prise en charge de la requête depuis OpenCA ................................. 12
2.6 Installation du certificat contrôleur de domaine ............................. 14
2.7 Publication du certificat dans Active Directory .............................. 14
2.8 Création d’un nouveau rôle « clientMS » ........................................ 15
2.9 Création puis installation du certificat utilisateur sur le support
hardware .................................................................................................... 16
3 Annexe (extensions) ............................................................. 18
3.1 Kdc.ext ......................................................................................... 18
3.2 UserMs.ext .................................................................................... 18
4 Annexe (policy) ................................................................... 19
4.1 Kdc.conf....................................................................................... 19
4.2 UserMs.conf ................................................................................. 21
1 Introduction
Les mécanismes d’authentification et de contrôle des droits d’accès dans un domaine

Windows 2000 se basent sur le protocole Kerberos et l’annuaire Active directory.
Dans un scénario de login traditionnel, l’utilisateur introduit son nom d’utilisateur et un mot
de passe. En réalité, une empreinte du mot de passe est transférée par le réseau. Le contrôleur
de domaine Windows 2000 vérifiera les informations utilisateurs en comparent l’empreinte du
mot de passe utilisateur contenu localement sur le contrôleur avec l’empreinte passée par
l’utilisateur lors du login.
La fonctionnalité smart card logon permet de renforcer sensiblement la procédure de login en

remplacent le mot de passe par un certificat numérique contenu dans une smart card
hardware.
L’authentification de l’utilisateur se base toujours sur le mécanisme centralisé Kerberos
version 5, mais il nécessite une reconnaissance réciproque du client et du contrôleur de
domaine par une signature numérique et l’échange des certificats x509 utilisés pour la
signature (voire document Pkinit VS MD5 ).
Pour rendre possible cette politique de login par authentification forte, il est nécessaire
d’intégrer les mécanismes PKI au cœur même du système Windows 2000.
Microsoft fournit différents outils permettant de mettre sur pied une autorité de certification
privée « Microsoft CA » l’intégration de cet élément au cœur d’active directory comme
mécanisme d’authentification supplémentaire permet également d’adapter le protocole
Kerberos aux nouveaux mécanismes PKI.
De façon incontestable, l’ajout des mécanismes PKI dans un domaine W2K accroît la sécurité
globale de tout le système. Mais de nombreuses cont roverses concernant la sécurité ou la non
sécurité des équipements Microsoft, notamment sur un accort secret entre la NSA et
Microsoft, ont mis en évidence le besoin de remplacer toutes applications Microsoft sensées
garantir la confidentialité par des applications développées par d’autres constructeurs, jugés
plus sûr, ce qui s’applique particulièrement à la CA de Microsoft.
Malgré cet état des lieux, il est nécessaire d’installer la CA Microsoft en premier lieu pour
bénéficier des mécanismes additionnels apportés à Kerberos lors de cette installation. En
second lieu, la CA Microsoft proprement dite sera remplacée par notre propre autorité de
certification OpenCA dont nous contrôlons parfaitement l’intégrité.
2 Pré-requis
La procédure de smart card logon décrite dans ce document ne peut être mise en œuvre
uniquement si les composants suivants ont été préalablement installés
• Un contrôleur de domaine Windows 2000 est installé, le droit administrateur de

domaine est requis.
• Le service pack 2 doit être installé sur le contrôleur de domaine.
• Active directory est présent ainsi qu’un serveur DNS.
• Les services de certification Microsoft sont installés sur le contrôleur de domaine, ce
qui sous-entend que la CA Microsoft est installée dans le domaine.
• La PKI OpenC A est installée et accessible depuis le domaine.
Pour intégrer une PKI tiers dans le domaine Windows 2000, il est nécessaire d’utiliser au
préalable la CA Microsoft. En analysant les éléments spécifiques générés par la CA Microsoft
dans le système, il est possible de substituer la CA Microsoft par la CA tiers en dupliquant
tous les éléments nécessaires au système Microsoft.
De façon plus précise, le contrôleur de domaine, comme les clients smart card logon
requièrent des certificats au profil bien particulier pour être reconnus mutuellement lors de
l’authentification Kerberos.
L’intégration de la CA tiers suit la procédure suivante :
• Publication du certificat root de la CA tiers dans la liste des certificats de confiance

root du contrôleur de domaine(Ntauth).
• Publication du certificat root dans la liste entreprise trust.
• Génération d’une requête de certificat pour le contrôleur de domaine.
• Création d’un nouveau rôle OpenCA spécifique au contrôleur de domaine.
• Prise en charge de la requête de certificat dans la PKI OpenCA.
• Génération et installation du certificat contrôleur de domaine.
• Requête d’un certificat utilisateur.
• Création d’un nouveau rôle OpenCA spécifique aux clients smart card logon.
• Création puis installation du certificat utilisateur sur le support hardware.
2.1 Publication du certificat root dans le fichier Ntauth
Pour que le contrôleur de domaine autorise une ouverture de connexion smart card logon, il
est nécessaire qu’il reconnaisse le certificat root. Le contrôleur de domaine ne reconnaît que
les autorités contenues dans Ntauth (et non pas la liste contenue dans Entreprise trust list). A
ce stade le fichier Ntauth ne contient que le certificat de la CA microsoft.
Dans cette étape il s’agira d’ajouter par le protocole LDAP le nom de la CA tiers et le
certificat proprement dit.
Le document fournit par Microsoft décrit précisément cette procédure

(how to import a third-party certificate into the Ntauth Store Q295663)
Le fichier Ntauth est un objet dans le contener Configuration, le DN (distinguish name) de

cet objet est le suivant.
CN=NTAuthCertificates,CN=PublicKey
Services,CN=Services,CN=Configuration ;DC=MyDomain,DC=com
Pour ajouter le certificat root à l’objet Ntauth, la stratégie proposée par Microsoft consiste à
générer un fichier ldif contenant le DN de la CA et son certificat, puis de modifier l’objet à
l’aide des utilitaires ldap fournis par Microsoft, ce qui aura pour but d’ajouter le certificat à
l’annuaire Ldap.
1. Le certificat root doit préalablement être convertit en forma t base-64.
L’utilitaire certutil installé avec les outils Windows 2000 Certification Service
permettra d’effectuer cette conversion de type.
certutil –encode inputfile outputfile.
La variable inputefile contient le lien sur le certificat root en format DER et

outputfile contient le lien sur le certificat base-64 à créer.
2. Création du fichier ldif
La façon la plus simple de créer un fichier ldif aussi trivial, consiste à introduire les
données suivantes avec le Notepad de Microsoft.
dn :CN=NTAuthCertificates,CN=PublicKey
Services,CN=Services,CN=Configuration ;DC=MyDomain,DC=com
Changetype: modify
Add: cACertificate
CAcertificate::
<encoded certificate>
-
Le certificat au format base-64 créé précédemment doit être introduit dans le champ
<encoded certificate>, il ne doit pas contenir les rubriques begin
Certificate et end certificate.
Chaque ligne du certificat doit débuter par un espace et le certificat doit
impérativement se terminer par un retour de chariot et le caractère trait d’union.
dn:CN=NTAuthCertificates,CN=PublicKey
Services,CN=Services,CN=Configuration,DC=MyDomain,DC=com
changetype: modify
add: cACertificate
cACertificate::
MIIDkjCCAzygAwIBAgIQUGI7+cbSDadN3AcuClPjEjANBgkqhkiG9w0BAQUFADC
BkTEcMBoGCSqGSIb3DQEJARYNYWRtaW5Aai5sb2NhbDELMAkGA1UEBhMCVVMxFz
AVBgNVBAgTDk5vcnRoIENhcm9saW5hMRIwEAYDVQQHEwlDaGFybG90dGUxEjAQB
gNVBAoTCU1pY3Jvc29mdDEMMAoGA1UECxMDTVBTMRUwEwYDVQQDEwxFbnRlcnBy
aXNlQ0EwHhcNMDEwNDA1MjM1ODE3WhcNMjEwNDA2MDAwNDQyWjCBkTEcMBoGCSq
GSIb3DQEJARYNYWRtaW5Aai5sb2NhbDELMAkGA1UEBhMCVVMxFzAVBgNVBAgTDk
5vcnRoIENhcm9saW5hMRIwEAYDVQQHEwlDaGFybG90dGUxEjAQBgNVBAoTCU1pY
3Jvc29mdDEMMAoGA1UECxMDTVBMRUwEwYDVQQDEwxFbnRlcnByaXNlQ0EwXDANB
gkqhkiG9w0BAQEFAANLADBIAkEA3M8E1gV1vgo8UnGuTT/g6JFJS3IxzTqDV3yF
pxtcXN9kUZhHT1xa0xf1L7Dx/7t7qzwUBytkeLLmHoCiyEnd/wIDAQABo4IBbDC
CAWgwEwYJKwYBBAGCNxQCBAYeBABDAEEwCwYDVR0PBAQDAgFGMA8GA1UdEwEB/w
QFMAMBAf8wHQYDVR0OBBYEFLAFj6XPYTQjNzPuJFYGIeHKpxlCMIIBAAYDVR0fB
IH4MIH1MIG4oIG1oIGyhoGvbGRhcDovLy9DTj1FbnRlcnByaXNlQ0EsQ049ai1k
Yy0wMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vydml
jZXMsQ0492Q9uZmlndXJhdGlvbixEQz1qLERDPWxvY2FsP2NlcnRpZmljYXRlUm
V2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RjbGFzcz1jUkxEaXN0cmlidXRpb25Qb
2ludDA4oDagNIYyaHR0cDovL2otZGMtMDEuai5sb2NhbC9DZXJ0RW5yb2xsL0Vu
dGVycHJpc2VDQS5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJKoZIhvcNAQEFBQA
DQQDC1vPF7ZpnovlZMU8hTCKK8VNpexCOX0dpuQ6cy7VnpTsCehxM/fJkcGOwNY
AiSjTf9QfxK1yR/yhVnE7iMxHn
-
3. Sauvegarder le fichier comme Ntauth.ldf.
4. Utiliser l’utilitaire ldifde.exe pour importer le fichier dans Active Directory. Cet
utilitaire est installé par défaut avec Windows 2000 Server.
ldifde –i –f ntauth.ldf
5. Mettre à jour la GPO de domaine afin que la nouvelle CA soit connue de tous les
clients du domaine. Cette mise à jour s’effectue par l’outil dsstore contenu dans
Windows 2000 resource kit
dsstore –pulse
6. Il est souhaitable de vérifier que le certificat a bien été intégré au fichier Ntauth en
utilisant l’utilitaire certmgr.
certmgr –s –r localMachine ntauth
Le résultat de cette commande affiche les données contenues dans le fichier ntauth.
==============Certificate # 1 ==========
Subject::
[0,0] 1.2.840.113549.1.9.1 (E) admin@mydomain.com

[1,0] 2.5.4.6 (C) US
[2,0] 2.5.4.8 (S) Washington
[3,0] 2.5.4.7 (L) Redmond
[4,0] 2.5.4.10 (O) Microsoft
[5,0] 2.5.4.11 (OU) PSS
[6,0] 2.5.4.3 (CN) My Enterprise CA
Issuer::
[0,0] 1.2.840.113549.1.9.1 (E) admin@mydomain.com
[1,0] 2.5.4.6 (C) US
[2,0] 2.5.4.8 (S) Washington
[3,0] 2.5.4.7 (L) Redmond
[4,0] 2.5.4.10 (O) Microsoft
[5,0] 2.5.4.11 (OU) PSS
[6,0] 2.5.4.3 (CN) My Enterprise CA
SerialNumber::
50 62 3B F9 C6 D2 0D A7 4D DC 07 2E 0A 53 E3 12
SHA1 Thumbprint::
A357B06E 6EA9E2F9 C892FE1B 43BED0A5 AB0A081F
MD5 Thumbprint::
2948B478 D9D6A967 8AA8B247 AAD2690E
NotBefore::
Thu Apr 05 19:58:17 2001
NotAfter::
Mon Apr 05 20:04:42 2021
==============No CTLs ==========
==============No CRLs ==========
==============================================
CertMgr Succeeded
2.2 Ajout de la CA root à la liste Entreprise trust list
Bien que cette étape ne soit pas indispensable pour la procédure de smart card logon, il
est toutefois pertinent d’ajouter le certificat root de la CA à la liste des certificats de confiance
du domaine
Le certificat peut être introduit au format PEM par la commande suivante
Dsstore DC=<domaine>,DC=com –addroot cacert.pem
De cette manière tous les utilisateurs du domaine reconnaîtront par défaut le certificat root de
la CA lors de leur prochain login.
2.3 Génération du certificat pour le contrôleur de

domaine.
Lors de la procédure de smart card logon, le contrôleur de domaine devra également

présenter son certificat au client, car l’authentification mutuelle est nécessaire.
Ce point décrit les étapes à respecter pour générer, puis installer le certificat du contrôleur de
domaine à l’emplacement requis.
Un document fournit par Microsoft, décrit précisément la politique de certificat à imposer au

certificat de type Domain Controller .
(Requirements for Domain Controller Certificates from a Third-Party CA (Q291010))
La manière la plus simple pour générer ce certificat, consiste à effectuer une requête de
certificat (PKCS#10) spécifique depuis la CA Microsoft, puis de transférer cette requête à la
PKI tiers (OpenCA) qui se chargera de signer la requête en ajoutant les extensions et les
contraintes stipulées dans le document Q291919.
1. Intégration du template Router offline request
La requête qui devra être faite par la CA Microsoft sera du type server request
pkcs#10, il est donc nécessaire d’ajouter ce template à la liste des certificates
template reconnue par la CA microsoft.
Start->Programs->Administrative Tools->Certification Authority.
Puis étendre l’arborescence de la CA Microsoft, cliquez avec le bouton droite sur le

répertoire Policy Settings et choisir new.->Certificate to Issue .
Une liste de template apparaît, choisir le template Router (Offline request).

Ce template pourra dés lors être utilisé.
2. Générer une requête de certificat depuis la CA Microsoft.
L’outil d’enrôlement de la CA Microsoft se gère par une interface WEB accessible à

l’URL suivant.
http://<controlleur>.<domaine>.com/certsrv/
Le champ <controleur> correspond au nom du contrôleur de domaine et le champ

<domaine> spécifie le chemin complet du domaine.
Il est nécessaire de se connecter en temps qu’administrateur de domaine. Une fois sur

la page principale choisir Request a certificate puis Next.
Sur la page suivante choisir Advanced request puis Next.
A la page suivante choisir Submit a certificate request to this CA

using a form. puis next.
Le formulaire suivante apparaît (figure 1).
F i g u r e 1 Advanced Certificate Request
• Choisir comme champ certificate template : Router(Offline request)
• Puis introduire les informations concernant le contrôleur de domaine, seul le nom est
nécessaire.
• Dans la section Key Options choisir.

CSP : Microsoft RSA Schannel Cryptographic Provider
Puis cocher l’option Use local machine store .
• Dans l’option Additional Options:
Cocher la case Save request to a PKCS#10 file.

Puis donner l’adresse ou sera stocké la requête.
• Finalement sauver la requête sur le disque.
Remarque : La clé privée est stockée provisoirement dans le CSP, Il est donc absolument
nécessaire d’effectuer les étapes qui suivront sur le même poste avec le même naviga teur
WEB.
Le CSP Schannel permet de générer une paire de clés localement puis de les intégrer sur un
poste distant à travers un canal sécurisé.
A ce stade la CA Microsoft n’est plus nécessaire, la suite de la procédure s’effectuera depuis

la CA tiers OpenCA.
2.4 Création d’un nouveau rôle « kdc »
Pour que le certificat du contrôleur de domaine soit conforme aux exigences Microsoft, il est
nécessaire d’ajouter de nouvelles extensions à introduire dans le certificat du contrôleur.
OpenCA permet de définir différents rôles suivant le profile que l’on désire ajouter aux
certificats.
Depuis le serveur de la CA choisir Certification->Roles
Puis add a new role.
Choisir un nom pour le nouveau rôle, par exemple KDC
Ce scripte générera un fichier kdc.conf qui contient la politique de certification à utiliser sur
ce type de rôle et un fichier kdc.ext qui contient les extensions à ajouter aux certificats dont
le rôle et KDC.
Avant de modifier ces fichiers il est nécessaire d’exporter ce nouveau rôle sur le serveur
public afin qu’il soit disponible lors de l’enrôlement.
Depuis le serveur CA. Input and output->Export Configuration
Puis depuis le serveur de la RA. Input and output->Import Configuration.
Remarque : Ces rôles sont le pendant des Certifications templates de Microsoft

2.4.1 Définition d’une politique de certificat pour le rôle kdc
Les champs contenus dans une requête pkcs#10 n’ont pas pu être contrôlés lors de
l’enrôlement étant donné que cette dernière a été effectuée sur la PKI Microsoft.
Le contrôle de ces champs s’effectuera lors de la signature proprement dite du certificat.

Dans le fichier kdc.conf, sous la rubrique policy match définir une politique assez
souple, juste le champ CN devrait être requit.
[ policy_match ]
countryName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
Une politique de certificat raisonnable pour des certificats de type pkcs#10 consiste à n’exiger
que le champ CN dans la requête.
2.4.2 Ajout des extensions spécifiques à un contrôleur de

domaine microsoft.
Microsoft utilise des extensions propriétaires qu’il est nécessaire d’ajouter au certificat
contrôleur de domaine.
La documentation de Microsoft préconise les recommandations suivantes sur les extensions

du certificat.
• Le certificat doit contenir une extension disposant d’un lien sur une CRL valide de
type ldap ou http
• De manière optionnelle le CN contenu dans le certificat contrôleur de domaine doit
contenir le DN complet du contrôleur.
• L’extension certificate Key Usage section doit contenir les champs
suivants :
Digital signature, Key Encipherment.
• Le certificat doit contenir l’extension enhanced key Usage section avec les
deux champs suivants :
Client authentication(1.3.6.1.5.5.7.3.2)
Server Authentication(1.3.6.1.5.5.7.3.1)
• L’extension Certificate Subject Alternative Name section doit contenir
le champ other name (1.3.6.1.4.1.311.25.1)=GUID, tel que le GUID et
l’identificateur ldap unique du contrôleur de domaine. Cette extension doit également
contenir le champ DNS Name=<controlleur>.<domaine>
• L’extension spécifique certificate template doit contenir le champ
domainController en données BMP.
Etant donné que certaines de ces extensions sont propriétaires, et bien évidement pas connues
d’OpenSSL(version 0.9.6e), la solution pour les intégrer malgré tout au certificat du
contrôleur de domaine, consiste à ajouter l’extension manuellement à l’aide de son OID
ASN1, puis d’introduire les données sous forme de données brutes au format DER. (la
configuration à apporter au fichier kdc.ext est disponible en annexe)
Remarque : Il ne s’agit peut être pas la de la technique la plus élégante, mais étant donné que
parmi les extensions à ajouter, certaines ne respectent pas l’ ASN1, seule cette possibilité est
envisageable.
2.5 Prise en charge de la requête depuis OpenCA
La requête effectuée précédemment à été sauvegardée sur un fichier, le format n’est toutefois
pas conforme au standard pkcs#10 d’OpenSSL.
Il s’agit d’ajouter les entêtes BEGIN CERTIFICATE REQUEST et END CERTIFICATE REQUEST
-----BEGIN CERTIFICATE REQUEST-----

MIICjDCCAjYCAQAwHTEbMBkGA1UEAxMSa2RjdnBuLnZwbi50Y29tdnBuMFwwDQYJ
KoZIhvcNAQEBBQADSwAwSAJBALJb2H1kcmoEaTpfUwIoLZHb7u45bpQAt6kf1u7V
tH8+ETZJJwL/PaCBJuuJuMiWfbnfvfUBN2paFY/Ogale+yUCAwEAAaCCAbIwGgYK
KwYBBAGCNw0CAzEMFgo1LjAuMjE5NS4yMIGTBgorBgEEAYI3AgEOMYGEMIGBMA4G
A1UdDwEB/wQEAwIEMDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAO
BggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwKQYJKwYBBAGCNxQC
BBweGgBPAGYAZgBsAGkAbgBlAFIAbwB1AHQAZQByMIH9BgorBgEEAYI3DQICMYHu
MIHrAgEBHloATQBpAGMAcgBvAHMAbwBmAHQAIABSAFMAQQAgAFMAQwBoAGEAbgBu
AGUAbAAgAEMAcgB5AHAAdABvAGcAcgBhAHAAaABpAGMAIABQAHIAbwB2AGkAZABl
AHIDgYkAUL9Rtrw1nPb5Ys6tk8N+R/ABN/KEC++h4D8MisMagcCve07XEclgvLGC
mQrAdxNc/gcC5nvDUoaciLlI4dIAcZh/ew4jhNqM7mFEeGCN06Tx2UhgZtWXXIqG
aJihWa5KciQvIwF9Nhtw3cii1yQQR8M+iseGxgc+Sq56THPK8RwAAAAAAAAAADAN
BgkqhkiG9w0BAQUFAANBADhfIhjMRBXVfRXzBTYDyz0EV+yF//WqrBQm8t8mJ9iW
UNSmLnl1LpZwDebmpeB1jlafRQEkoAJGlWxDbOt5VAM=
-----END CERTIFICATE REQUEST-----
Depuis le serveur public d’OpenCA choisir Request a Certificate puis Serveur

request (PKCS#10 formated request).
Dans le champ request, choisir le fichier contenant la requête précédemment créée.

Choisir comme champ rôle, le rôle kdc. (Figure 2)
Fig u r e 2 P K C S # 1 1 r e q u e s t
Puis Continue...
La requête sera transmise à la RA puis à la CA en vue d’une signature.
Avant de signer le certificat, il est nécessaire de modifier légèrement le fichier ca.conf. Il

n’est pas conseillé de faire apparaître le numéro de série contenu dans le DN de la requête
(configuration par défaut d’OpenCA).
SET_REQUEST_SERIAL_IN_DN "N"
######################
## support for PKIX ##
######################
SET_REQUEST_SERIAL_IN_DN "N"
REQUEST_SERIAL_NAME "sn"
SET_CERTIFICATE_SERIAL_IN_DN "N"
CERTIFICATE_SERIAL_NAME "serialNumber"
DN_WITHOUT_EMAIL "Y"
AUTOMATIC_SUBJECT_ALT_NAME "Y"
DEFAULT_SUBJECT_ALT_NAME "Email"
A ce stade, le certificat peut être signé par la CA puis transféré au serveur public de façon
traditionnelle.
2.6 Installation du certificat contrôleur de domaine
Pour installer le certificat dans le contrôleur de domaine, la procédure est parfaitement

similaire à une installation conventionnelle.
Depuis le serveur public.
Choisir get requested certificate puis install.
Remarque : Etant donné que les clés ont été créées avec le CSP SChannel, le certificat sera
automatiquement installé non pas sur le poste local, mais sur le localMachine du poste
contrôleur de domaine, et cela à travers un canal sécurisé.
2.7 Publication du certificat dans Active Directory
Le certificat installé précédemment se situe dans le répertoire localMachine du contrôleur

de domaine. Pour rester rigoureux, il est également nécessaire de le publier dans Active
Directory.
Il est possible de configurer directement OpenCA pour ajouter le certificat à l’endroit voulu
dans Active Directory. Il est toutefois nettement plus simple de l’ajouter à l’aide d’un browser
LDAP à l’adresse suivante.
Ldap:// <contrôleur>.<domaine>/OU=Domain Controllers, DC=<domaine>,

DC=<com>.
Dans le champ usercertificate de l’object CN=<contrôleur>
Cette publication à été faite à l’aide du browser LDAP ldapbrowser\Editor v2.8.2. (Figure 3)
Figure 3 LDAP browser
Puis insérer le nouveau certificat à la place de celui crée par la CA Microsoft.
2.8 Création d’un nouveau rôle « clientMS »
Il s’agit à ce stade de spécifier un nouveau rôle de certificat, spécifique aux clients du

domaine W2K désirant utiliser la méthode Pkinit pour se loguer.
Comme pour le certificat kdc, les certificats des clients du domaine W2K devront posséder un
certain nombre d’extensions indispensables. Cette étape définit la procédure à suivre pour
créer un rôle intégrant les extensions spécifiques aux certificats utilisateurs smart card
logon.
Depuis le serveur de la CA choisir : Certification->Roles

Puis add a new role.
Choisir un nom pour le nouveau rôle, par exemple clientMS.
Ce scripte générera un fichier clientMS.conf qui contient la politique de certification à

utiliser sur ce type de rôle et un fichier clientMS.ext qui contient les extensions à ajouter
aux certificats dont le rôle est clientMS .
Avant de modifier ces fichiers il est nécessaire d’exporter ce nouveau rôle au serveur public
afin qu’il soit disponible lors de l’enrôlement.
Depuis le serveur CA : Input and output->Export Configuration
Puis depuis le serveur de la RA : Input and output->Import Configuration.

Il s’agit à ce point de configurer les extensions qui devront être ajoutées à tous les certificats
clientMS .
Remarque : Il n’existe pas de définition précise fournie par Microsoft sur les contraintes à
imposer aux certificats utilisateurs smart card logon, ces contraintes ont été déduites en
étudiant précisément les extensions d’un certificat similaire généré par la CA Microsoft.
• Le certificat doit contenir une extension contenant un lien sur une CRL valide de type
ldap ou http.
• L’extension certificate Key Usage section doit contenir les champs suivants
Digital signature, Key Encipherment.
• Le certificat doit contenir l’extension enhanced key Usage section avec les
deux champs suivant :
Client authentication(1.3.6.1.5.5.7.3.2)
Smart Card Logon(1.3.6.1.4.1.311.20.2.2)
• L’extension Certificate Subject Alternative Name section doit contenir

le champ other name (1.3.6.1.4.1.311.20.2.3)
Principal Name=<nom de login>@<domaine>
• L’extensionspécifique certificate template doit contenir le champ
SmartcardUser en données BMP.
Ces extensions doivent être spécifiées dans le fichier d’extension correspondant au rôle
clientMS , c’est-à-dire le fichier clientMS.ext .
Remarque : Etant donné que la plupart de ces extensions sont propriétaires, la technique pour
les intégrer dans un certificat OpenCA, consiste à extraire l’extension en donnée brute dans le
certificat Microsoft CA puis à l’introduire en format DER dans le certificat OpenCA.
Le détail de cette intégration d’extension est disponible dans le document en annexe.
ClientMS.ext.
2.9 Création puis installation du certificat utilisateur

sur le support hardware
A ce stade, un rôle spécifique aux clients Microsoft smart card logon à été crée. Ce rôle
contient toutes les extensions requisses par le contrôleur de domaine Microsoft pour accepter
un login par smart card.
Il ne reste plus qu’à générer des certificats pour les clients Microsoft à l’aide d’OpenCA, puis
de les intégrer dans un support hardware de type etoken.
Depuis la page principale du serveur public de la PKI OpenCA, choisir Request a

certificate, puis IE Request.
Il s’agit alors de remplir le formulaire avec les informations spécifiques à un client Microsoft
smart card logon.
Dans le champ Role, il est important de préciser le rôle UserMs créé précédemment. Les clés
doivent être générées ensuite dans le support hardware etoken, en spécifiant le CSP
correspondant à etoken alladin.
La suite de la procédure de certification est standard. Une fois le certificat signé, il peut être
récupérer de façon conventionnelle depuis la page principale de la PKI.
Get requested certificate puis install.
Remarque : Pour que le CSP puisse installer le certificat, il est nécessaire d’utiliser le même
poste avec le même browser.
3 Annexe (extensions)
3.1 Kdc.ext
# nsCertType = client, email
# nsComment= "User Certificate of tcomca"
# subject KeyIdentifier=hash
# authorityKeyIdentifier=keyid,issuer:always
# subjectAltName=${ENV::subjectAltName}
# issuerAltName=issuer:copy
# nsCaRevocationUrl
=http://pki.vpn.tcomvpn/crl/cacrl.crl
# nsRevocationUrl =
http://pki.vpn.tcomvpn/cr l/cacrl.crl
keyUsage=digitalSignature,keyEncipherment
#Certificate template domaine controller

1.3.6.1.4.1.311.20.2=DER:1e:20:00:44:00:6F:00:6D:00:61:00:69:00
:6E:00:43:00:6F:00:6E:00:74:00:72:00:6F:00:6C:00:6C:00:65:00:72
#subj alt name

2 . 5 . 2 9 . 1 7 = D E R : 3 0 :3 5 : a 0 : 1 f : 0 6 : 0 9 : 2 b : 0 6 : 0 1 : 0 4 : 0 1 : 8 2 : 3 7 : 1 9 : 0 1 : a 0 : 1
2:04:10:37:4d:72:2d:28:b6:ae:43:90:ee:01:e4:13:5f:f2:48:82:12:6
b:64:63:76:70:6e:2e:56:50:4e:2e:54:43:4f:4d:56:50:4 e
#enhanced key usage

2.5.29.37=DER:30:14:06:08:2b:06:01:05:05:07:03:02:06:08:2b:06:0
1:05:05:07:03:01
crlDistributionPoints =
URI:http://pki.vpn.tcomvpn/crl/cacrl.crl
3.2 UserMs.ext
# nsCertType = objsign
keyUsage = digitalSignature, keyEncipherment
#nsCommen:1e:1a:00:53:00:6d:00:61:00:72:00:74:00:63:00:61:00:72
:00:64:00:55:00:73:00:65:00:72
# PK I X r e c o m m e n d a t i o n s
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
#subjectAltName=${ENV::subjectAltName}
#issuerAltName=issuer:copy
# n s C a R e v o c a t i o n U r l = h t t p s : / / p k i . v p n . t c o m v p n / c g i-
bin/pub/crl/cacrl.crl
#nsRevocationUrl = https://pki.vpn.tcomvpn/cgi -
bin/pub/crl/cacrl.crl
crlDistributionPoints =
URI:https://pki.vpn.tcomvpn/crl/cacrl.crl
#certificate template smart card logon

1.3.6.1.4.1.311.20.2=DER:1e:1a:00:53:00:6d:00:61:00:72:00:74:00
:63:00:61:00:72:00:64:00:55:00:73:00:65:00:72
#enhanced key usage
2.5.29.37=DER:30:20:06:08:2b:06:01:05:05:07:03:04:06:08:2b:06:0
1:05:05:07:03:02:06:0a:2b:06:01:04:01:82:37:14:02:02
#subject alt name other name

2.5.29.17=DER:30:22:a0:20:06:0a:2b:06:01:04:01:82:37:14:02:03:a
0 : 1 2 : 0 c : 1 0 :7 4 : 6 5 : 7 3 : 7 4 : 4 0 : 5 6 : 5 0 : 4 e : 2 e : 5 4 : 4 3 : 4 f : 4 d : 5 6 : 5 0 : 4 e
4 Annexe (policy)
4.1 Kdc.conf
# OpenSSL example configuration file.

# This is mostly being used for generation of certificate requests.
#
# This definition stops the following lines choking if HOME isn't

# defined.
HOME = .
RANDFILE = $ENV::HOME/.rnd
# Extra OBJECT IDENTIFIER info:

#oid_file = $ENV::HOME/.oid
oid_section = new_oids
# To use this configuration file with the " -extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions =
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)
[ new_oids ]
# W e c a n add new OIDs in here for use by 'ca' and 'req'.

# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6
## used by ISIS -M T T
#pseudonym=2.5.4.65
#################################################
###################
[ ca ]
default_ca = CA_default # The default ca section
#################################################
###################
[ CA_default ]
dir = /usr/local/openca/OpenCA/var/crypto # Where everythin g

is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crls # Where the issued crl are kept
database = $dir/index.txt # database index file.
new_certs_dir = $dir/certs # default place for new certs.
certificate = $dir/cacerts/cacert.pem # The CA certificate

serial = $dir/serial # The current serial number
crl = $dir/crls/current.pem # The current CRL
private_key = $dir/keys/cakey.pem # The private key
RANDFILE = $dir/keys/.rand # private random number file
oid_file = $dir/.oid
#crl_extensions = crl_ext # Extensions to add to CRL

# As Netscape only accepts CLRs V1,
# DON't use CRL's extensions
# at least if you are uning Netscape
# 4 . 5 ( -).
default_da ys = 365 # how long to certify for

default_crl_days= 31 # how long before next CRL
default_md = sha1 # which md to use.
preserve = no
name_opt = ca_default
cert_opt = ca_default # keep passed DN ordering
# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy = p olicy_match
# For the CA policy

[ policy_match ]
commonName = optional
#################################################
###################
countryName_max = 2
SET-ex3 = SET extension number 3
[ req_attributes ]
## challengePassword = A challenge password
4.2 UserMs.conf
# OpenSSL example configura tion file.

# This is mostly being used for generation of certificate requests.
#
# This definition stops the following lines choking if HOME isn't

# defined.
HOME = .
RANDFILE = $ENV::HOME/.rnd
# Extra OBJECT IDENTIFIER info:

#oid_file = $ENV::HOME/.oid
oid_section = new_oids
# To use this configuration file with the " -extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions =
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)
[ new_oids ]
# We can add new OIDs in here for use by 'ca' and 'req'.
# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:

# testoid2=${testoid1}.5.6
## used by ISIS -M T T
#pseudonym=2.5.4.65
#################################################
###################
[ ca ]
default_ca = CA_default # The default ca section
#################################################
###################
[ CA_default ]
dir = /usr/local/openca/OpenCA/var/crypto # Where everything

is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/c rls # Where the issued crl are kept
database = $dir/index.txt # database index file.
new_certs_dir = $dir/certs # default place for new certs.
certificate = $dir/cacerts/cacert.pem # The CA certificate

seri al = $dir/serial # The current serial number
crl = $dir/crls/current.pem # The current CRL
private_key = $dir/keys/cakey.pem # The private key
RANDFILE = $dir/keys/.rand # private random number file
oid_file = $dir/.oid
#crl_extensions = crl_ext # Extensions to add to CRL

# As Netscape only accepts CLRs V1,
# DON't use CRL's e xtensions
# at least if you are uning Netscape
# 4 . 5 ( -).
default_days = 365 # how long to certify for

default_crl_days= 31 # how long before next CRL
default_md = sha1 # which md to use.
preserve = no
name_opt = ca_default
cert_opt = ca_default # keep passed DN ordering
# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy = policy_match
# For the CA policy

[ policy_match ]
commonName = optional
#################################################
###################
countryName_max = 2
SET-ex3 = SET extension number 3
[ req_attributes ]
## challengePassword = A challenge password

Integration OpenCA W2k PKI

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Integration OpenCA W2k PKI

Uploaded by

Copyright:

Available Formats

Intégration d’une PKI tierce(OpenCA)

dans un domaine Windows 2000.

Tables des matières

Les mécanismes d’authentification et de contrôle des droits d’accès dans un domaine

La fonctionnalité smart card logon permet de renforcer sensiblement la procédure de login en

• Un contrôleur de domaine Windows 2000 est installé, le droit administrateur de

L’intégration de la CA tiers suit la procédure suivante :

• Publication du certificat root de la CA tiers dans la liste des certificats de confiance

2.1 Publication du certificat root dans le fichier Ntauth

Le document fournit par Microsoft décrit précisément cette procédure

Le fichier Ntauth est un objet dans le contener Configuration, le DN (distinguish name) de

1. Le certificat root doit préalablement être convertit en forma t base-64.

certutil –encode inputfile outputfile.

La variable inputefile contient le lien sur le certificat root en format DER et

2. Création du fichier ldif

3. Sauvegarder le fichier comme Ntauth.ldf.

certmgr –s –r localMachine ntauth

[0,0] 1.2.840.113549.1.9.1 (E) admin@mydomain.com

2.2 Ajout de la CA root à la liste Entreprise trust list

Dsstore DC=<domaine>,DC=com –addroot cacert.pem

2.3 Génération du certificat pour le contrôleur de

Lors de la procédure de smart card logon, le contrôleur de domaine devra également

Un document fournit par Microsoft, décrit précisément la politique de certificat à imposer au

1. Intégration du template Router offline request

Start->Programs->Administrative Tools->Certification Authority.

Puis étendre l’arborescence de la CA Microsoft, cliquez avec le bouton droite sur le

Une liste de template apparaît, choisir le template Router (Offline request).

2. Générer une requête de certificat depuis la CA Microsoft.

L’outil d’enrôlement de la CA Microsoft se gère par une interface WEB accessible à

Le champ <controleur> correspond au nom du contrôleur de domaine et le champ

Il est nécessaire de se connecter en temps qu’administrateur de domaine. Une fois sur

Sur la page suivante choisir Advanced request puis Next.

A la page suivante choisir Submit a certificate request to this CA

Le formulaire suivante apparaît (figure 1).

F i g u r e 1 Advanced Certificate Request

• Choisir comme champ certificate template : Router(Offline request)

• Dans la section Key Options choisir.

CSP : Microsoft RSA Schannel Cryptographic Provider

Puis cocher l’option Use local machine store .

• Dans l’option Additional Options:

Cocher la case Save request to a PKCS#10 file.

• Finalement sauver la requête sur le disque.

A ce stade la CA Microsoft n’est plus nécessaire, la suite de la procédure s’effectuera depuis

2.4 Création d’un nouveau rôle « kdc »

Choisir un nom pour le nouveau rôle, par exemple KDC

Depuis le serveur CA. Input and output->Export Configuration

Puis depuis le serveur de la RA. Input and output->Import Configuration.

Remarque : Ces rôles sont le pendant des Certifications templates de Microsoft

2.4.1 Définition d’une politique de certificat pour le rôle kdc

Le contrôle de ces champs s’effectuera lors de la signature proprement dite du certificat.

2.4.2 Ajout des extensions spécifiques à un contrôleur de

La documentation de Microsoft préconise les recommandations suivantes sur les extensions

2.5 Prise en charge de la requête depuis OpenCA

-----BEGIN CERTIFICATE REQUEST-----

Depuis le serveur public d’OpenCA choisir Request a Certificate puis Serveur

Dans le champ request, choisir le fichier contenant la requête précédemment créée.

La requête sera transmise à la RA puis à la CA en vue d’une signature.

Avant de signer le certificat, il est nécessaire de modifier légèrement le fichier ca.conf. Il

2.6 Installation du certificat contrôleur de domaine

Pour installer le certificat dans le contrôleur de domaine, la procédure est parfaitement

Choisir get requested certificate puis install.

2.7 Publication du certificat dans Active Directory

Le certificat installé précédemment se situe dans le répertoire localMachine du contrôleur

Ldap:// <contrôleur>.<domaine>/OU=Domain Controllers, DC=<domaine>,