|
Taille: 2003
Commentaire: on avance...
|
← 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: |
| = Ce qu'il faut faire = | * /CréationDesAutorités : procédures pour construire les clés et certificats des AC racine et régionales |
| Ligne 18: | Ligne 13: |
| 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. | * /DiffusionDesInformations : principe de diffusion les certificats et CRL de ces AC |
| Ligne 20: | Ligne 15: |
| 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 |
* /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 25: | Ligne 17: |
| = Etat du projet = | * 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: |
| * /NotesDeThomas avec notamment le fichier openssl.cnf proposé (à valider par ceux qui connaissent un peu openssl... y'en a, dans la salle ? ;) ) * /CréationDesAutorités |
= 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...). |
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...).