|
Taille: 4158
Commentaire: on va passer à EJBCA
|
← Version 17 à la date du 2008-10-14 09:53:34 ⇥
Taille: 2426
Commentaire: ancienne piste en tôle ondulée
|
| Texte supprimé. | Texte ajouté. |
| Ligne 2: | Ligne 2: |
| Si vous ne savez pas ce que veut dire PKI, ou si vous ne savez pas exactement tout ce qui est en jeu, vous devez lire ceci : http://fr.wikipedia.org/wiki/Public_Key_Infrastructure | |
| Ligne 4: | Ligne 3: |
| Cependant notre projet n'a pas l'ambition de créer une véritable PKI avec tout ce qui va autour (RA, séquestration, etc) . Il s'agit juste d'un système permettant d'émettre des certificats et de les révoquer, le tout avec une gestion des autorités de certification à deux niveaux (une racine et des régionales) et une publication des listes de révocation la plus efficace possible (c'est le point faible de la plupart des PKI). Projet suivi par ThomasNoël. '''Merci de le contacter si vous avez quelques connaissances sur le sujet ou du temps pour tester des trucs.''' = Objectif = Il s'agit de mettre en place une PKI simple et souple afin de générer des certificats signés par une autorité de certification "AUF". Nous pourrons produire des certificats pour : * nos serveurs web, smtp, imap, jabber, etc. * les utilisateurs, surtout pour l'accès au RPV via [[OpenVPN]] (nomades) * pour le [[Projet/RPVv2]] (liaisons openvpn inter-sites) Le projet consiste à la mise en place d'un système de certification à deux niveaux : * une autorité de certification (AC) racine * des AC régionales, signées par l'AC racine L'autorité racine ne sera utilisée que pour générer des AC régionales. Les AC régionales seront celles qui signeront tous les certificats à émettre. Toutes les AC géreront leurs révocations (CRL). La publication des informations (surtout des CRL) se fera sur un serveur central igc.auf.org. |
||<#fcca00> '''Page archivée : il s'agit de l'ancienne façon de gérer la PKI, que nous avons abandonnée<<BR>>(trop complexe, surtout au niveau de la publication des révocations)<<BR>>La PKI déployée sera basée sur EJBCA, voir [[Projet/PKI]]'''|| |
| Ligne 40: | Ligne 24: |
= Autre orientation possible = Plutôt que d'utiliser nos propres outils basés sur OpenSSL, on pourrait passer par un logiciel de gestion de PKI comme [[http://ejbca.org|EJBCA]]. C'est en cours de test/validation. Voir notamment [[ThomasNoël/NotesEJBCA]] pour l'installation en cours sur http://igc.auf/ ---- ''Note de bas de page'' |
Page archivée : il s'agit de l'ancienne façon de gérer la PKI, que nous avons abandonnée
(trop complexe, surtout au niveau de la publication des révocations)
La PKI déployée sera basée sur EJBCA, voir Projet/PKI
Etat du projet, ce qui reste à faire
- Pré-requis à valider : les responsables techniques régionaux (RTR) doivent savoir utiliser un peu OpenSSL et comprendre les principes de la gestion de certificat.
Un fichier de configuration de openssl (openssl-auf.cnf) régit le fonctionnement de openssl dans le cadre de notre PKI. Il est disponible ici. Il est validé à 95% par... moi tout seul. Help wanted !
/CréationDesAutorités : procédures pour construire les clés et certificats des AC racine et régionales
/DiffusionDesInformations : principe de diffusion les certificats et CRL de ces AC
/UtilisationDesAutorités : instructions (commandes openssl) permettant de générer les certificats par les AC, et de les révoquer au besoin. Il faut notamment se mettre d'accord sur le format des DN dans les certificats en fonction de leur destination : serveurs Web/IMAP/SMTP, serveurs et clients OpenVPN RPV2, clients utilisateurs du RPV2, etc
Le code est sur http://git.auf.org/?p=pki. Si vous voulez voir son évolution du code, abonnez-vous au flux RSS correspondant.
Questions en suspension
le format des DN des certif : va être explicité sur /UtilisationDesAutorités (reprise des idées de RPVv2)
- diffuser les certificats de ces AC : étude des formats PKCS utiles... d'autres formats et protocoles ?
NextUpdate pour les CRL, que mettre ? Actuellement 1 mois. Si la durée est trop longue : les clients "automatiques" ne la rechargeront pas assez souvent. Si elle est trop courte et que l'AC ne la renouvelle pas à temps, ça sera révocation pour tout le monde... Ceci dit, c'est une valeur qui se change en cours de route, donc, bon... 2 mois ? 3 mois ? ou bien "cron" intelligent pour l'AC qui renouvelle la CRL 1 ou 2 jours avant son "expiration" (c'est la solution la plus jolie, qui veut la programmer ? piste à suivre, sans doute : lire "man crl" pour chercher comment connaitre la date d'expiration d'une CRL...).