|
Taille: 2668
Commentaire: pour laisser une trace quelque part
|
Taille: 3397
Commentaire: baratinage sur l'avancement
|
| 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. | 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<<FootNote(Ceci étant, comme les certificats ne peuvent pas être modifiés, nous devons dès maintenant leur donner les extensions qui permettront une évolution vers une "vraie" PKI, notamment pour une réelle gestion des révocations. C'est tout l'objet de la recherche du ''bon'' fichier `openssl.cnf`)>>. Projet suivi par ThomasNoël. '''Merci de le contacter si vous avez quelques connaissances sur le sujet ou du temps pour tester des trucs.''' |
| Ligne 7: | Ligne 9: |
| * les utilisateurs, surtout pour l'accès au RPV via openvpn (aka ''RPV1.5'') * plus tard pour le RPV2 (liaisons openvpn inter-sites) |
* les utilisateurs, surtout pour l'accès au RPV via [[OpenVPN]] (aka ''RPV1.5'') * pour le RPV2 (liaisons openvpn inter-sites) |
| Ligne 14: | Ligne 16: |
| 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). ''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 ! */ |
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 voire OCSP). |
| Ligne 23: | Ligne 23: |
| * 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 |
* construire un fichier `openssl.cnf` standard avec les paramètres régissants les différents types de certificats que nous voulons gérer : '''ok''', c'est fait et validé à 95% (par moi tout seul) * construire les clés et certificats des AC racine et régionales * diffuser les certificats de ces AC racines, et donc établir les formats et principes de cette diffusion : c'est en cours, voir les idées sur igc.auf.org sur /NotesDeThomas * établir les instructions permettant de générer les certificats (commandes `openssl`) par les AC. Il faut notamment se mettre d'accord sur le format des DN dans les certificats * établir le processus de mise en place et de diffusion des CRL par les AC : en cours sur igc.auf.org |
| Ligne 29: | Ligne 31: |
| * 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 : dodo de Thomas * 24 février 2008 : relecture, ré-appropritaion et reprise des éléments de [[http://trac.sn.auf.org/rpv2/browser/auf-igc|auf-igc]], `openssl.cnf` en préparation : [[attachment:openssl.cnf]] * 25 février : ben c'est demain, on verra ! |
* bouts de code en cours : http://git.auf.org/?p=pki, dont le fichier `openssl.cnf` qui détermine notre utilisation de OpenSSL (merci à ceux qui connaissent un peu de donner leur avis sur ce fichier) * Si vous voulez me voir travailler, abonnez-vous au flux RSS du git : http://git.auf.org/?p=pki;a=rss * /CréationDesAutorités : a priori c'est ok, il reste à définir comment diffuser les certificats de ces AC (étude des formats PKCS utiles, création d'un paquet générique ca-certificates-auf, distribution dédiée à openvpn et à d'autres clients spécifiques, etc.) * /NotesDeThomas : mes recherches et tests en cours... ---- ''Note de bas de page'' |
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'instant1.
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, openvpn, etc.
les utilisateurs, surtout pour l'accès au RPV via OpenVPN (aka RPV1.5)
- pour le RPV2 (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 voire OCSP).
Ce qu'il faut faire
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 un peu de doc devrait suffire.
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 : ok, c'est fait et validé à 95% (par moi tout seul)
- construire les clés et certificats des AC racine et régionales
diffuser les certificats de ces AC racines, et donc établir les formats et principes de cette diffusion : c'est en cours, voir les idées sur igc.auf.org sur /NotesDeThomas
établir les instructions permettant de générer les certificats (commandes openssl) par les AC. Il faut notamment se mettre d'accord sur le format des DN dans les certificats
- établir le processus de mise en place et de diffusion des CRL par les AC : en cours sur igc.auf.org
Etat du projet
bouts de code en cours : http://git.auf.org/?p=pki, dont le fichier openssl.cnf qui détermine notre utilisation de OpenSSL (merci à ceux qui connaissent un peu de donner leur avis sur ce fichier)
Si vous voulez me voir travailler, abonnez-vous au flux RSS du git : http://git.auf.org/?p=pki;a=rss
/CréationDesAutorités : a priori c'est ok, il reste à définir comment diffuser les certificats de ces AC (étude des formats PKCS utiles, création d'un paquet générique ca-certificates-auf, distribution dédiée à openvpn et à d'autres clients spécifiques, etc.)
/NotesDeThomas : mes recherches et tests en cours...
Note de bas de page
Ceci étant, comme les certificats ne peuvent pas être modifiés, nous devons dès maintenant leur donner les extensions qui permettront une évolution vers une "vraie" PKI, notamment pour une réelle gestion des révocations. C'est tout l'objet de la recherche du bon fichier openssl.cnf (1)