|
Taille: 2703
Commentaire: hop, discussion rapidement terminée ;-)
|
← 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 1: | Ligne 1: |
| Note : le titre «PKI» un peu pompeux, notre projet n'a pas l'ambition de créer une véritable PKI avec tout ce qui va autour. Il s'agira juste d'un système permettant d'émettre des certificats et (phase suivante) de les révoquer, le tout avec une gestion des autorités de certification à deux niveaux (régionalisation). Rien de plus pour l'instant. | ## page was renamed from Projet/PKI |
| Ligne 3: | Ligne 3: |
| = Objectif = | ||<#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 5: | Ligne 5: |
| 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, openvpn, etc. * les utilisateurs, surtout pour l'accès au RPV via openvpn (aka ''RPV1.5'') * plus tard pour le RPV2 (liaisons openvpn inter-sites) |
= Etat du projet, ce qui reste à faire = |
| Ligne 10: | Ligne 7: |
| 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 |
* Pré-requis à valider : les responsables techniques régionaux (RTR) doivent savoir utiliser un peu OpenSSL et comprendre les principes de la gestion de certificat. |
| Ligne 14: | Ligne 9: |
| 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). | * Un fichier de configuration de ''openssl'' (`openssl-auf.cnf`) régit le fonctionnement de ''openssl'' dans le cadre de notre PKI. Il est [[http://git.auf.org/?p=pki;a=blob;f=ca-certificates-auf/openssl-auf.cnf;hb=HEAD|disponible ici]]. Il est validé à 95% par... moi tout seul. Help wanted ! |
| Ligne 16: | Ligne 11: |
| ''A discuter : est-il nécessaire d'avoir des AC "nationales" pour la création plus rapides de certificats locaux ? Je ne le pense pas, j'estime que les responsables régionaux doivent être capables de pouvoir émettre les certificats pour toute leur région... Ca rend le système un poil plus "sécure" de limiter le nombre d'AC. Mais je suis ouvert à la discussion... -- ThomasNoël'' /* tu parles, charles ! */ /* Non. Fin de discussion. ;-) -- ProgFou */ | * /CréationDesAutorités : procédures pour construire les clés et certificats des AC racine et régionales |
| Ligne 18: | Ligne 13: |
| = Ce qu'il faut faire = | * /DiffusionDesInformations : principe de diffusion les certificats et CRL de ces AC |
| Ligne 20: | Ligne 15: |
| Nous considérons que les responsables techniques régionaux (RTR) doivent savoir utiliser un peu OpenSSL et comprendre les principes de la gestion de certificat. Si ce n'est pas le cas, lire [[http://fr.wikipedia.org/wiki/Public_Key_Infrastructure|un peu de doc]] devrait suffire. | * /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 |
| Ligne 22: | Ligne 17: |
| A partir de là, nous allons : * construire un fichier `openssl.cnf` standard avec les paramètres régissants les différents types de certificats que nous voulons gérer * établir les instructions permettant de générer les certificats (commandes `openssl`) * établir le processus de mise en place et de diffusion des CRL |
* Le code est sur http://git.auf.org/?p=pki. Si vous voulez voir son évolution du code, abonnez-vous au [[http://git.auf.org/?p=pki;a=rss|flux RSS]] correspondant. |
| Ligne 27: | Ligne 19: |
| = Etat du projet = | = Questions en suspension = |
| Ligne 29: | Ligne 21: |
| * 23 février 2008 : Thomas se porte volontaire pour continuer ce projet qui (qu'il) se traîne depuis 4 ans... Quel héroïsme. * nuit du 23 au 24 février : Thomas dors au lieu d'y bosser, c'est nul * 24 février 2008 : relecture, ré-appropritaion et reprise des éléments de [[http://trac.sn.auf.org/rpv2/browser/auf-igc|auf-igc]]... Voir /NotesDeThomas * 25 février : ben c'est demain, on verra ! |
* 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...). |
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...).