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 [email protected] 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

Intégration d’une PKI tiers dans un domaine Windows 2000

1

- 3 –

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é.

Intégration d’une PKI tiers dans un domaine Windows 2000

2

- 4 –

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.

Intégration d’une PKI tiers dans un domaine Windows 2000

- 5 –

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.

Intégration d’une PKI tiers dans un domaine Windows 2000

- 6 –

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::

Intégration d’une PKI tiers dans un domaine Windows 2000

- 7 –

[0,0] 1.2.840.113549.1.9.1 (E) [email protected] [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) [email protected] [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.

Intégration d’une PKI tiers dans un domaine Windows 2000

2.3 Génération domaine.

du

certificat

pour

le

contrôleur

- 8 –

de

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://.<domaine>.com/certsrv/

Le champ 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.

Intégration d’une PKI tiers dans un domaine Windows 2000

- 9 –

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.

Intégration d’une PKI tiers dans un domaine Windows 2000

- 10 –

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

Intégration d’une PKI tiers dans un domaine Windows 2000

2.4.1

- 11 –

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 organizationName organizationalUnitName commonName emailAddress

= = = = =

optional optional optional supplied 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=.<domaine> L’extension spécifique certificate template doit contenir le champ domainController en données BMP.

Intégration d’une PKI tiers dans un domaine Windows 2000

- 12 –

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)

Intégration d’une PKI tiers dans un domaine Windows 2000

- 13 –

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"

Intégration d’une PKI tiers dans un domaine Windows 2000

- 14 –

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:// .<domaine>/OU=Domain Controllers, DC=<domaine>, DC=. Dans le champ usercertificate de l’object CN=

Cette publication à été faite à l’aide du browser LDAP ldapbrowser\Editor v2.8.2. (Figure 3)

Intégration d’une PKI tiers dans un domaine Windows 2000

- 15 –

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.

Intégration d’une PKI tiers dans un domaine Windows 2000

- 16 –

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)

•

L’extension

Principal Name=<nom de login>@<domaine> spécifique certificate template doit SmartcardUser en données BMP.

contenir

le

champ

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.

Intégration d’une PKI tiers dans un domaine Windows 2000

- 17 –

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.

Intégration d’une PKI tiers dans un domaine Windows 2000

3

- 18 –

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 ibin/pub/crl/cacrl.crl #nsRevocationUrl = https://pki.vpn.tcomvpn/cgi bin/pub/crl/cacrl.crl crlDistributionPoints = URI:https://pki.vpn.tcomvpn/crl/cacrl.crl

Intégration d’une PKI tiers dans un domaine Windows 2000

- 19 –

#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

Intégration d’une PKI tiers dans un domaine Windows 2000

- 20 –

## 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 default_crl_days= 31 default_md = sha1 preserve = no name_opt cert_opt

# how long to certify for # how long before next CRL # which md to use.

= ca_default = 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 ] countryName

= optional

Intégration d’une PKI tiers dans un domaine Windows 2000

- 21 –

organizationName = optional organizationalUnitName = optional commonName = optional emailAddress = optional ################################################# ################### countryName_max

SET-ex3 [ req_attributes ] ## challengePassword

= 2

= SET extension number 3 = 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

Intégration d’une PKI tiers dans un domaine Windows 2000

- 22 –

# 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

default_days = 365 default_crl_days= 31 default_md = sha1 preserve = no name_opt cert_opt

= ca_default = ca_default

# # # #

# 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 ( -). # how long to certify for # how long before next CRL # which md to use.

# 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

Intégration d’une PKI tiers dans un domaine Windows 2000

- 23 –

[ policy_match ] countryName = optional organizationName = optional organizationalUnitName = optional commonName = optional emailAddress = optional ################################################# ################### countryName_max

SET-ex3 [ req_attributes ] ## challengePassword

= 2

= SET extension number 3 = A challenge password