|
Taille: 2703
Commentaire: hop, discussion rapidement terminée ;-)
|
Taille: 2237
Commentaire: Accord total de toutes les parties (au pire, l'AC racine pourra produires d'autres AC que les régionales...)
|
| Texte supprimé. | Texte ajouté. |
| Ligne 15: | Ligne 15: |
''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 */ |
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.
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)
- plus tard 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).
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
établir les instructions permettant de générer les certificats (commandes openssl)
- établir le processus de mise en place et de diffusion des CRL
Etat du projet
- 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 auf-igc... Voir /NotesDeThomas
- 25 février : ben c'est demain, on verra !