Integration OpenCA W2k PKI

Intgration dune 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] dcembre 2002

Intgration dune PKI tiers dans un domaine Windows 2000

- 2

RsumCe document dcrit de manire gnrale, les diffrentes tapes permettant lintgration dune PKI non-Microsoft dans un domaine Windows 2000, en vue dune authentification smart card logon base sur pkinit. De manire spcifique, la PKI rellement intgre dans le domaine Windows 2000 est le produit OpenCA qui utilise largement les fonctionnalits cryptographies dOpenSSL.

Tables des matiresRsum..................................................................................... 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 Gnration du certificat pour le contrleur de domaine. ................... 8 2.4 Cration dun nouveau rle kdc ................................................ 10 2.4.1 Dfinition dune politique de certificat pour le rle kdc ........... 11 2.4.2 Ajout des extensions spcifiques un contrleur de domaine microsoft. 11 2.5 Prise en charge de la requte depuis OpenCA ................................. 12 2.6 Installation du certificat contrleur de domaine ............................. 14 2.7 Publication du certificat dans Active Directory .............................. 14 2.8 Cration dun nouveau rle clientMS ........................................ 15 2.9 Cration 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


- 3

1

Introduction

Les mcanismes dauthentification et de contrle des droits daccs dans un domaine Windows 2000 se basent sur le protocole Kerberos et lannuaire Active directory. Dans un scnario de login traditionnel, lutilisateur introduit son nom dutilisateur et un mot de passe. En ralit, une empreinte du mot de passe est transfre par le rseau. Le contrleur de domaine Windows 2000 vrifiera les informations utilisateurs en comparent lempreinte du mot de passe utilisateur contenu localement sur le contrleur avec lempreinte passe par lutilisateur lors du login. La fonctionnalit smart card logon permet de renforcer sensiblement la procdure de login en remplacent le mot de passe par un certificat numrique contenu dans une smart card hardware. Lauthentification de lutilisateur se base toujours sur le mcanisme centralis Kerberos version 5, mais il ncessite une reconnaissance rciproque du client et du contrleur de domaine par une signature numrique et lchange des certificats x509 utiliss pour la signature (voire document Pkinit VS MD5 ). Pour rendre possible cette politique de login par authentification forte, il est ncessaire dintgrer les mcanismes PKI au cur mme du systme Windows 2000. Microsoft fournit diffrents outils permettant de mettre sur pied une autorit de certification prive Microsoft CA lintgration de cet lment au cur dactive directory comme mcanisme dauthentification supplmentaire permet galement dadapter le protocole Kerberos aux nouveaux mcanismes PKI. De faon incontestable, lajout des mcanismes PKI dans un domaine W2K accrot la scurit globale de tout le systme. Mais de nombreuses cont roverses concernant la scurit ou la non scurit des quipements Microsoft, notamment sur un accort secret entre la NSA et Microsoft, ont mis en vidence le besoin de remplacer toutes applications Microsoft senses garantir la confidentialit par des applications dveloppes par dautres constructeurs, jugs plus sr, ce qui sapplique particulirement la CA de Microsoft. Malgr cet tat des lieux, il est ncessaire dinstaller la CA Microsoft en premier lieu pour bnficier des mcanismes additionnels apports Kerberos lors de cette installation. En second lieu, la CA Microsoft proprement dite sera remplace par notre propre autorit de certification OpenCA dont nous contrlons parfaitement lintgrit.


- 4

2

Pr-requis

La procdure de smart card logon dcrite dans ce document ne peut tre mise en uvre uniquement si les composants suivants ont t pralablement installs Un contrleur de domaine Windows 2000 est install, le droit administrateur de domaine est requis. Le service pack 2 doit tre install sur le contrleur de domaine. Active directory est prsent ainsi quun serveur DNS. Les services de certification Microsoft sont installs sur le contrleur de domaine, ce qui sous-entend que la CA Microsoft est installe dans le domaine. La PKI OpenC A est installe et accessible depuis le domaine.

Pour intgrer une PKI tiers dans le domaine Windows 2000, il est ncessaire dutiliser au pralable la CA Microsoft. En analysant les lments spcifiques gnrs par la CA Microsoft dans le systme, il est possible de substituer la CA Microsoft par la CA tiers en dupliquant tous les lments ncessaires au systme Microsoft. De faon plus prcise, le contrleur de domaine, comme les clients smart card logon requirent des certificats au profil bien particulier pour tre reconnus mutuellement lors de lauthentification Kerberos. Lintgration de la CA tiers suit la procdure suivante : Publication du certificat root de la CA tiers dans la liste des certificats de confiance root du contrleur de domaine(Ntauth). Publication du certificat root dans la liste entreprise trust. Gnration dune requte de certificat pour le contrleur de domaine. Cration dun nouveau rle OpenCA spcifique au contrleur de domaine. Prise en charge de la requte de certificat dans la PKI OpenCA. Gnration et installation du certificat contrleur de domaine. Requte dun certificat utilisateur. Cration dun nouveau rle OpenCA spcifique aux clients smart card logon. Cration puis installation du certificat utilisateur sur le support hardware.

2.1 Publication du certificat root dans le fichier NtauthPour que le contrleur de domaine autorise une ouverture de connexion smart card logon, il est ncessaire quil reconnaisse le certificat root. Le contrleur de domaine ne reconnat que les autorits 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 sagira dajouter par le protocole LDAP le nom de la CA tiers et le certificat proprement dit.


- 5

Le document fournit par Microsoft dcrit prcisment cette procdure (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 lobjet Ntauth, la stratgie propose par Microsoft consiste gnrer un fichier ldif contenant le DN de la CA et son certificat, puis de modifier lobjet laide des utilitaires ldap fournis par Microsoft, ce qui aura pour but dajouter le certificat lannuaire Ldap.

1. Le certificat root doit pralablement tre convertit en forma t base-64.

Lutilitaire certutil install avec les outils Windows 2000 Certification Service permettra deffectuer 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 crer.

2. Cration du fichier ldif La faon la plus simple de crer un fichier ldif aussi trivial, consiste introduire les donnes 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:: -

Le certificat au format base-64 cr prcdemment doit tre introduit dans le champ , il ne doit pas contenir les rubriques begin Certificate et end certificate. Chaque ligne du certificat doit dbuter par un espace et le certificat doit imprativement se terminer par un retour de chariot et le caractre trait dunion.


- 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 lutilitaire ldifde.exe pour importer le fichier dans Active Directory. Cet utilitaire est install par dfaut 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 seffectue par loutil dsstore contenu dans Windows 2000 resource kitdsstore pulse

6. Il est souhaitable de vrifier que le certificat a bien t intgr au fichier Ntauth en utilisant lutilitaire certmgr.certmgr s r localMachine ntauth

Le rsultat de cette commande affiche les donnes contenues dans le fichier ntauth.==============Certificate # 1 ========== Subject::


- 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 listBien que cette tape ne soit pas indispensable pour la procdure de smart card logon, il est toutefois pertinent dajouter 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 suivanteDsstore DC=,DC=com addroot cacert.pem

De cette manire tous les utilisateurs du domaine reconnatront par dfaut le certificat root de la CA lors de leur prochain login.


- 8

2.3 Gnration domaine.

du

certificat

pour

le

contrleur

de

Lors de la procdure de smart card logon, le contrleur de domaine devra galement prsenter son certificat au client, car lauthentification mutuelle est ncessaire. Ce point dcrit les tapes respecter pour gnrer, puis installer le certificat du contrleur de domaine lemplacement requis. Un document fournit par Microsoft, dcrit prcisment la politique de certificat imposer au certificat de type Domain Controller . (Requirements for Domain Controller Certificates from a Third-Party CA (Q291010)) La manire la plus simple pour gnrer ce certificat, consiste effectuer une requte de certificat (PKCS#10) spcifique depuis la CA Microsoft, puis de transfrer cette requte la PKI tiers (OpenCA) qui se chargera de signer la requte en ajoutant les extensions et les contraintes stipules dans le document Q291919.

1. Intgration du template Router offline request La requte qui devra tre faite par la CA Microsoft sera du type server request pkcs#10, il est donc ncessaire dajouter ce template la liste des certificates template reconnue par la CA microsoft.Start->Programs->Administrative Tools->Certification Authority.

Puis tendre larborescence de la CA Microsoft, cliquez avec le bouton droite sur le rpertoire Policy Settings et choisir new.->Certificate to Issue . Une liste de template apparat, choisir le template Router (Offline request). Ce template pourra ds lors tre utilis. 2. Gnrer une requte de certificat depuis la CA Microsoft. Loutil denrlement de la CA Microsoft se gre par une interface WEB accessible lURL suivant.http://..com/certsrv/

Le champ correspond au nom du contrleur de domaine et le champ spcifie le chemin complet du domaine. Il est ncessaire de se connecter en temps quadministrateur de domaine. Une fois sur la page principale choisir Request a certificate puis Next.


- 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 apparat (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 contrleur de domaine, seul le nom est ncessaire. Dans la section Key Options choisir.


- 10

CSP : Microsoft RSA Schannel Cryptographic Provider

Puis cocher loption Use local machine store . Dans loption Additional Options: Cocher la case Save request to a PKCS#10 file. Puis donner ladresse ou sera stock la requte. Finalement sauver la requte sur le disque.

Remarque : La cl prive est stocke provisoirement dans le CSP, Il est donc absolument ncessaire deffectuer les tapes qui suivront sur le mme poste avec le mme naviga teur WEB. Le CSP Schannel permet de gnrer une paire de cls localement puis de les intgrer sur un poste distant travers un canal scuris. A ce stade la CA Microsoft nest plus ncessaire, la suite de la procdure seffectuera depuis la CA tiers OpenCA.

2.4 Cration dun nouveau rle kdc Pour que le certificat du contrleur de domaine soit conforme aux exigences Microsoft, il est ncessaire dajouter de nouvelles extensions introduire dans le certificat du contrleur. OpenCA permet de dfinir diffrents rles suivant le profile que lon dsire ajouter aux certificats. Depuis le serveur de la CA choisir Certification->Roles Puis add a new role. Choisir un nom pour le nouveau rle, par exemple KDC Ce scripte gnrera un fichier kdc.conf qui contient la politique de certification utiliser sur ce type de rle et un fichier kdc.ext qui contient les extensions ajouter aux certificats dont le rle et KDC. Avant de modifier ces fichiers il est ncessaire dexporter ce nouveau rle sur le serveur public afin quil soit disponible lors de lenrlement. Depuis le serveur CA. Input and output->Export Configuration Puis depuis le serveur de la RA. Input and output->Import Configuration. Remarque : Ces rles sont le pendant des Certifications templates de Microsoft


- 11

2.4.1

Dfinition dune politique de certificat pour le rle kdc

Les champs contenus dans une requte pkcs#10 nont pas pu tre contrls lors de lenrlement tant donn que cette dernire a t effectue sur la PKI Microsoft. Le contrle de ces champs seffectuera lors de la signature proprement dite du certificat. Dans le fichier kdc.conf, sous la rubrique policy match dfinir 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 nexiger que le champ CN dans la requte.

2.4.2

Ajout des extensions spcifiques un contrleur de domaine microsoft.

Microsoft utilise des extensions propritaires quil est ncessaire dajouter au certificat contrleur de domaine. La documentation de Microsoft prconise les recommandations suivantes sur les extensions du certificat. Le certificat doit contenir une extension disposant dun lien sur une CRL valide de type ldap ou http De manire optionnelle le CN contenu dans le certificat contrleur de domaine doit contenir le DN complet du contrleur. Lextension certificate Key Usage section doit contenir les champs suivants : Digital signature, Key Encipherment. Le certificat doit contenir lextension 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) Lextension 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

lidentificateur ldap unique du contrleur de domaine. Cette extension doit galement contenir le champ DNS Name=. Lextension spcifique certificate template doit contenir le champ domainController en donnes BMP.


- 12

Etant donn que certaines de ces extensions sont propritaires, et bien videment pas connues dOpenSSL(version 0.9.6e), la solution pour les intgrer malgr tout au certificat du contrleur de domaine, consiste ajouter lextension manuellement laide de son OID ASN1, puis dintroduire les donnes sous forme de donnes brutes au format DER. (la configuration apporter au fichier kdc.ext est disponible en annexe) Remarque : Il ne sagit peut tre pas la de la technique la plus lgante, 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 requte depuis OpenCALa requte effectue prcdemment t sauvegarde sur un fichier, le format nest toutefois pas conforme au standard pkcs#10 dOpenSSL. Il sagit dajouter les enttes 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 dOpenCA choisir Request a Certificate puis Serveurrequest (PKCS#10 formated request).

Dans le champ request, choisir le fichier contenant la requte prcdemment cre. Choisir comme champ rle, le rle kdc. (Figure 2)


- 13

Fig u r e 2 P K C S # 1 1 r e q u e s t

Puis Continue... La requte sera transmise la RA puis la CA en vue dune signature. Avant de signer le certificat, il est ncessaire de modifier lgrement le fichier ca.conf. Il nest pas conseill de faire apparatre le numro de srie contenu dans le DN de la requte (configuration par dfaut dOpenCA).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"


- 14

A ce stade, le certificat peut tre sign par la CA puis transfr au serveur public de faon traditionnelle.

2.6 Installation du certificat contrleur de domainePour installer le certificat dans le contrleur de domaine, la procdure est parfaitement similaire une installation conventionnelle. Depuis le serveur public. Choisir get requested certificate puis install. Remarque : Etant donn que les cls ont t cres avec le CSP SChannel, le certificat sera automatiquement install non pas sur le poste local, mais sur le localMachine du poste contrleur de domaine, et cela travers un canal scuris.

2.7 Publication du certificat dans Active DirectoryLe certificat install prcdemment se situe dans le rpertoire localMachine du contrleur de domaine. Pour rester rigoureux, il est galement ncessaire de le publier dans Active Directory. Il est possible de configurer directement OpenCA pour ajouter le certificat lendroit voulu dans Active Directory. Il est toutefois nettement plus simple de lajouter laide dun browser LDAP ladresse suivante.Ldap:// ./OU=Domain Controllers, DC=, DC=. Dans le champ usercertificate de lobject CN=

Cette publication t faite laide du browser LDAP ldapbrowser\Editor v2.8.2. (Figure 3)


- 15

Figure 3 LDAP browser

Puis insrer le nouveau certificat la place de celui cre par la CA Microsoft.

2.8 Cration dun nouveau rle clientMS Il sagit ce stade de spcifier un nouveau rle de certificat, spcifique aux clients du domaine W2K dsirant utiliser la mthode Pkinit pour se loguer. Comme pour le certificat kdc, les certificats des clients du domaine W2K devront possder un certain nombre dextensions indispensables. Cette tape dfinit la procdure suivre pour crer un rle intgrant les extensions spcifiques 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 rle, par exemple clientMS. Ce scripte gnrera un fichier clientMS.conf qui contient la politique de certification utiliser sur ce type de rle et un fichier clientMS.ext qui contient les extensions ajouter aux certificats dont le rle est clientMS . Avant de modifier ces fichiers il est ncessaire dexporter ce nouveau rle au serveur public afin quil soit disponible lors de lenrlement. Depuis le serveur CA : Input and output->Export Configuration Puis depuis le serveur de la RA : Input and output->Import Configuration.


- 16

Il sagit ce point de configurer les extensions qui devront tre ajoutes tous les certificats clientMS . Remarque : Il nexiste pas de dfinition prcise fournie par Microsoft sur les contraintes imposer aux certificats utilisateurs smart card logon, ces contraintes ont t dduites en tudiant prcisment les extensions dun certificat similaire gnr par la CA Microsoft. Le certificat doit contenir une extension contenant un lien sur une CRL valide de type ldap ou http. Lextension certificate Key Usage section doit contenir les champs suivantsDigital signature, Key Encipherment.

Le certificat doit contenir lextension 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)

Lextension Certificate Subject Alternative Name section doit contenir le champ other name (1.3.6.1.4.1.311.20.2.3)Principal Name=@ spcifique certificate template doit SmartcardUser en donnes BMP.

Lextension

contenir

le

champ

Ces extensions doivent tre spcifies dans le fichier dextension correspondant au rle clientMS , cest--dire le fichier clientMS.ext . Remarque : Etant donn que la plupart de ces extensions sont propritaires, la technique pour les intgrer dans un certificat OpenCA, consiste extraire lextension en donne brute dans le certificat Microsoft CA puis lintroduire en format DER dans le certificat OpenCA. Le dtail de cette intgration dextension est disponible dans le document en annexe. ClientMS.ext.

2.9 Cration puis installation du certificat utilisateur sur le support hardwareA ce stade, un rle spcifique aux clients Microsoft smart card logon t cre. Ce rle contient toutes les extensions requisses par le contrleur de domaine Microsoft pour accepter un login par smart card. Il ne reste plus qu gnrer des certificats pour les clients Microsoft laide dOpenCA, puis de les intgrer 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.


- 17

Il sagit alors de remplir le formulaire avec les informations spcifiques un client Microsoft smart card logon.

Dans le champ Role, il est important de prciser le rle UserMs cr prcdemment. Les cls doivent tre gnres ensuite dans le support hardware etoken, en spcifiant le CSP correspondant etoken alladin. La suite de la procdure de certification est standard. Une fois le certificat sign, il peut tre rcuprer de faon conventionnelle depuis la page principale de la PKI.Get requested certificate puis install.

Remarque : Pour que le CSP puisse installer le certificat, il est ncessaire dutiliser le mme poste avec le mme browser.


- 18

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


- 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


- 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 # # # # default_da ys = 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 extensions 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 = p olicy_match # For the CA policy [ policy_match ] countryName

= optional


- 21

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

SET-ex3 [ req_attributes ] ## challengePassword

= 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


- 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


- 23

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

SET-ex3 [ req_attributes ] ## challengePassword

= SET extension number 3 = A challenge password

Documents

Integration OpenCA W2k PKI