Openstuff Wiki : HowtoPKI

HomePage :: Categories :: PageIndex :: RecentChanges :: RecentlyCommented :: Login/Register

Mise en oeuvre d'une PKI via des outils libres


L'objectif de cet article est de mettre en place une infrastructure de gestion de clefs à partir d'outils de base tel qu'OpenSSH ceci afin d'obtenir une architecture simple à mettre en oeuvre.

1 Etat des lieux


Commençons par un petit retour sur les notions de PKI.

1.1 Rappel sur les concepts de PKI


Une PKI (Public Key Infrastructure) ou IGC (Infrastructure de Gestion de Clefs) en français, est un système permettant la gestion de certificats numériques. Un tel certificat permet d'identifier aussi bien des machines que des personnes. Les certificats ont de nombreuses applications, ils peuvent être utilisés pour sécuriser les échanges avec un serveur Web (HTTPS), son MTA (SMTP-TLS) mais aussi de signer et chiffrer ses courriers électroniques.

Le rôle d'une infrastructure de gestion de clefs est donc de permettre la création de tels certificats mais aussi leur destruction appelée révocation. Ceux-ci sont normalisés et peuvent prendre plusieurs formes. Les plus courantes sont:

OpenPGP est une approche distribuée qui se prête bien au cadre personnel, mais ne répond pas forcément aux problématiques entreprises. Les certificats X.509 s'intègrent particulièrement bien aux annuaires et permettent une gestion centralisée.

La norme X.509 définit plusieurs champs, dont les principaux sont:

Au niveau des extensions, les plus utilisés sont :

Voici des exemples de KeyUsage :

Ainsi que des exemples de extendedKeyUsage :

Il est possible de connaître le rôle d'un certificat avec OpenSSL, via la commande suivante:
$ openssl x509 -purpose -in certificat.crt
Certificate purposes:
SSL client : No
SSL client CA : No
SSL server : Yes
SSL server CA : No
Netscape SSL server : Yes
Netscape SSL server CA : No
S/MIME signing : No
S/MIME signing CA : No
S/MIME encryption : No
S/MIME encryption CA : No
CRL signing : No
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No



Afin de permettre de gérer de tels certificats, une PKI s'organise en plusieurs entités:

1.2 La problématique de révocation


Il est relativement simple de mettre en place des certificats X.509 pourtant la problématique de révocation ne l'est pas. En effet, comment connaître le statut d'un certificat ? C'est la qu'interviennent les listes de révocation (CRL, RFC 3280) mais aussi le protocole OCSP (RFC 2560).

1.2.1 Liste de révocation

Une CRL est en fait une liste publique qui contient l'ensemble des certificats révoqués par une autorité de certification. Cette liste, signée par le CA et mise à jour périodiquement, contient les numéros de série des certificats qui ont été révoqués. Le certificat du CA doit être habilité à signer des CRL. Pour cela, il faut penser à rajouter cRLSign dans les keyUsage du certificat du CA (cf. configuration d'OpenSSL).

Ainsi, lorsqu'un client va récupérer la CRL, il va en premier lieu vérifier la signature de cette CRL, les dates de signature et de renouvellement de la CRL, puis importer les numéros de série des certificats révoqués. Ainsi, lors de l'utilisation d'un certificat, si celui-ci est présent dans cette liste, il sera considéré comme révoqué.

Mais comment savoir où se trouvent les CRL ? Et quand les mettre à jours ?
C'est pour cela que les dates de publication courante et future font partie de la CRL (Last Update, Next Update). Ce paramètre est utilisé par les clients (Firefox pour n'en citer qu'un) pour sa mise à jour automatique. De plus, les certificats intègrent généralement une URI permettant de connaître l'emplacement pour récupérer une CRL récente (crlDistributionPoints). Le client doit donc télécharger régulièrement la CRL qui peut facilement peser plusieurs dizaines de megas octets au bout de quelques années. Ceci implique bien évidement de configurer votre client pour qu'il récupère ces mises à jour, or l'auto update est bien souvent désactivé par défaut. De plus, le temps entre deux mises à jour n'est pas forcément acceptable (un mois par défaut dans OpenSSL).

1.2.2 Le protocole OCSP

Heureusement pour palier tous ces problèmes nous avons un protocole: OCSP (RFC 2560), malheureusement pas encore supporté pas tous. OCSP, késako ?
Comme indiqué sur le site d'OpenCA:
The OCSP Responder is an rfc2560 compliant OCSPD responder.
The purpose of such a server is to provide an on-line tool to verify the status of a certificate (such as Mozilla/Firefox/Netscape7).

Il s'agit en fait d'un protocole de vérification de certificats en ligne qui est une alternative aux listes de révocations. Celui-ci permet de vérifier si un certificat est révoqué, mais contrairement aux CRLs, le traitement s'effectue côté serveur. Il suffit donc que votre client contacte ce tiers et de lui fournisse le numéro de série du certificat à vérifier, le hash du nom de l'autorité signataire et le hash de la clé. Le serveur OCSP renverra une réponse signée qui contiendra le statut du certificat : good, revoked ou unknown.

Il est bien sûr possible d'indiquer dans le certificat le serveur OCSP (OCSP Responder) à interroger pour valider celui-ci. Ceci se fait dans la configuration d'OpenSSL:
authorityInfoAccess = OCSP;URI:http://ocsp.toto/

Cette extension est typiquement utilisée par Firefox pour vérifier de manière automatique la validité d'un certificat HTTPS.

Le serveur OCSP doit quant à lui présenter un certificat comportant l'extension OCSPSigning:
extendedKeyUsage = OCSPSigning


1.3. Solutions techniques existantes


Le monde du libre propose depuis quelque temps déjà toutes les briques essentielles permettant la mise en place d'une PKI. On pourra citer: OpenSSL pour la génération de certificat, OpenLDAP pour le stockage des CRT et autres CRL mais également des logiciels serveur tel que Apache et mod_ssl. Il existe également des solutions intégrées permettant la mise en place de l'ensemble des éléments constituant une PKI. C'est le cas de la solution IDX-PKI maintenant appelé OpenTrust-PKI proposé par la SSLL française IDEALX. Malheureusement, l'accès au source n'est plus gratuit (réservé au C3I, club des clients contributeurs). Il y a bien sur d'autres solutions telles que OpenCA qui est assez prometteur.

Le but ici n'est pas de faire une liste exhaustive ni d'utiliser ce genre de solution. Nous allons voir qu'il est possible d'obtenir une solution efficace à partir des briques de base que le libre met à notre disposition, moyennant quelques scripts maison :)
Pour cela nous allons utiliser les outils suivants:

2. Proposition d'architecture


L'architecture se décompose en éléments opérationnels. Ces éléments sont indépendants et ne nécessitent pas forcément une machine physique propre. Attention toutefois au risque de sécurité que cela peut entraîner. A noter également que le CA est un élément critique. Il est censé être coupé de tout réseau ce qui n'est pas le cas ici pour des raison d'automatisation et de simplification.

Architecture de la PKI

Toutes ces entités permettent de prendre en charge le cycle de vie d'un certificat. A noter qu'ici l'autorité d'enregistrement (RA) est déléguée sur le serveur / l'interface web (génération du CSR) et sur le CA (Validation).

Concernant la validation, c'est l'opérateur qui aura cette responsabilité. Celui-ci aura pour rôle de vérifier que les informations fournies sont correctes et respecte bien les conventions de l'entreprise : l'initiateur du CSR travaille t'il bien chez vous ? Le FQDN respecte t'il bien les conventions de nommage ?

2.1 Package pki-client


Ce package inclut la mise en place d'OpenSSL, d'Easy-RCA ainsi que la paire de clés permettant de se connecter en SSH sur le CA.
La copie du CSR se fait via SSH avec un compte particulier, ici pkicsr. Ceci permet de profiter des mécanismes de sécurité offerts par SSH: authentification, chiffrement.

Le mot package n'est pas anodin, nous vous conseillons fortement de packager toutes ces choses pour pouvoir envisager un déploiement sur plusieurs serveurs.

2.2 Interface Web


L'interface Web permet la création de certificats pour les utilisateurs. Cette interface aura exactement les mêmes taches que pki-client: générer une demande de certificat et la copier en SSH sur le CA.

2.1 Package pki-server


La partie serveur contient également OpenSSL et Easy-RCA. Les serveurs ainsi que l'interface Web n'ont besoin que de copier les fichiers CSR, nous allons donc mettre en place SCPOnly sur le CA. SCPOnly permet d'avoir un shell modifié autorisant uniquement l'accès aux fichiers et d'interdire tous privilèges d'exécution.


3. Mise en place


3.1 pki-server


OpenSSL

Pour installer OpenSSL (Debian) il suffit de faire:
# apt-get install openssl


Easy-RCA

Pour Easy-RCA, il faut récupérer le package OpenVPN. Les scripts se trouvent tous dans le répertoire openvpn-2.0.9/easy-rsa/2.0/:
$ wget http://openvpn.net/release/openvpn-2.0.9.tar.gz
$ tar zxvf openvpn-2.0.9.tar.gz 
$ cd  openvpn-2.0.9/easy-rsa/2.0/


Pour la configuration, il faudra aller voir du côté du fichier vars. Vérifiez que les différentes variables reflètent bien votre installation.
La configuration se poursuit par le fichier openssl.cnf. Voici les déclarations permettant la génération de certificat serveur, client ainsi que pour le démon OCSP:

[ crl_dp ]
URI = ldap://ldap/ou=ca,ou=pki,dc=oraganisatino,dc=com?certificateRevocationList;binary
[ server ]
nsComment                       = "Server certificate"
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid,issuer:always
issuerAltName                   = issuer:copy
basicConstraints                = critical,CA:FALSE
keyUsage                        = digitalSignature, keyEncipherment
extendedKeyUsage                = serverAuth
nsCertType                      = server
authorityInfoAccess             = OCSP;URI:http://ldap
crlDistributionPoints= @crl_dp
[ client ]
nsComment                       = "Client certificate"
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid,issuer:always
issuerAltName                   = issuer:copy
basicConstraints                = critical,CA:FALSE
keyUsage                        = digitalSignature, nonRepudiation, keyEncipherment
extendedKeyUsage                = clientAuth, emailProtection
authorityInfoAccess             = OCSP;URI:http://ldap
crlDistributionPoints= @crl_dp
[OCSP]
nsComment                       = "OCSP Responder"
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid,issuer:always
basicConstraints                = critical,CA:FALSE
extendedKeyUsage                = OCSPSigning
[ v3_ca ]
basicConstraints                = critical,CA:true
keyUsage                        = critical,keyCertSign,cRLSign
authorityKeyIdentifier          = keyid,issuer:always
subjectKeyIdentifier            = hash
[ crl_ext ]
issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always,issuer:always


Il faut maintenant créer notre certificat racine pour le CA (--pass permet de mettre une pass phrase sur la clé privée):
$ source ./vars 
$ ./clean-all
$ ./pkitool --pass --initca


Ainsi que les listes de révocation (ARL signifie Authority Revocation List, cette liste de révocation serra nécessaire pour l'annuaire):
$ export KEY_CN=""
$ export KEY_OU=""
$ cd "$KEY_DIR"
$ $OPENSSL ca -gencrl -out crl.pem -config "$KEY_CONFIG"
$ $OPENSSL ca -gencrl -out arl.pem -config "$KEY_CONFIG"


SCPOnly

L'installation sur le CA est assez simple (Debian):
# apt-get install scponly


Nous allons créer le compte pkicsr:
# useradd -s /usr/bin/scponly -m pkicsr


Puis, sur une autre machine, il vous faudra générer une paire de clés et mettre la clé publique dans le authorized_keys de ce compte (/home/pkicsr/.ssh/authorized_keys).
$ ssh-keygen -t rsa -b 2048


Nous pouvons maintenant lancer un test de connexion sur notre CA en fournissant à SSH la clé privée (id_rsa) du compte pkicsr:
$ scp -i id_rsa file pkicsr@machineCA:
test                                     100% 1273     1.2KB/s   00:00

$ ssh -i id_rsa pkicsr@machineCA:
Linux machineCA 2.6.14.6-grsec #1 PREEMPT Wed Jul 12 14:42:24 CEST 2006 i686 GNU/Linux

WinSCP: this is end-of-file:0

On voit bien que la copie ne pose pas de problème. Par contre, il n'est pas possible d'obtenir un environnement permettant l'exécution de commandes.

3.2 Mise en place de l'annuaire


Nous n'allons pas rentrer dans les détails de la mise en place d'un annuaire OpenLDAP qui dépasse le cadre de cet article. Nous considérons donc que vous possédez un annuaire up and running
Nous allons créer une branche dédiée à notre PKI: ou=pki,dc=organisation,dc=com
ou=pki,dc=organisation,dc=com
objectClass: organizationalUnit
objectClass: top
ou: pki


Dans cette branche nous allons avoir:

ou=ca,ou=pki,dc=organisation,dc=com
cn: pki-ca
description: Certificate Authority certificate and revocation list
objectClass: certificationAuthority
objectClass: applicationProcess
ou: ca
cACertificate;binary:: [...]
authorityRevocationList;binary:: [...]
certificateRevocationList;binary:: [...]

ou=hosts,ou=pki,dc=organisation,dc=com
objectClass: organizationalUnit
objectClass: top
ou: hosts

ou=users,ou=pki,dc=organisation,dc=com
objectClass: organizationalUnit
objectClass: top
ou: users


A noter que la classe certificationAuthority nécessite d'avoir un attribut authorityRevocationList qui correspond à une liste de révocation de certificat autorité.

Voici un exemble de fichier LDIF permettant d'importer ces données dans le LDAP:
dn: ou=ca,ou=pki,dc=organisation,dc=com
ou: ca
cn: pki-ca
description: Certificate Authority certificate and revocation list
cACertificate;binary:< file:///path/easy-rsa/2.0/keys/ca.der
certificateRevocationList;binary:< file:///path/easy-rsa/2.0/keys/crl.der
authorityRevocationList;binary:< file:///path/easy-rsa/2.0/keys/crl.der
objectClass: certificationAuthority
objectCLass: applicationProcess


Assurez-vous que votre annuaire stocke correctement les entrées hosts et users. Voici à quoi ressemblent de telles entrées:
cn=Julien Stankiewicz,ou=users,ou=pki,dc=organisation,dc=com
cn: Julien Stankiewicz
sn: Julien Stankiewicz
objectClass: inetOrgPerson
objectClass: top
objectClass: pkiUser
userCertificate;binary:: [...]

cn=servname,ou=hosts,ou=pki,dc=organisation,dc=com
cn: servname
ipHostNumber: 127.0.0.1
objectClass: ipHost
objectClass: device
objectClass: extensibleObject
userCertificate;binary:: [...]


3.3 Package pki-client


Ici il faudra, comme pour le package pki-server, installer OpenSSL et Easy-RCA. Une fois ceci fait, il faudra procéder a l'initialisation d'Easy-RCA. Celle-ci ne devra être fait qu'une seule fois:
$ PKI_PATH="/path/to/easy-rca"
$ source $PKI_PATH/vars
$ $PKI_PATH/clean-all


3.4 Mise en place d'OCSP


Mise en place d'Openca-ocspd:
$ tar zxvf openca-ocspd-1.5.1-rc1.tar.gz
$ cd openca-ocspd-1.5.1-rc1
# apt-get install gcc libc6-dev make patch
# apt-get install libldap2 libldap2-dev libssl0.9.7 libssl-dev
$ ./configure --prefix=/usr/local/ocspd
$ make
# make install


Puis:
# vi /etc/passwd
ocspd:x:102:1:OCSP Server Account,,,:/usr/local/ocspd:/bin/false
# vi /etc/shadow
ocspd:!:13559:0:99999:7:::


Enfin la configuration à proprement parler:
[ ocspd ]
default_ocspd   = OCSPD_default         # The default ocspd section
[ OCSPD_default ]
dir               = /usr/local/ocspd/etc/ocspd           # Where everything is kept
db                = $dir/index.txt               # database index file.
md                = sha1
ca_certificate    = $dir/certs/cacert.pem       # The CA certificate
ocspd_certificate = $dir/certs/ocspd_cert.pem   # The OCSP server cert
ocspd_key         = $dir/private/ocspd_key.pem  # The OCSP server key
pidfile           = $dir/ocspd.pid              # Main process pid
user                  = ocspd
group                 = daemon
bind                  = *
port                  = 80
max_req_size          = 8192
threads_num           = 150
max_timeout_secs      = 5
crl_auto_reload       = 3600
crl_check_validity    = 600
crl_reload_expired    = yes
response              = ocsp_response 
dbms                  = dbms_ldap
engine                = HSM
[ ocsp_response ]
dir                     = /usr/local/ocspd/etc/ocspd
ocsp_add_response_certs = $dir/certs/chain_certs.pem
ocsp_add_response_keyid = yes
next_update_days        = 0
next_update_mins        = 5
[ dbms_ldap ]
0.ca = @ldap_ca_1
[ ldap_ca_1 ]
crl_url = ldap://ldap
crl_entry_dn = "ou=ca,ou=pki,dc=organisation,dc=com"
crl_entry_attribute = "certificateRevocationList;binary"
ca_url = ldap://ldap
ca_entry_dn = "ou=ca,ou=pki,dc=organisation,dc=com"
ca_entry_attribute = "cACertificate;binary"
[ dbms_file ]
0.ca = @first_ca
[ first_ca ]
crl_url = file:////usr/local/ocspd/etc/ocspd/crls/crl.pem
ca_url  = file:////usr/local/ocspd/etc/ocspd/certs/cacert.pem
[ second_ca ]
[ HSM ]
engine_id = LunaCA3
0.engine_pre = login:1:10:11:myPassword


Une fois la configuration faite, il vous faudra générer les certificats pour OCSP: ocspd_cert.pem et ocspd_key.pem. Pensez également à copier le certificat publique du CA (cacert.pem).

Pour tester, il vous suffit de lancer le démon via la commande suivante:

# /usr/local/ocspd/sbin/ocspd -c /usr/local/ocspd/etc/ocspd/ocspd.conf -v


Ceci devrait vous donner les entrées suivantes dans le syslog:
Apr  4 18:07:16 ldaptest ocspd[1608]: INFO::OPENCA_SRV_INFO_TREAD::new thread created
Apr  4 18:07:56 ldaptest ocspd[1761]: OpenCA OCSPD v1.5.1 - starting.
Apr  4 18:07:56 ldaptest ocspd[1761]: reading certificate file (/usr/local/ocspd/etc/ocspd/certs/ocspd_cert.pem).
Apr  4 18:07:56 ldaptest ocspd[1761]: Reading Private Key file /usr/local/ocspd/etc/ocspd/private/ocspd_key.pem
Apr  4 18:07:56 ldaptest ocspd[1761]: reading CA certificate file.
Apr  4 18:07:56 ldaptest ocspd[1761]: OCSP Daemon setup completed
Apr  4 18:07:56 ldaptest ocspd[1761]: variable lookup failed for OCSPD_default::chroot_dir
Apr  4 18:07:56 ldaptest ocspd[1761]: Auto CRL reload every 3600 secs
Apr  4 18:07:56 ldaptest ocspd[1761]: Reload on expired CRLs enabled
Apr  4 18:07:56 ldaptest ocspd[1761]: Number of CAs in configuration is 1
Apr  4 18:07:56 ldaptest ocspd[1761]: Using LDAP protocol for CA retrivial
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::Connecting to LDAP (ldap)
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::Connection established (ldap)
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::Successfully binded to LDAP (ou=ca,ou=pki,dc=organisation,dc=com)
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP::Search Successful
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP::Got 1 entries
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP:CA Cert is DER formatted
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP::Got CA cert from LDAP
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP::Successfully unbinded
Apr  4 18:07:56 ldaptest ocspd[1761]: CA CERT for ldap_ca_1 loaded successfully.
Apr  4 18:07:56 ldaptest ocspd[1761]: CA List Entry added (CA list num 0)
Apr  4 18:07:56 ldaptest ocspd[1761]: Using LDAP protocol for CRL retrivial
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::CRL RELOAD::LDAP Protocol
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::Connecting to LDAP (ldap)
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::Connection established (ldap)
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::Successfully binded to LDAP (ou=ca,ou=pki,dc=organisation,dc=com)
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP::Successfully binded (ou=ca,ou=pki,dc=organisation,dc=com)
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP::Search Successful
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP::Got [1] entries
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP::Got CRL ok.
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP::Successfully unbinded
Apr  4 18:07:56 ldaptest ocspd[1761]: CRL loaded [ ldap_ca_1 ]
Apr  4 18:07:56 ldaptest ocspd[1761]: CRL and CA cert [0:1] check ok
Apr  4 18:07:56 ldaptest ocspd[1761]: CRL matching CA cert ok [ 1 ]
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::CRL::Verify 1 [OK=1]
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::CRL is Valid
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::CRL::-1 Entries [ ldap_ca_1 ]
Apr  4 18:07:56 ldaptest ocspd[1761]: No Entries for CRL (@ldap_ca_1)
Apr  4 18:07:56 ldaptest ocspd[1761]: CRL loaded successfully [ldap_ca_1]
Apr  4 18:07:56 ldaptest ocspd[1761]: CRL validity check every 600 sec.
Apr  4 18:07:56 ldaptest ocspd[1761]: Configuration loaded and parsed
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::Local Address 0.0.0.0 [80]
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::OPENCA_SRV_INFO_TREAD::new thread created


4. Le cycle de génération d'un certificat


Concernant la génération de certificat pour des personnes, il est possible de créer une interface en PHP permettant d'avoir un fonctionnement similaire à ce qui est fait pour un serveur (cf. http://fr3.php.net/manual/fr/ref.openssl.php pour la génération des CSR). Dans la suite de l'article nous détaillerons l'utilisation de la partie serveur via le package pki-client.

4.1 Génération et copie d'un CSR


Pour chaque nouveau certificat, il faudra générer une clé privée et un CSR:
$ PKI_PATH="/path/to/easy-rca"
$ source $PKI_PATH/vars
$ $PKI_PATH/pkitool --interact --csr --server "servname"


Enfin, il faudra copier le CSR sur le CA:
$ scp -i $PKI_PATH/id_rsa $PKI_PATH/keys/servname.csr pkicsr@machineCA:


4.2 Validation et Signature


Nous arrivons maintenant a la phase de vérification de l'identité de l'entité demandeuse et à la signature du CSR qui permettra d'obtenir le CRT qui sera publique. Pour vous simplifier la vie nous vous conseillons d'avoir une crontab qui détecte l'arrivée de nouvelle demande. Un mail pourrait être envoyé à l'initiateur du CSR (l'email est présent dans le CSR) pour l'informer que sa requête est en cours de traitement. De plus, il serait intéressant d'envoyer un second mail à l'opérateur chargé de la validation.

L'opérateur à le choix entre plusieurs scénarios :
$ ./revoke-full "servname"


$./pkitool --interact --sign --server "servname"


Suite a ceci, il faudra publier le CRT ou le CRL.

4.3 Mise a disposition des certificats


La publication des CRT et CRL se fait en générant un fichier ldif puis en publiant les modifications sur l'annuaire via un appel a ldapmodify. Il faut tout d'abord récupérer le serial associé au certificat en question, ici servname. Le serial est présent dans le certificat lui même mais peut être également trouvé dans le fichier index.txt. Nous considérons ici que $SERIAL contient le numéro correspondant au certificat souhaitant être publié (par exemple 01).
# Conversion au format DER
$OPENSSL x509 -in $SERIAL.pem -outform DER -out $SERIAL.der

# Generation d'un fichier ldif
{
/bin/cat <<EOF
dn: cn=servname,ou=hosts,ou=pki,dc=organisation,dc=com
cn: servname
ipHostNumber: 127.0.0.1
objectClass: ipHost
objectClass: device
objectClass: extensibleObject
userCertificate;binary:< file://$KEY_DIR/$SERIAL.der
EOF
} > $SERIAL.ldif

# Publication du certificat dans l'annuaire LDAP
ldapmodify -x -D "cn=manager,dc=organisation,dc=com" -w "password" -f $SERIAL.ldif -H ldap://ldap -Z


Ici nous utilisons le compte manager qui a tous les droits sur l'annuaire, c'est mal ! Il faudra veiller à creer un compte avec des droits restreint uniquement au sous arbre correspondant à la PKI (ou=pki,dc=organisation,dc=com). A noter que si l'entrée cn=servname,ou=hosts,ou=pki,dc=organisation,dc=com n'existe pas, il faudra ajouter l'option -a à la commande ldapmodify pour pouvoir ajouter l'entrée: cf. le man de ldapmodify:
-a     Add new entries.  The default for ldapmodify is to modify existing entries.


4.4 Récupération des certificats par le demandeur


La récupération du certificat depuis le LDAP se fait comme ceci:
# récupération du CRT depuis l'annuaire LDAP
FILE=`ldapsearch -x -t -u -b "cn=servname,ou=hosts,ou=pki,dc=organisation,dc=com" -H ldap://ldap -Z -LLL | grep "userCertificate;binary" | sed 's/userCertificate;binary:< file:\/\/\(.*\)/\1/'`
# Conversion au format PEM
openssl x509 -inform DER -in $FILE -outform PEM -out $PKI_PATH/keys/servname.crt
# Affichage
openssl x509 -in $PKI_PATH/keys/servname.crt -text -noout


4.5 Vérification des certificats


La validation des certificats permet de renseigner n'importe quelle entité sur l'état de validité d'un certificat, et ce, à tout moment. Faisons le test avec notre certificat servname via la commande OpenSSL:
openssl ocsp -issuer ca.crt -CAfile ca.crt -cert servname.crt -url http://ldap:80 -text
[...]
Response verify OK
servname.crt: good
	    This Update: Apr  4 14:24:40 2007 GMT
	    Next Update: Apr  5 08:50:31 2007 GMT

Au niveau du démon ocspd nous obtenons la trace suivante:
Apr  5 10:45:31 ldaptest ocspd[2624]: INFO::Connection from [192.168.5.55]
Apr  5 10:45:31 ldaptest ocspd[2624]: request for certificate serial 2
Apr  5 10:45:31 ldaptest ocspd[2624]: status VALID for 2


Révoquons maintenant ce certificat et reproduisons la commande précédente:
Response verify OK
servname.crt: revoked
	    This Update: Apr  5 08:52:33 2007 GMT
	    Next Update: Apr  5 08:58:08 2007 GMT
	    Revocation Time: Apr  5 08:52:32 2007 GMT


Ce qui donne au niveau d'OCSP:
Apr  5 10:53:08 ldaptest ocspd[2928]: INFO::Connection from [192.168.5.55]
Apr  5 10:53:08 ldaptest ocspd[2928]: request for certificate serial 2
Apr  5 10:53:08 ldaptest ocspd[2928]: Status for 2 is REVOKED

Valid XHTML 1.0 Transitional :: Valid CSS :: Powered by WikkaWiki
Page was generated in 0.1090 seconds