Openstuff Wiki : HowtoPKI

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

Revision [525]

Last edited on 2007-11-17 10:41:08 by StanKju
Additions:
~- ""CRLDistributionPoints"" : définis un point de distribution d'une liste de révocations (CRL)
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"").
Deletions:
~- ""CRLDistributionPoints"" : défini un point de distribution d'une liste de révocations (CRL)
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 a 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"").


Revision [312]

Edited on 2007-07-06 09:49:40 by StanKju
Additions:
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.
Deletions:
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.


Revision [247]

Edited on 2007-05-04 20:17:41 by StanKju
Additions:
$ ssh-keygen -t rsa -b 2048
# Conversion au format DER
# Generation d'un fichier ldif
# Publication du certificat dans l'annuaire LDAP
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:
# récupération du CRT depuis l'annuaire LDAP
# Conversion au format PEM
# Affichage
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"":
Deletions:
ssh-keygen -t rsa -b 2048
# Convert in DER format
# Generate ldif file
# Push cert in LDAP directory
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:
# retreiving CRT from LDAP directory
# Convert cert in PEM format
# Display it
La validation de 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"":


Revision [246]

Edited on 2007-05-04 20:05:06 by StanKju
Additions:
$ PKI_PATH="/path/to/easy-rca"
$ source $PKI_PATH/vars
$ $PKI_PATH/clean-all
dir = /usr/local/ocspd/etc/ocspd # Where everything is kept
db = $dir/index.txt # database index file.
md = sha1
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:
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//.
$ PKI_PATH="/path/to/easy-rca"
$ source $PKI_PATH/vars
$ $PKI_PATH/pkitool --interact --csr --server "servname"
$ scp -i $PKI_PATH/id_rsa $PKI_PATH/keys/servname.csr pkicsr@machineCA:
Deletions:
# PKI_PATH="/path/to/easy-rca"
# source $PKI_PATH/vars
#$PKI_PATH/clean-all
dir = /usr/local/ocspd/etc/ocspd # Where everything is kept
db = $dir/index.txt # database index file.
md = sha1
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 le lancer via la commande suivante:
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'utilisateur de la partie serveur via le package //pki-client//.
PKI_PATH="/path/to/easy-rca"
source $PKI_PATH/vars
$PKI_PATH/pkitool --interact --csr --server "servname"
scp -i $PKI_PATH/id_rsa $PKI_PATH/keys/servname.csr pkicsr@machineCA:


Revision [245]

Edited on 2007-05-04 19:58:20 by StanKju
Additions:
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).
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"").
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 [[http://sublimation.org/scponly/ 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.
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//).
Nous pouvons maintenant lancer un test de connexion sur notre CA en fournissant à SSH la clé privée (//id_rsa//) du compte //pkicsr//:
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
Enfin la configuration à proprement parler:
dir = /usr/local/ocspd/etc/ocspd # Where everything is kept
db = $dir/index.txt # database index file.
md = sha1
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
Deletions:
Il est relativement simple de mettre en place des certificats X.509 pourtant la problématique de révocation est loin d'être simple. 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).
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"").
La partie serveur contient également ""OpenSSL"" et ""Easy-RCA"". N'ayant besoin que de copier des fichiers, nous allons également mettre en place [[http://sublimation.org/scponly/ 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.
Puis il vous faudra générer une paire de clés et mettre la clé publique dans le authorized_keys (/home/pkicsr/.ssh/authorized_keys).
Nous pouvons maintenant lancer un test de connexion sur notre CA en fournissant a SSH la clé privée (//id_rsa//) du compte //pkicsr//:
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"". Ceci ne devra être fait qu'une seule fois:
$PKI_PATH/clean-all
Enfin la configuration a proprement parlé:
dir = /usr/local/ocspd/etc/ocspd # Where everything is kept
db = $dir/index.txt # database index file.
md = sha1
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


Revision [237]

Edited on 2007-04-21 12:04:39 by StanKju
Additions:
~- ""CRLDistributionPoints"" : défini un point de distribution d'une liste de révocations (CRL)
~- Une Autorité de Certification (CA) chargée d'émettre des certificats électroniques. Celle-ci a donc pour rôle de signer les demandes de certificat (CSR, Certificate Signing Request) et de signer les listes de révocation (CRL, Certificate Revocation List)
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é [[http://www.opentrust.com 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 [[http://www.openca.org OpenCA]] qui est assez prometteur.
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.
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.
Il faut maintenant créer notre certificat racine pour le CA (--pass permet de mettre une //pass phrase// sur la clé privée):
Nous pouvons maintenant lancer un test de connexion sur notre CA en fournissant a SSH la clé privée (//id_rsa//) du compte //pkicsr//:
Assurez-vous que votre annuaire stocke correctement les entrées //hosts// et //users//. Voici à quoi ressemblent de telles entrées:
Deletions:
~- ""CRLDistributionPoints"" : défini un point de distribution d'une listes de révocations (CRL)
~- Une Autorité de Certification (CA) chargée d'émettre des certificats électroniques. Celle-ci, à donc pour rôle de signer les demandes de certificat (CSR, Certificate Signing Request) et de signer les listes de révocation (CRL, Certificate Revocation List)
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é [[http://www.opentrust.com 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 à bien sur d'autres solutions telles que [[http://www.openca.org OpenCA]] qui est assez prometteur.
Ce package inclut la mise en place d'""OpenSSL"", d'""Easy-RCA"" ainsi que la paire de clé permettant de se connecter en SSH sur le CA.
Pour la configuration, il faudra aller voir du coté du fichier //vars//. Vérifiez que les différentes variables reflètent bien votre installation.
Il faut maintenant créer notre certificat racine pour le CA (--pass permet de mettre une //pass phrase// sur la clé privé):
Nous pouvons maintenant lancer un test de connexion sur notre CA en fournissant a SSH la clé privé (//id_rsa//) du compte //pkicsr//:
Assurez vous que votre annuaire stocke correctement les entrées //hosts// et //users//. Voici à quoi ressemblent de telles entrées:


Revision [236]

Edited on 2007-04-12 09:54:36 by StanKju
Additions:
$ openssl x509 -purpose -in certificat.crt
Deletions:
openssl x509 -purpose -in certificat.crt


Revision [235]

Edited on 2007-04-12 09:54:22 by StanKju
Additions:
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


Revision [234]

Edited on 2007-04-12 09:50:29 by StanKju
Additions:
Au niveau des extensions, les plus utilisés sont :
~- ""AuthorityKeyIdentifier"" : identifiant de la clé de l'autorité
~- ""SubjectKeyIdentifier"" : identifiant de la clé du sujet
~- ""KeyUsage"" : précise le cadre d'utilisation du certificat
~- ""SubjectAltName"" : non alternatif pour l'identification du propriétaire du certificat
~- ""BasicConstraints"" : identification pour un certificat d'une autorité
~- ""ExtendedKeyUsage"" : précise le cadre d'utilisation du certificat
~- ""CRLDistributionPoints"" : défini un point de distribution d'une listes de révocations (CRL)
Voici des exemples de //""KeyUsage""// :
~- digitalSignature : signature numérique
~- nonRepudiation : signature numérique et non répudiation
~- keyEncipherment : chiffrement de clé pour le transport (utilisé avec RSA)
~- dataEncipherment : chiffrement de données (utilisé avec RSA)
~- keyAgreement : mise en accord de clés (utilisé avec Diffie-Hellman)
~- keyCertSign : signature numérique de certificats (utilisé par les CA)
~- cRLSign : signature numérique de liste de révocation (utilisé par les CA)
Ainsi que des exemples de //extendedKeyUsage// :
~- serverAuth : authentification d'un serveur lors d'une authentification TLS
~- clientAuth : authentification d'un client au lors d'une authentification TLS
~- codeSigning : signature de code
~- emailProtection : utilisation de S/MIME lors d'échange de mail
~- timeStamping : horodatage de données.
~- OCSPSigning : signature de données OCSP.


Revision [233]

Edited on 2007-04-10 20:33:40 by StanKju
Additions:
~- La norme X.509 avec les versions successives 1, 2 et 3 (RFC 3279, 3280) qui nous intéressent ici
""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:
~- Une Autorité d'Enregistrement (RA): qui permet de faire l'interface entre les demandeurs de certificats et l'autorité de certification. Son rôle est de générer les demandes de certificats, mais aussi de vérifier l'identité du demandeur
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"").
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"":
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é [[http://www.opentrust.com 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 à bien sur d'autres solutions telles que [[http://www.openca.org 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 :)
~- [[http://openvpn.net/easyrsa.html Easy-RCA]] (fourni par ""OpenVPN""). Il s'agit de scripts bash permettant de manipuler simplement les commandes ""OpenSSL"".
~- [[http://www.openca.org/projects/ocspd/ OCSPD]] (fourni par le projet ""OpenCA"") qui nous permettra de mettre en oeuvre un démon OCSP.
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 ?
Ce package inclut la mise en place d'""OpenSSL"", d'""Easy-RCA"" ainsi que la paire de clé 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.
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///:
Pour la configuration, il faudra aller voir du coté du fichier //vars//. Vérifiez que les différentes variables reflètent bien votre installation.
Puis il vous faudra générer une paire de clés et mettre la clé publique dans le authorized_keys (/home/pkicsr/.ssh/authorized_keys).
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//
Assurez vous que votre annuaire stocke correctement les entrées //hosts// et //users//. Voici à quoi ressemblent de telles entrées:
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).
Ceci devrait vous donner les entrées suivantes dans le syslog:
Enfin, il faudra copier le CSR sur le CA:
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 :
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).
La validation de 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"":
Deletions:
~- La norme X.509 avec les versions successives 1, 2 et 3 (RFC 3279, 3280) qui nous intéresse ici
""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:
~- Une Autorité d'Enregistrement (RA): qui permet de faire l'interface entre les demandeurs de certificats et l'autorité de certification. Son rôle est de générer les demandes de certificats mais aussi de vérifier l'identité du demandeur
Mais comment savoir ou 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 peux facilement peser plusieurs dizaines de mega 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 mise à jour n'est pas forcément acceptable (un mois par défaut dans ""OpenSSL"").
Il est bien sur possible d'indiquer dans le certificat le serveur OCSP (OCSP Responder) à interroger pour valider celui-ci. Ceci ce fait dans la configuration d'""OpenSSL"":
Le monde du libre propose depuis quelque temps déja 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 appellé [[http://www.opentrust.com 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 à bien sur d'autres solution tel que [[http://www.openca.org 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 script maison :)
~- [[http://openvpn.net/easyrsa.html Easy-RCA]] (fournit par ""OpenVPN""). Il s'agit de scripts bash permettant de manipuler simplement les commandes ""OpenSSL"".
~- [[http://www.openca.org/projects/ocspd/ OCSPD]] (fournit par le projet ""OpenCA"") qui nous permettra de mettre en oeuvre un démon OCSP.
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é sur le serveur / l'interface web (génération du CSR) et sur le CA (Validation).
Concernant la validation, c'est l'operateur qui aura cette responsabilité. Celui-ci aura pour rôle de vérifier que les informations fournis sont correcte 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 ?
Ce package inclus la mise en place d'""OpenSSL"", d'""Easy-RCA"" ainsi que la paire de clé 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écanisme de sécurité offert par SSH: authentification, chiffrement.
Pour Easy-RCA, il faut récuperer le package ""OpenVPN"". Les scripts se trouvent tous dans le répertoire //openvpn-2.0.9/easy-rsa/2.0///:
Pour la configuration, il faudra aller voir du coté du fichier //vars//. Vérifiez que les différentes variables reflète bien votre installation.
Puis il vous faudra générer une paire de clé et mettre la clé publique dans le authorized_keys (/home/pkicsr/.ssh/authorized_keys).
Nous n'allons pas rentrer dans les details de la mise en place d'un annuraire ""OpenLDAP"" qui dépasse le cadre de cette article. Nous considérons donc que vous possédez un annuaire //up and running//
Nous allons créer une branche dédié à notre PKI: //ou=pki,dc=organisation,dc=com//
Assurez vous que votre annuaire stocke correctement les entrées //hosts// et //users//. Voici à quoi ressemble de telles entrées:
Une fois la configuration faite, il vous faudra générer les certificat pour OCSP: ocspd_cert.pem et ocspd_key.pem. Pensez également à copier le certificat publique du CA (cacert.pem).
Ceci devrais vous donner les entrés suivantes dans le syslog:
Enfin il faudra copier le CSR sur le CA:
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 serra 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'operateur à le choix entre plusieurs scénario:
La publication des CRT et CRL se fait en générant un fichier ldif puis en publiant les modification 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 corresponant au certificat souhaitant être publié (par exemple 01).
La validation de 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"":


Revision [232]

Edited on 2007-04-10 20:28:02 by StanKju
Additions:
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:
~- La norme X.509 avec les versions successives 1, 2 et 3 (RFC 3279, 3280) qui nous intéresse ici
""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.
~- Emetteur : l'identifiant de l'autorité de certification qui a émis le certificat
Afin de permettre de gérer de tels certificats, une PKI s'organise en plusieurs entités:
~- Une Autorité d'Enregistrement (RA): qui permet de faire l'interface entre les demandeurs de certificats et l'autorité de certification. Son rôle est de générer les demandes de certificats mais aussi de vérifier l'identité du demandeur
===1.2 La problématique 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 a 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"").
Mais comment savoir ou 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 peux facilement peser plusieurs dizaines de mega 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 mise à jour n'est pas forcément acceptable (un mois par défaut dans ""OpenSSL"").
Le monde du libre propose depuis quelque temps déja 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 appellé [[http://www.opentrust.com 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 à bien sur d'autres solution tel que [[http://www.openca.org OpenCA]] qui est assez prometteur.
Deletions:
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 électronique.
Le rôle d'une infrastructure de gestion de cléfs est donc de permettre la création de tel certificats mais aussi leur destruction appelé révocation. Ceux-ci sont normalisée et peuvent prendre plusieurs formes. Les plus courantes sont:
~- La norme X.509 avec les versions successive 1, 2 et 3 (RFC 3279, 3280) qui nous intéresse ici
""OpenPGP"" est une approche distribuée qui se prête bien au cadre personnel mais ne réponds pas forcément aux problématique entreprise. Les certificats X.509 s'intègrent particulièrement bien aux annuaires et permettent une gestion centralisée.
~- Emetteur : l'identifiant de l'autorité de certification qui à émit le certificat
Afin de permettre de gérer de tels cerficats, une PKI s'organise en plusieurs entités:
~- Une Autorité d'Enregistrement (RA): qui permet de faire l'interface entre les demandeur de certificats et l'autorité de certification. Son rôle est de générer les demandes de certificats mais aussi de vérifier l'identité du demandeur
===1.2 La problématique de révoquation===
Une CRL est en fait une liste publique qui content l'ensemble des certificats révoqués par une autorité de certification. Cette liste, signé par le CA et mise a 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"").
Mais comment savoir ou se trouve 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 peux facilement peser plusieurs dixaines de mega octets au bout de quelques années. Ceci implique bien évidement de configurer votre client pour qu'il récupère ces mise a jour, or l'//auto update// est bien souvent désactivé par défaut. De plus le temps entre deux mise à jours n'est pas forcément acceptable (un mois par défaut dans ""OpenSSL"").
Le monde du libre propose depuis quelques temps déja 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 logiciel 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 appellé [[http://www.opentrust.com 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 à bien sur d'autres solution tel que [[http://www.openca.org OpenCA]] qui est assez prometteur.


Revision [231]

Edited on 2007-04-06 11:15:08 by StanKju
Additions:
Le monde du libre propose depuis quelques temps déja 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 logiciel 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 appellé [[http://www.opentrust.com 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 à bien sur d'autres solution tel que [[http://www.openca.org OpenCA]] qui est assez prometteur.
La copie du CSR se fait via SSH avec un compte particulier, ici //pkicsr//. Ceci permet de profiter des mécanisme de sécurité offert par SSH: authentification, chiffrement.
La partie serveur contient également ""OpenSSL"" et ""Easy-RCA"". N'ayant besoin que de copier des fichiers, nous allons également mettre en place [[http://sublimation.org/scponly/ 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.
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:
URI = ldap://ldap/ou=ca,ou=pki,dc=oraganisatino,dc=com?certificateRevocationList;binary
Nous pouvons maintenant lancer un test de connexion sur notre CA en fournissant a SSH la clé privé (//id_rsa//) du compte //pkicsr//:
$ scp -i id_rsa file pkicsr@machineCA:
$ ssh -i id_rsa pkicsr@machineCA:
Nous n'allons pas rentrer dans les details de la mise en place d'un annuraire ""OpenLDAP"" qui dépasse le cadre de cette article. Nous considérons donc que vous possédez un annuaire //up and running//
Nous allons créer une branche dédié à notre PKI: //ou=pki,dc=organisation,dc=com//
Pour chaque nouveau certificat, il faudra générer une clé privée et un CSR:
# retreiving CRT from LDAP directory
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/'`
Deletions:
Le monde du libre propose depuis quelques temps déja 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 Apache et mod_ssl pour contrôler les accès à un serveur web. 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 appellé [[http://www.opentrust.com 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 à bien sur d'autres solution tel que [[http://www.openca.org OpenCA]] qui est assez prometteur.
La copie du CSR se fait via SSH avec un compte particulier, ici //pkicsr//. Ceci permet de profiter des mécanisme de sécurité offert par SSH: authentification, chiffrement. N'ayant besoin que de copier des fichiers, nous allons mettre en place [[http://sublimation.org/scponly/ 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.
La partie serveur contient également ""OpenSSL"" et ""Easy-RCA"" mais aussi "SCPOnly".
La configuration se poursuit par le fichier openssl.cnf. Voici les déclarations pour mettre en place un certificat serveur, client et pour l'OCSP:
URI = ldap://ldaptest.infra.b2.p.fti.net/ou=ca,ou=pki,dc=fti,dc=net?certificateRevocationList;binary
[ engine_section ]
Nous pouvons maintenant lancer un test de connexion sur notre CA en fournissant a SSH la clé privé du compte //pkicsr//:
$ scp -i clé_privé file pkicsr@machineCA:
$ ssh -i ma_clé_privé pkicsr@machineCA:
Nous n'allons pas rentrer dans les details de la mise en place d'un annuraire ""OpenLDAP"" qui dépasse le cadre de cette article. Nous allons créer une branche dédié à notre PKI: //ou=pki,dc=organisation,dc=com//
Puis pour chaque nouveau certificat, il faudra générer une clé privée et un CSR:
$ # retreiving CRT from LDAP directory
$ 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/'`


Revision [230]

Edited on 2007-04-05 10:54:01 by StanKju
Additions:
La validation de 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
Deletions:
La validation de certificats permet de renseigner n'importe quelle entité sur l'état de validité d'un certificat, et ce à tout moment. La révocation de certificats consiste à publier une CRL.


Revision [229]

Edited on 2007-04-05 10:37:27 by StanKju
Additions:
ou=ca,ou=pki,dc=organisation,dc=com
cn=servname,ou=hosts,ou=pki,dc=organisation,dc=com
dn: cn=servname,ou=hosts,ou=pki,dc=organisation,dc=com
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:
$ 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/'`
Deletions:
ou=ca,dc=organisation,dc=com
cn=servname.organisation.com,ou=hosts,ou=pki,dc=organisation,dc=com
cn: servname.organisation.com
dn: cn=servname,ou=hosts,ou=pki,ou=organisation,dc=com
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,ou=organisation,dc=com//). A noter que si l'entrée //cn=servname,ou=hosts,ou=pki,ou=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:
$ FILE=`ldapsearch -x -t -u -b "cn=servname,ou=hosts,ou=pki,ou=organisation,dc=com" -H ldap://ldap -Z -LLL | grep "userCertificate;binary" | sed 's/userCertificate;binary:< file:\/\/\(.*\)/\1/'`


Revision [228]

Edited on 2007-04-05 10:34:16 by StanKju
Additions:
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é sur le serveur / l'interface web (génération du CSR) et sur le CA (Validation).
Concernant la validation, c'est l'operateur qui aura cette responsabilité. Celui-ci aura pour rôle de vérifier que les informations fournis sont correcte 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 ===
La copie du CSR se fait via SSH avec un compte particulier, ici //pkicsr//. Ceci permet de profiter des mécanisme de sécurité offert par SSH: authentification, chiffrement. N'ayant besoin que de copier des fichiers, nous allons mettre en place [[http://sublimation.org/scponly/ 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.
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.1 Package pki-server ===
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"". Ceci ne devra être fait qu'une seule fois:
PKI_PATH="/path/to/easy-rca"
source $PKI_PATH/vars
$PKI_PATH/clean-all
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'utilisateur de la partie serveur via le package //pki-client//.
Puis 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:
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 serra 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.
~- La révocation
~- La signature d'un certificat
Suite a ceci, il faudra publier le CRT ou le CRL.
La publication des CRT et CRL se fait en générant un fichier ldif puis en publiant les modification 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 corresponant au certificat souhaitant être publié (par exemple 01).
# Convert in DER format
$OPENSSL x509 -in $SERIAL.pem -outform DER -out $SERIAL.der
# Generate ldif file
{
/bin/cat < dn: cn=servname,ou=hosts,ou=pki,ou=organisation,dc=com
userCertificate;binary:< file://$KEY_DIR/$SERIAL.der
EOF
} > $SERIAL.ldif
# Push cert in LDAP directory
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,ou=organisation,dc=com//). A noter que si l'entrée //cn=servname,ou=hosts,ou=pki,ou=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.
La récupération du certificat depuis le LDAP se fait comme ceci:
$ # retreiving CRT from LDAP directory
$ FILE=`ldapsearch -x -t -u -b "cn=servname,ou=hosts,ou=pki,ou=organisation,dc=com" -H ldap://ldap -Z -LLL | grep "userCertificate;binary" | sed 's/userCertificate;binary:< file:\/\/\(.*\)/\1/'`
# Convert cert in PEM format
openssl x509 -inform DER -in $FILE -outform PEM -out $PKI_PATH/keys/servname.crt
# Display it
openssl x509 -in $PKI_PATH/keys/servname.crt -text -noout
Deletions:
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é sur le serveur ou l'interface web (génération du CSR) et sur le CA (Validation).
=== 2.1 package pki-client ===
La copie du CSR se fait via SSH avec un compte particulier, ici //pkicsr//. Ceci permet de profiter des mécanisme de sécurité offert par SSH: authentification, chiffrement. N'ayant besoin que de copier des fichier, nous allons mettre en place [[http://sublimation.org/scponly/ 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.
Le mot package n'est pas annodin, nous vous conseillons fortement de packager toutes ces choses pour pouvoir envisager un déploiement sur plusieurs serveurs.
=== 2.1 package pki-server ===
Ici il faudra, comme pour le package pki-server, installer ""OpenSSL"" et ""Easy-RCA"".
Generation: ...
Copie: ....
Recuperation ...
Commençons par la génération d'une clé privée et d'un CSR. Ceci ce fait de deux manières différentes qu'il s'agisse d'un certificat pour un serveur ou pour une personne. En effet, les serveurs disposent d'un package //pki-client// permettant la création de CSR via un script :
$ pki-client "servname"
****************
Creating CSR ...
****************
Generating a 1024 bit RSA private key
...........++++++
...........++++++
writing new private key to 'servname.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [FR]:
State or Province Name (full name) [Departement]:
Locality Name (eg, city) [Ville]:
Organization Name (eg, company) [Organisation]:
Organizational Unit Name (eg, section) [Service]:
Common Name (eg, your name or your server's hostname) [servname]:
Email Address [julien@organisation.com]:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
****************************
Uploading CSR to CA serv ...
****************************
servname.csr 100% 749 0.7KB/s 00:00
An email should be sent to the email specified in the CSR. You should reveive an other email once the certificate will be availaible.
Ce package inclus:
~- la clé privé ainsi que le pauthorized key our se connecter en SSH au CA
~- le script qui permet la génération du CSR et la copie en SSH
Concernant les personnes, il est possible de créer une interface en PHP permettant d'avoir un fonctionnement similaire (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'utilisateur de la partie serveur via le package //pki-client//
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 serra publique. Pour nous simplifier la vie nous avons une //crontab// qui détecte l'arrivée de nouvelle demande. Un mail est envoyé à l'initiateur du CSR (l'email est extrait du CSR) l'informant que sa requête est en cours de traitement. Un second mail est envoyé à l'opérateur chargé de la validation. Cette personne à pour rôle de vérifier que les information fournis sont correcte et respecte bien les conventions de l'entreprise (la personne travaille bien chez nous ?).
~- La révocation (et publication de la nouvelle CRL)
$ ./publish.sh --crl
~- La signature d'un certificat (et publication sur l'annuaire):
$ ./publish.sh --server "servname"
La publication des CRT et CRL se fait via le script publish.sh. Celui-ci génére les fichier ldif a la volée et les publie via un appel a //ldapmodify//. Il envois également un mail au demandeur pour l'informer que le certificat est disponible.
La récupération des assez simple, il suffit de relancer la commande:
%%
$ pki-client "servname"
CSR already generated, retreiving CRT ...
dn: cn=servname,ou=hosts,ou=pki,dc=organisation,dc=com
Le script va détecter qu'un CSR est présent mais qu'il manque le CRT. Il va alors essayer de le récupérer sur l'annuaire via un //ldapsearch//.


Revision [227]

Edited on 2007-04-04 18:15:59 by StanKju
Additions:
Ici il faudra, comme pour le package pki-server, installer ""OpenSSL"" et ""Easy-RCA"".
Generation: ...
Copie: ....
Recuperation ...
===3.4 Mise en place d'OCSP===
Deletions:
===3.5 Mise en place d'OCSP===


Revision [226]

Edited on 2007-04-04 18:09:44 by StanKju
Additions:
Une fois la configuration faite, il vous faudra générer les certificat 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 le lancer via la commande suivante:
# /usr/local/ocspd/sbin/ocspd -c /usr/local/ocspd/etc/ocspd/ocspd.conf -v
Ceci devrais vous donner les entrés 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
Deletions:
Une fois la configuration faite, il vous suffit de le lancer via la commande:
# ./sbin/ocspd -c etc/ocspd/ocspd.conf -v


Revision [225]

Edited on 2007-04-04 18:02:14 by StanKju
Additions:
Pour la configuration, il faudra aller voir du coté du fichier //vars//. Vérifiez que les différentes variables reflète bien votre installation.
La configuration se poursuit par le fichier openssl.cnf. Voici les déclarations pour mettre en place un certificat serveur, client et pour l'OCSP:
[ crl_dp ]
URI = ldap://ldaptest.infra.b2.p.fti.net/ou=ca,ou=pki,dc=fti,dc=net?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
[ 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
[ engine_section ]
[OCSP]
nsComment = "OCSP Responder"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
basicConstraints = critical,CA:FALSE
extendedKeyUsage = OCSPSigning
Deletions:
Pour la configuration, tout se fait dans le fichier //vars//. Vérifiez que les différentes variables refléte bien votre installation.


Revision [224]

Edited on 2007-04-04 17:57:25 by StanKju
Additions:
=== 2.1 package pki-client ===
Ce package inclus la mise en place d'""OpenSSL"", d'""Easy-RCA"" ainsi que la paire de clé 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écanisme de sécurité offert par SSH: authentification, chiffrement. N'ayant besoin que de copier des fichier, nous allons mettre en place [[http://sublimation.org/scponly/ 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.
Le mot package n'est pas annodin, 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"" mais aussi "SCPOnly".
===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écuperer 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, tout se fait dans le fichier //vars//. Vérifiez que les différentes variables refléte bien votre installation.
Il faut maintenant créer notre certificat racine pour le CA (--pass permet de mettre une //pass phrase// sur la clé privé):
$ 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""==
Nous allons créer le compte //pkicsr//:
Puis il vous faudra générer une paire de clé et mettre la clé publique dans le authorized_keys (/home/pkicsr/.ssh/authorized_keys).
ssh-keygen -t rsa -b 2048
Nous pouvons maintenant lancer un test de connexion sur notre CA en fournissant a SSH la clé privé du compte //pkicsr//:
$ scp -i clé_privé file pkicsr@machineCA:
$ ssh -i ma_clé_privé pkicsr@machineCA:
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
Enfin la configuration a proprement parlé:
[ 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
Deletions:
===3.1 Package pki-server===
cACertificate;binary:< file:///root/easy-rsa/2.0/keys/ca.der
certificateRevocationList;binary:< file:///root/easy-rsa/2.0/keys/crl.der
authorityRevocationList;binary:< file:///root/easy-rsa/2.0/keys/crl.der
===3.4 Copie en SSH===
La copie du CRT se fait via SSH. Ceci permet de profiter des mécanisme de sécurité offert par SSH: authentification, chiffrement. La connexion sur le CA se fait via un compte particulier, ici //pkicsr//.
N'ayant besoin que de copier des fichier, nous avons mis en place [[http://sublimation.org/scponly/ 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.
# ls /usr/bin/scponly
Creer /home/pkicsr/.ssh avec la clé publique dans le authorized_keys. Puis faire un test:
$ scp test pkicsr@machineCA:
$ ssh pkicsr@machineCA:


Revision [223]

The oldest known version of this page was created on 2007-04-04 11:43:03 by StanKju
Valid XHTML 1.0 Transitional :: Valid CSS :: Powered by WikkaWiki
Page was generated in 0.1653 seconds