Politique de certification et procédures de l autorité de certification CNRS

Documents pareils
Certificats (électroniques) : Pourquoi? Comment? CA CNRS-Test et CNRS

Certificats X509 & Infrastructure de Gestion de Clés. Claude Gross CNRS/UREC

Mise en place progressive d une IGC (Infrastructure de Gestion de Clés - PKI) au CNRS

La sécurité des Réseaux Partie 7 PKI

PUBLIC KEY INFRASTRUCTURE. Rappels PKI PKI des Impôts PKI de la Carte de Professionnel de Santé

Public Key Infrastructure (PKI)

Mise en oeuvre d un intranet à partir de logiciels Open Source avec intégration des certificats numériques et login unique

Perso. SmartCard. Mail distribution. Annuaire LDAP. SmartCard Distribution OCSP. Codes mobiles ActivX Applet. CRLs

Certificats (électroniques) : Pourquoi? Comment?

Politique de Certification Autorité de Certification Signature Gamme «Signature simple»

Pour révoquer un Gestionnaire des Certificats : le Représentant Légal utilise la fiche n 2A en cochant la case appropriée.

ROYAUME DU MAROC Politique de certification - Autorité de Certification Externe -

Les certificats numériques

Installation et utilisation d'un certificat

Politique de Certification Pour les Certificats de classe 0 et 4 émis par l autorité de certification Notaires PUBLIÉ

La gestion des identités au CNRS Le projet Janus

Politique de Certification - AC SG TS 2 ETOILES Signature

Windows Server 2008 Sécurité ADMINISTRATION ET CONFIGURATION DE LA SECURITE OLIVIER D.

Certificats et infrastructures de gestion de clés

Du 03 au 07 Février 2014 Tunis (Tunisie)

Politique de Certification de l'ac INFRASTRUCTURE Profil Signature de jetons d horodatage

Fiche technique rue de Londres Paris Tél. : Mail : contact@omnikles.com

Contrat de Souscription : CA Certificat + Conditions Générales d Utilisation Annexe 2 : Guide de souscription

Politique de Certification

Les infrastructures de clés publiques (PKI, IGC, ICP)

POLITIQUE DE CERTIFICATION DE L'AC KEYNECTIS SSL RGS * (authentification serveur) Date : 12/08/2011

COMMUNICATION TECHNIQUE N TCV060 Ed. 01. OmniVista 4760 Nb de pages : 18 Date : URGENTE NON URGENTE TEMPORAIRE DEFINITIVE

PORTAIL INTERNET DE LA GESTION PUBLIQUE Guide d'utilisation du Portail Internet de la Gestion Publique

Autorité de Certification OTU

FORMATION SUR «CRYPTOGRAPHIE APPLIQUEE

Sommaire Introduction Les bases de la cryptographie Introduction aux concepts d infrastructure à clés publiques Conclusions Références

Cadre de Référence de la Sécurité des Systèmes d Information

Chapitre 7. Sécurité des réseaux. Services, attaques et mécanismes cryptographiques. Hdhili M.H. Cours Administration et sécurité des réseaux

Architectures PKI. Sébastien VARRETTE

Politique de Certification et Déclaration des pratiques de certifications de l autorité Tunisian Server Certificate Authority PTC BR

POLITIQUE DE CERTIFICATION AC RACINE JUSTICE

CERTEUROPE ADVANCED V4 Politique de Certification V1.0 Diffusion publique

EJBCA Le futur de la PKI

Gestion des Clés Publiques (PKI)

Guide d'initiation aux. certificats SSL. Faire le bon choix parmi les options qui s'offrent à vous en matière de sécurité en ligne. Document technique

Sécurisez votre serveur Web Internet Information Services de Microsoft (MS IIS) avec un certificat numérique de thawte thawte thawte thawte thawte

SOREGIES RESEAUX DISTRIBUTION

Modèle de sécurité de la Grille. Farida Fassi Master de Physique Informatique Rabat, Maroc May 2011

Politique de Certification de l'ac "ALMERYS SIGNATURE AND AUTHENTICATION CA NC" Référentiel : Sous-Référentiel : Référence : Statut :

Sécurisation des accès au CRM avec un certificat client générique

EJBCA PKI. Yannick Quenec'hdu Reponsable BU sécurité

Utilisation des certificats X.509v3

Créer et partager des fichiers

ScTools Outil de personnalisation de carte

1. Mise en œuvre du Cegid Web Access Server en https

Guide Numériser vers FTP

La sécurité dans les grilles

PORTAIL INTERNET DECLARATIF. Configuration du client Mail de MICROSOFT VISTA

28/06/2013, : MPKIG034,

La messagerie électronique avec La Poste

GLPI (Gestion Libre. 2 ième édition. Nouvelle édition. de Parc Informatique)

Microsoft Hosted Exchange 2010 DOCUMENT D EXPLOITATION

Signature électronique. Romain Kolb 31/10/2008

Démonstration Google Apps. Christophe Thuillier Avril 2010 Arrowsoft

INSTALLATION D UN CERTIFICAT FIDUCIO LOGICIEL

Sécurité WebSphere MQ V 5.3

PASS v2.0 : solution d authentification unique basée sur les composants Shibboleth Service Provider v2.5.1 et Identity Provider v2.3.

Cours 20410D Examen

Introduction aux services Active Directory

DNSSEC. Introduction. les extensions de sécurité du DNS. Les dossiers thématiques de l AFNIC. 1 - Organisation et fonctionnement du DNS

Mise à jour : Octobre 2011

Jean-Luc Archimbaud. Sensibilisation à la sécurité informatique.

Guide d'utilisation du portail d'authentification Cerbère à usage des professionnels et des particuliers

NOUVEAUTES de Microsoft Dynamics CRM 2011 REF FR 80342A

Configuration Et Résolution Des Problèmes Des Services De Domaine Active Directory Windows Server Référence Cours : 6238B

LEGALBOX SA. - Politique de Certification -

Informations sur l utilisation du webmail du CNRS. Webmail du CNRS. Manuel Utilisateur

Aristote Groupe PIN. Utilisations pratiques de la cryptographie. Frédéric Pailler (CNES) 13 janvier 2009

Banque Nationale de Belgique Certificate Practice Statement For External Counterparties 1

POLITIQUE DE CERTIFICATION. Autorité de certification «CERTEUROPE ADVANCED CA V3»

Intégrer le chiffrement et faciliter son intégration dans votre entreprise!

Documentation utilisateur "OK-MARCHE" Historique des modifications. 3.0 Mise à jour complète suite à version OK-MARCHE V2.2. de marchés publics

Cours 10219A: Configuration, Gestion Et Résolution Des Problèmes De Microsoft Exchange Server 2010

Groupe Eyrolles, 2004 ISBN :

I.1. Chiffrement I.1.1 Chiffrement symétrique I.1.2 Chiffrement asymétrique I.2 La signature numérique I.2.1 Les fonctions de hachage I.2.

EJBCA PKI Open Source

Processus 2D-Doc. Version : 1.1 Date : 16/11/2012 Pôle Convergence AGENCE NATIONALE DES TITRES SECURISÉS. Processus 2D-Doc.

Configuration du FTP Isolé Active Directory

GESLAB Fonctionnalités et Environnement

Les modules SI5 et PPE2

MANUEL D UTILISATION DE LA SALLE DES MARCHES APPEL D OFFRES OUVERT ACCES ENTREPRISES. Version 8.2

MINISTÈRE DES SOLIDARITÉ ET DE LA COHÉSION SOCIALE

Réflexion autour des Bases de données pour la gestion du personnel. Administration locale

La gestion des boîtes aux lettres partagées

AIDE ENTREPRISE SIS-ePP Plateforme de dématérialisation des marchés publics

POLITIQUE DE CERTIFICATION DE L AC : Crédit Agricole Cards and Payments

SSL. Secure Socket Layer. R. Kobylanski janvier version 1.1 FC INPG. Protocole SSL Application avec stunnel

Introduction aux services de domaine Active Directory

POLITIQUE DE CERTIFICATION DE L AC : Crédit Agricole Cards and Payments

TheGreenBow IPsec VPN Client. Guide de Déploiement Options PKI. Site web: Contact:

LES IMPACTS SUR VOTRE SYSTEME DE FACTURATION DE LA SIGNATURE ELECTRONIQUE COMME OUTIL DE SECURISATION DE VOS ECHANGES DEMATERIALISES

NORMES TECHNIQUES POUR UNE INTEROPERABILITE DES CARTES D IDENTITE ELECTRONIQUES

Manuel d utilisation du Guichet électronique V2

Autorité de Certification OTU

Transcription:

Politique de certification et procédures de l autorité de certification CNRS V2.1 1 juin 2001 Jean-Luc Archimbaud CNRS/UREC Directeur technique de l UREC Chargé de mission sécurité réseaux informatiques au CNRS Ce document décrit les choix de services, d organisation et techniques de l autorité de certification CNRS. Il sera complété au fur et à mesure de la mise en place de cette autorité. En février 2000 a été mise en place une autorité de certification CNRS-Test. Les buts (tests) sont décrits dans l article http://www.urec.fr/securite/articles/ca.cnrs-test.pdf et le mode opératoire dans les pages en ligne http://www.services.cnrs.fr/ca/. En juin 2000 le CNRS a pris la décision de créer une autorité de certification et d en confier la mise en place à l UREC : http://www.urec.cnrs.fr/securite/certifications/decision_creation_ac_cnrs.pdf. Depuis cette date, un comité de pilotage animé par C. Michau Directeur de l UREC et un comité technique animé par moi-même travaillent pour définir la politique de certification et les procédures. Ce qui a été mis en place et ce qui est décrit dans ce document découlent des décisions de ces comités. En parallèle, le développement d un logiciel IGC (Infrastructure de Gestion de Clé) pour les besoins du CNRS s adaptant à la structure de l organisme a été réalisé à partir d'outils du domaine public, OpenSSL en particulier. Une première version de ce développement est opérationnelle. En mai 2001, a débuté la mise en place de sites pilotes utilisant les logiciels développés et les procédures définies pour délivrer des certificats : délégations de Bordeaux et Toulouse, laboratoire LAAS, fédération IMAG, projet européen de calcul distribué datagrid, groupe des coordinateurs et des correspondants sécurité, comités d'organisation et de programme de la conférence JRES2001. Actuellement des certificats ont déjà été distribués sur ces sites et commencent à être utilisés principalement pour le contrôle d accès à des serveurs Web (authentification de l'utilisateur, accès en lecture ou écriture à certaines pages,...) et à des listes de diffusion ainsi que pour la signature de messages électroniques. Politique de certification et procédures de l autorité de certification CNRS 1

1 Des certificats pour qui? Des certificats pour les personnes, des certificats pour les services (serveur Web, routeur, ) et des certificats pour signer du code de programme (applet JAVA par exemple) seront délivrés. Dans la phase pilote seuls des certificats de personnes et de services sont délivrés, dans les sites et projets pilotes ainsi qu'à quelques entités pour des tests. 1.1 Pour les personnes Toute personne : o qui travaille dans un laboratoire ou service CNRS (agents CNRS ou non, permanents, temporaires, stagiaires, thésards, invités, ), o qui est agent CNRS mais ne travaille pas dans une unité CNRS, o d un organisme partenaire et qui a besoin de certificat dans le cadre de ses collaborations avec le CNRS, peut obtenir un certificat de l autorité de certification CNRS. 1.2 Pour les services Tout service et tout équipement dans un laboratoire CNRS ou fonctionnant pour le compte du CNRS ou utilisé par de nombreux utilisateurs CNRS peut obtenir un certificat CNRS. La demande doit être validée et faite par l autorité d enregistrement de l unité propriétaire ou gestionnaire. Politique de certification et procédures de l autorité de certification CNRS 2

2 Des certificats pour quel usage? Par défaut les certificats délivrés ne sont pas réservés à une application ou à un ensemble d applications bien délimité. Ils pourront être utilisés pour la messagerie électronique, le contrôle d accès à des pages Web et à des applications, la diffusion électronique de notes administratives signées, Coté utilisateur, les certificats sont conçus pour être utilisable au moins par les versions récentes des clients Netscape et Internet Explorer (et Outlook). La DCSSI (Direction Centrale de la Sécurité des Systèmes d'information) recommande 2 types de certificats : o Pour la signature (authentification et intégrité). Dans ce cas l utilisateur est seul à connaître sa clé privée ; o Pour le chiffrement (confidentialité). Dans ce cas il est recommandé que l autorité de certification (ou un service) assure le séquestre des clés privées de tous les utilisateurs pour en particulier pouvoir les restituer en cas de perte. L autorité de certification CNRS délivrera donc à terme les 2 types de certificats recommandés par la DCSSI, avec des procédures différentes et des options de séquestre différentes. Dans la phase pilote ne seront délivrés que des certificats pour l authentification et l intégrité, sans séquestre de clé privée. Politique de certification et procédures de l autorité de certification CNRS 3

3 Autorités et certificats 3.1 Autorités de certification Il n existe pas actuellement d autorité de certification française gouvernementale qui pourrait certifier l autorité CNRS. Celle-ci est donc auto-signée dans un premier temps. Si cette configuration changeait, ce choix pourrait être modifié. L arborescence d autorités suivante est mise en place Une autorité racine «CNRS» est créée et au second niveau, plusieurs autorités filles : o Une autorité CNRS-Standard (signée par l autorité CNRS) : délivre des certificats utilisateurs, des certificats de services et de codes pour des utilisations courantes. Dans la phase pilote des certificats CNRS-Standard sont délivrés aux utilisateurs du LAAS, de l IMAG et des laboratoires des délégations de Bordeaux et Toulouse. o Une autorité CNRS-Plus (signée par l autorité CNRS) : délivre des certificats utilisateurs pour des «actes importants» aux personnes ayant une fonction de direction. Dans la phase pilote, les autorités d enregistrement des sites pilotes ont des certificats CNRS-Plus. o Une autorité CNRS-Projets (signée par l autorité CNRS) dont de but est de pouvoir délivrer des certificats (utilisateurs, services ou codes) pour des projets. Ces projets ont pour la plupart une durée de vie limitée, avec éventuellement la participation d autres organismes que le CNRS. Sous cette autorité on créera autant de sous autorités que de projets. Dans la phase pilote ont été créés 3 sous arborescences (signées par l autorité CNRS-Projets) : Datagrid-fr pour le projet Datagrid, SSI (comme Sécurité des Systèmes d Information) pour les coordinateurs et correspondants sécurité et JRES. CNRS CNRS-Standard CNRS-Plus CNRS-Projets Datagrid-fr SSI JRES Politique de certification et procédures de l autorité de certification CNRS 4

L autorité CNRS-Test continue d exister pour les mêmes besoins de tests mais en utilisant le nouveau logiciel IGC et les nouvelles procédures pour délivrer et gérer les certificats. 3.2 Les certificats de personnes Ils sont au format X509V3. Ils utilisent un algorithme de chiffrement RSA avec des clés de 1024 bits par défaut (512 ou 2048 éventuellement). Ils sont délivrés par défaut pour une période de 1 an dans le cas de personnel permanent. Dans le cas de personnel temporaire la durée est limitée à la durée du contrat pour les contrats inférieurs à un an. Le champ CN (Canonical Name) contient le prénom, le prénom et l adresse électronique de la personne. Les autres champs du DN (Distinguished Name) sont remplis différemment selon les caractéristiques de la personne et selon l autorité de certification. Pour les certificats émis par les autorités CNRS-Standard et CNRS-Plus : o Si la personne travaille dans une unité ou un service CNRS (même si elle n'est pas agent CNRS) : C=FR, O=CNRS, OU=Code unité o Si la personne est agent CNRS mais travaille dans un service d un autre organisme : C=FR, O=CNRS, OU= Code Labintel du service o Si la personne n est pas agent CNRS et travaille chez un partenaire : C=Vide, O=EXTERNE, OU=Vide Pour les certificats émis par les autorités sous l autorité CNRS-Projets, le contenu des différents champs se fait en accord avec le responsable du projet. Dans la phase pilote : o Datagrid-fr : C contient le code pays (pas uniquement FR, si la personne n est pas française), O le nom de l organisme (CNRS ou CEA ou CS ou ), OU le code ou le nom du laboratoire ou du service. o SSI : C=FR, O=CNRS, OU=Code unité 3.3 Les certificats de services Le DN contient le nom de la machine sous forme de domaines, en utilisant un alias de la machine pour faire apparaître le nom du service (Exemples : www.urec.cnrs.fr pour un service Web, abintel.cnrs.fr pour un serveur labintel national) et l'adresse électronique de l'administrateur du service. 3.4 Autorités d enregistrement pour CNRS-Standard Pour chaque unité ou service, une personne a autorité pour valider les demandes de certificat CNRS-Standard du personnel (mais aussi des services et des codes de programmes) de cette unité ou de ce service. Elle est autorité d enregistrement. Cette personne est par défaut le directeur. Celui- Politique de certification et procédures de l autorité de certification CNRS 5

ci peut déléguer cette fonction à une personne de confiance de son unité qui agira en son nom pour ces procédures. Chaque autorité d enregistrement a un certificat CNRS-Plus qui est utilisé pour ces procédures. 3.5 Autorités d enregistrement des sous-autorités de CNRS-Projets Pour chaque projet, une personne a autorité pour valider les demandes de certificat pour les personnes travaillant dans le projet, ainsi qu éventuellement les services et les codes de programmes du projet. Cette autorité d enregistrement est par défaut le responsable du projet (pour le CNRS). Celui-ci peut déléguer cette fonction à une autre personne pour ces procédures. Chaque autorité d enregistrement a un certificat CNRS-Plus qui est utilisé pour ces procédures. 4 Procédures pour délivrer un certificat 4.1 CNRS-Standard ou de sous-autorité de CNRS-Projets de personne, sans séquestre de clé privée Ces certificats sont destinés à l authentification et à la signature (authentification et intégrité). Ils peuvent être utilisés pour la confidentialité (chiffrement) si l utilisateur prend soin de sauvegarder de manière très fiable sa clé privée. Pour chaque unité ou service ou projet, il existe une autorité d enregistrement. Cette autorité d enregistrement possède un certificat CNRS-Plus. La chronologie de la création de certificat pour un utilisateur est la suivante : o L utilisateur avec Netscape ou Internet Explorer accède à un formulaire électronique en ligne. Ce formulaire lui demande son nom, prénom, adresse électronique, toutes les données qui vont figurer dans son certificat. Le formulaire rempli, la création d un couple de clés privée-publique est provoquée sur le poste utilisateur. Le poste utilisateur conserve la clé privée, la clé publique est «récupérée» par le serveur. o Un message électronique, pour confirmation et vérification d adresse électronique, est envoyé à l utilisateur, qui l acquitte. o Le formulaire (avec la clé publique de l utilisateur) est stocké dans un spool. L autorité d enregistrement est avertie par messagerie électronique qu une demande de certificat est arrivée. o L autorité d enregistrement accède à cette demande avec son navigateur et son certificat CNRS-Plus. Elle vérifie les informations contenues dans la demande, contacte le demandeur pour vérifier qu il a bien fait cette demande (et possède la clé privée associée). Si tout est bon, elle acquitte la demande. Celle-ci est transmise à l autorité de certification. o L autorité de certification (un automate) crée le certificat, le dépose sur un serveur Web et dans l annuaire LDAP des certificats CNRS, puis envoie un message électronique à l utilisateur. o L utilisateur récupère son certificat sur le serveur Web. Les différentes demandes et toutes les opérations sont archivées. Politique de certification et procédures de l autorité de certification CNRS 6

Cette procédure sera affinée après le bilan de la phase pilote. 4.2 CNRS-Standard de service, sans séquestre de clé privée La procédure est identique à celle utilisée pour les personnes. L utilisateur demandeur doit être l administrateur du service et il doit déjà posséder un certificat de personne. 5 Révocation des certificats Dans la phase pilote les certificats peuvent être révoqués uniquement par l autorité d enregistrement. 6 Service de séquestre et de recouvrement de clés privées Dans la phase pilote ce service n est pas assuré. L UREC n a connaissance à aucun moment de la clé privée des utilisateurs. Ce sont à eux de sauvegarder leurs clés privées. 7 Accès aux formulaires, certificats Pour demander un certificat, obtenir le certificat et la liste de révocation de l autorité de certification, rechercher les certificats d autres utilisateurs : CNRS/CNRS-Standard : http://igc.services.cnrs.fr/cnrs-standard/ CNRS/CNRS-Plus : http://igc.services.cnrs.fr/cnrs-plus/ CNRS/CNRS-Projets/Datagrid-fr : http://igc.services.cnrs.fr/datagrid-fr/ CNRS/CNRS-Projets/SSI : http://igc.services.cnrs.fr/ssi/ CNRS-Test : http://igc.services.cnrs.fr/cnrs-test/ Politique de certification et procédures de l autorité de certification CNRS 7