Trusted Certificate Service Le service de certificats de

Trusted Certificate Service
Le service de certificats de RENATER
Marc TURPIN
GIP RENATER
23-25 Rue Daviel
75013 Paris
Résumé
Depuis 2005, RENATER propose un service de certificats X.509 à sa communauté. L’objectif de ce
service est très simple : fournir aux établissements des certificats serveurs X.509 « pop-up free », donc
émis par une autorité de certification reconnue nativement par les navigateurs.
Ce service évolue pour s’adapter aux demandes et aux attentes de la communauté Education/Recherche.
En 2014, lors du renouvellement du marché géré par l’association GÉANT (fusion de TERENA et de
Dante), la société DigiCert a été choisie pour opérer les nouvelles Autorités de Certification (AC) du
service TCS. DigiCert est un acteur majeur du CA/Browser Forum, de l’IETF (Internet Engineering Task
Force), du TAGPMA (Americas Grid Policy Management Authority) et de l’EUGridPMA (European
Policy Management Authority for Grid Authentication). Ce choix permet d’étendre la gamme de
certificats disponibles, de simplifier et accélérer les processus de validation et de mettre à disposition un
portail plus ergonomique.
Au lancement du service, il ne s’agissait que de certificats serveurs. Mais ces dernières années, le service
a été élargi pour inclure des certificats personnels et de signature de code. Il est alors devenu TCS
(TERENA Certificate Service) et 29 NREN 1européens profitent de ce service.
Depuis juillet 2015, le service TCS propose, dans sa nouvelle version, la possibilité de chiffrement des
communications client/serveur, la signature de mails, le chiffrement de mails, la signature de documents,
l’authentification et la signature de code.
En France, 338 établissements ont adhéré au service TCS auprès de RENATER.
Mots-clefs
TCS, SCS, PKI, Certificats X.509, SSL, TLS, sécurité, réseau, EV certificates
1 Introduction
Pour sécuriser les échanges et garantir la confidentialité et l'intégrité des données qui transitent sur les
réseaux, nous choisissons principalement de déployer les protocoles SSL/TLS. Ces protocoles s'appuient
sur des certificats X.509 pour l'authentification et le chiffrement des données.
X.509 est une norme de cryptographie pour les infrastructures à clés publiques (PKI). X.509 établit entre
autres un format standard de certificat électronique et un algorithme pour la validation de chemin de
certification2.
1
National Research and Education Network
Contenu soumis à la licence CC-BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0/deed.fr) Source : Article X.509 de
Wikipédia en français (http://fr.wikipedia.org/wiki/X.509).
2
JRES 2015 - Montpellier
1/9
Les logiciels comme les navigateurs Web ou les clients de messagerie détiennent des certificats racines de
nombreuses autorités de certification (AC) commerciales ou gouvernementales. Quand un navigateur
ouvre une connexion sécurisée (TLS/SSL) vers un site possédant un certificat émis par une autorité
connue, il considère le site comme sûr dans la mesure où le chemin de certification est validé. Le passage
en mode sécurisé est alors transparent.
Le processus conduisant à publier un certificat racine dans l'ensemble des logiciels est long, complexe et
coûteux. Seules, ou presque, les AC de la sphère commerciale y parviennent. Cela induit une complexité
administrative pour l'achat des certificats (paiement par carte, appel d'offres...) et fait intervenir différents
services de l'établissement au delà du service technique concerné. En outre, le coût d'achat pour un grand
nombre de certificats peut être jugé excessif pour une généralisation dans les établissements. Organisé au
niveau européen, le service de certificats est le résultat d'appels d'offres visant à réduire les coûts pour un
large déploiement. Le GIP RENATER encourage l'usage de ces services afin de simplifier les procédures
administratives et d’accroitre le niveau de confiance des services proposés par sa communauté.
La première déclinaison du service, nommée SCS (pour Serveur Certificate Service, lancé en 2005), a
rencontré un franc succès, notamment en France où il était opéré par le CRU3 pour les établissements
d’enseignement supérieur sous tutelle du ministère. Fin 2009, un nouveau service nommé TCS (pour
TERENA Certificate Service) a pris le relais. Il se voulait plus souple à l’utilisation, plus simple et plus
rapide. Depuis 2015, en adéquation avec l’évolution des exigences de sécurité et des menaces, le service
ne cesse d’évoluer et les besoins en certificats sont croissants. C’est pourquoi le nouveau service TCS
(pour Trusted Certificate Service), offre en outre une gamme encore plus variée de certificats, eux-mêmes
plus largement reconnus par des clients plus divers.
2 Présentation générale
2.1
SCS par GlobalSign (Version G1)
En avril 2005, TERENA a lancé une invitation à qui voulait participer à l'initiative « pop-up free low cost
certificates ». Partant du constat d'un réel besoin en certificats serveurs dans tous les réseaux académiques
européens et de leur exposition aux mêmes difficultés, TERENA suggérait qu'il valait sans doute mieux
faire appel tous ensemble à un prestataire commercial reconnu dans les principaux navigateurs. Les
objectifs tenaient en trois phrases :
̶
la possibilité pour tous les établissements d'enseignement d'obtenir des certificats serveurs
dont l'utilisation ne provoquerait pas l'apparition d'un « pop-up » dans le navigateur client
indiquant à l'usager qu'il ne « faisait pas confiance à ce certificat » ;
̶
obtenir ces certificats à des prix bien plus raisonnables que ceux pratiqués sur le marché ;
̶
permettre à chaque pays participant de mettre en place sa propre Autorité d'Enregistrement
(AE) plutôt que de la centraliser chez le prestataire, étant entendu qu'il n'y avait pas meilleur
connaisseur de ses propres usagers que le réseau académique national.
Cette initiative a pris la forme d'un appel d'offres élaboré par un groupe de travail composé d'au moins un
représentant des NREN de chaque pays intéressé par le projet. Le projet fut alors nommé SCS (Server
Certificates Service). RENATER, avec la coopération du CRU, a rejoint le projet. L'appel d'offres a été
lancé en août 2005 avec notamment, comme clause obligatoire, la présence dans les magasins d'AC des
navigateurs Internet Explorer et Mozilla/Firefox. Les clauses optionnelles prévoyaient une certaine
flexibilité dans la rédaction de la politique de certification et la possibilité pour chaque NREN de
proposer des pages web dédiées. À l'issue de cet appel d'offres, la société GlobalSign avait été choisie. Le
service a ouvert en mai 2006 pour une durée initiale d'un an, renouvelé par la suite pour trois ans.
3
Le CRU (Comité Réseau des Universités) a cessé d’exister en 2011, date à laquelle il a été intégré à RENATER.
JRES 2015 - Montpellier
2/9
En quatre ans d'exploitation, le CRU a validé 3581 certificats, dont 248 certificats « wildcard » auxquels
il convient d'ajouter les 891 certificats, dont 93 wildcards, délivrés par l'AE RENATER pour obtenir le
total en France. Nous pouvions donc considérer qu'il s'agissait d'un succès puisque, d'une part, ce service
a répondu à un réel besoin et, d'autre part, sur le plan économique, en se basant sur le tarif public de
l'opérateur GlobalSign, l'économie réalisée s'est avérée considérable.
2.2
TCS par Comodo (Version G2)
Forte de l'expérience de SCS, TERENA a regroupé une vingtaine de réseaux de la recherche en Europe,
dont RENATER, pour lancer un nouvel appel d'offres visant à faire évoluer le service. Cet appel d'offres
a débouché sur la signature d'un contrat pour trois ans entre TERENA et Comodo CA Limited. Le contrat
expiré en juin 2012 a été prolongé jusqu’en 2015.
Dans la continuité de SCS, le coût des certificats émis n'a pas été directement répercuté aux
établissements par RENATER. L'accord du responsable de l'établissement n'est requis qu’à la
souscription initiale au service. Les demandes de certificats ne sont, quant à elles, que du ressort du
personnel technique désigné. Par contre, les certificats en cours de validité sont maintenus au delà de la
date de fin du contrat, et leurs détenteurs conservent la possibilité de les révoquer jusqu'à leur expiration.
TCS propose plusieurs types de certificats, mais ils ne sont pas tous disponibles dans tous les pays,
chaque NREN ayant fait ses choix parmi les options proposées. Le GIP RENATER, le CRU et l'UREC
ont opté pour les certificats serveurs ainsi que les certificats personnels. Les certificats de signature de
code ont été ajoutés en 2015.
En France, 338 établissements ont adhéré au service TCS auprès de RENATER.
2.2.1
Certificats Serveurs
Deux catégories de certificats serveurs sont disponibles, les certificats DV (Domain Validation) et les
certificats OV (Organization Validation).
Les certificats DV apportent le niveau de confiance le plus faible. Le propriétaire du domaine doit
prouver qu’il a bien le contrôle exclusif de son domaine via un mécanisme dit « DCV » (Domain Control
Validation). Aucune information sur l’identité du demandeur n’est affichée dans le certificat ou le sceau
du site sécurisé.
subject=/OU=Domain Control Validated/CN=www.renater.fr
Les certificats OV apportent un niveau de confiance un peu plus élevé, car en plus des informations des
certificats DV, l’autorité de certification vérifie que le propriétaire du domaine est bien inscrit dans un
registre public afin de valider son existence légale. Les informations vérifiées apparaissent dans le sceau
de site sécurisé, pour une confiance accrue.
subject=/C=FR/ST=PARIS/L=PARIS/O=Reseau National de
Télécommunication pour La Technologie, L'Enseignement et la
Recherche/CN=www.renater.fr
Chacune de ces deux catégories de certificats permet l’utilisation de certificats standard, omni-domaines
et multi-sites (Unified Communication, wildcards, multi domaines)
JRES 2015 - Montpellier
3/9
Le nombre de certificats émis est en constante évolution depuis 2011.
NombredeCer*ficats
7000
6000
5000
4000
3000
2000
1000
0
2009
2010
2011
2012
2013
2014
Figure 1 - Evolution du nombre de certificats émis
JRES 2015 - Montpellier
4/9
Suite aux annonces de Microsoft et de Google concernant la dépréciation de SHA1 sur leurs outils,
Comodo a décidé de stopper l'émission de certificats SSL serveurs SHA1. En 2014, les autorités de
certification de TERENA ont évolué vers les signatures SHA-256.
2.2.2
Certificats Personnels
Les certificats personnels (TCS e-Science) sont également disponibles afin de permettre l’authentification
et la signature de mails. L’établissement souscrit au service et devient alors autorité d’enregistrement.
Figure 2 - Workflow pour les certificats personnels
2.2.3
Les Portails
Deux portails distincts, développés par la communauté des NREN européens, hébergés et opérés par
chaque NREN, sont disponibles pour les demandes de certificats. Le portail « Djangora » pour les
certificats serveurs et « Confusa » pour les certificats personnels. Courant 2014, le service de certificats
pour la « Signature de code » est intégré au portail « Djangora ».
2.3
TCS par DigiCert (Version G3)
L’association GÉANT (fusion de TERENA et de Dante), a choisi la société DigiCert pour opérer les
nouvelles Autorités de Certification (AC) du service TCS. DigiCert est un acteur majeur du CA/Browser
Forum, de l’IETF (Internet Engineering Task Force), du TAGPMA (Americas Grid Policy Management
Authority) et de l’EUGridPMA (European Policy Management Authority for Grid Authentication). Ce
choix permet d’étendre la gamme de certificats disponibles, de simplifier et accélérer les processus de
validation et de mettre à disposition un portail plus ergonomique.
JRES 2015 - Montpellier
5/9
2.3.1
Certificats serveurs
Deux catégories de certificats serveurs sont disponibles, les certificats de type OV (Organization
Validation) et les certificats de type EV (Extended Validation)
La version actuelle de TCS retire les certificats de type DV (niveau de confiance faible) et introduit les
certificats de type EV (niveau de confiance le plus élevé).
En plus des vérifications effectuées pour les certificats OV, l’autorité de certification vérifie que le
contact désigné dans l’organisation (EV Verified User) est bien un membre de l’organisation. Ce contact
EV donne son accord pour les demandes de certificats.
subject=/businessCategory=Private
Organization/1.3.6.1.4.1.311.60.2.1.3=FR/serialNumber=180 089 476
00055/street=23-25,
rue
Daviel/postalCode=75013/C=FR/ST=Paris/L=Paris/O=GIP
RENATER
(Reseau National de Telecommunications pour La Technologie,
L'Enseignement et la Recherche)/OU=EPA/CN=idp.renater.fr
Les certificats de type EV affichent dans la barre d’adresse de certains navigateurs une barre verte
affichant le nom de l’organisation et mettant le visiteur en confiance.
Chaque catégorie de certificat est déclinée en plusieurs produits permettant l’utilisation de certificats
standards, omni-domaines et multi-sites (Unified Communication, wildcards, multi domaines)
2.3.2
Certificats personnels
Destinés à l'authentification de l'usager ou à la signature de mails, la délivrance de ces certificats est régie
par une Déclaration des Pratiques de Certification (DPC)4 spécifique.
4
TCS Certification Practice Statement - Personal,
(https://www.terena.org/activities/tcs/repository-g3/)
JRES 2015 - Montpellier
eScience
Personal
and
Document
Signing
Certificates
6/9
Trois types de certificats client sont disponibles :
̶
les certificats de signature : ces certificats permettent l’authentification et la signature des
mails et des documents ;
̶
les certificats de chiffrement : ces certificats permettent uniquement le chiffrement des mails.
Les certificats permettent également le séquestre de clé privée et la récupération des données
chiffrées. Ce qui permet de récupérer les clés privée en cas d’urgence, comme la perte de la
clé, la cessation d’emploi, ou dans le cas d’une enquête criminelle ;
̶
les certificats « Premium » permettant l’authentification, la signature et le chiffrement. Le
séquestre de clés n’est pas disponible.
Dans la mesure où nous n’avons pas encore d’informations concernant le séquestre par l’autorité de
certification, il est demandé de ne pas utiliser les deux premiers types de certificat. Les certificats
« Premium » sont à privilégier.
Il y a deux modes de délivrance pour ces certificats, le mode « manuel » et le mode « sso-SAML ».
Les établissements inscrits dans la fédération d’identité eduGain5 ont la possibilité de lier leur fournisseur
d’identité (Identity Provider ou IdP) et le fournisseur de service (Service Provider ou SP) de DigiCert.
L’attribut « eduPersonEntitlement » définit si l’utilisateur a son identité vérifiée et s’il est autorisé à
obtenir un certificat.
Les établissements non fédérés doivent se référer au guide « (TCS Model Process Non­SAML Personal
Issuance 2015) » pour la délivrance de certificats en mode « manuel ». Les certificats ne doivent être
délivrés qu’après une vérification, en face à face, de la conformité de l’identité déclarée du demandeur.
2.3.3
Certificats de signature de code
Les certificats de signature de code augmentent la confiance en permettant la vérification de la source et
de l’intégrité de l’application par la signature numérique d’un programme afin de prouver qu’il n’a pas
été altéré ou compromis. La majorité des produits de développement sont pris en charge, Microsoft
Authenticode, Office VBA, Java, Adobe AIR, Mac OS, et les objets Mozilla. Ces certificats empêchent
l’affichage des messages d’avertissement et assurent que l’application est de confiance.
2.3.4
Certificats de signature de document
Les certificats de signature de document permettent de signer numériquement les documents bureautiques
via les programmes supportant la signature tels que Adobe Acrobat, Microsoft Office, OpenOffice,
LibreOffice en garantissant aux destinataires que le document a été émis par l’organisation et n’a pas été
modifié.
Le nom de l’organisation apparaît dans la signature. La clé privée et le certificat sont générés et stockés
sur un support cryptographique, instaurant une authentification à deux facteurs. Les certificats sont
conformes à l’U.S. Federal ESIGN Act et autres lois internationales associées6 (EU Directive 99/93).
2.3.5
Le portail
Les NREN ont fait le choix de ne plus supporter des solutions développées en interne comme les anciens
portails Djangora et Confusa, coûteux en ressources et limitées en possibilités.
Toutes les demandes de certificats se font dorénavant sur un portail unique (DigiCert CertCentral). Pour
plus de sécurité, l’authentification à deux facteurs est supportée par OTP ou certificat. Pour accroitre la
sécurité, il est également possible de restreindre l’accès au portail à certaines adresses IP.
5
6
Extension européenne et mondiale de la Fédération Education-Recherche https://services.renater.fr/federation/docs/fiches/edugain
DigiCert Certificate Policy https://www.digicert.com/docs/cps/DigiCert_CP_v401.pdf
JRES 2015 - Montpellier
7/9
Les souscripteurs du service sont autonomes dans la gestion de leur établissement. Ils gèrent eux-mêmes
leurs organisations, domaines, utilisateurs et demandes de certificats.
Le portail inclut un accès à l’API7 permettant le développement d’applications internes interagissant avec
le portail.
2.4
Souscrire au service
2.4.1
Qui ?
Le contrat entre GÉANT et les NREN définit l'abonné de la manière suivante :
•
Les abonnés sont les organisations de la communauté recherche et/ou éducation et/ou des
membres sans but lucratif d’un NREN demandant un certificat au travers d’un compte chez
l’opérateur d’AC.
Dans cette définition, « sans but lucratif » signifie les universités, les collèges, les écoles, les académies,
les établissements du conseil de recherche et instituts, bibliothèques, musées, sociétés savantes, les
associations caritatives qui sponsorisent l'éducation ou la recherche, des organisations soutenant la
recherche et l'éducation (dans ces cas, l'organisation peut utiliser le service uniquement dans le but
d'apporter un tel soutien) et d'autres organisations du secteur public financées par le gouvernement.
2.4.2
Comment ?
Pour souscrire au service de certificats TCS, l'établissement doit avoir signé la lettre d'engagement qui en
fixe les conditions d'utilisation. Cette lettre d’engagement est l’accord de souscription au service TCS.
Cette lettre d'engagement définit par ailleurs :
•
le nom officiel de l'établissement ;
•
la liste des personnes, dites « administrateurs », autorisées à valider les demandes de certificats
et de révocation, ainsi que la déclaration des organisations et des domaines.
Les administrateurs ont l'obligation de prendre connaissance de la documentation légale du service.
3 Conclusion
Outre la reconnaissance des certificats dans une plus grande variété de clients, TCS apporte une vraie
plus-value au niveau du service. Les contacts administratifs obtiennent désormais des certificats de façon
complètement autonome. Le service est disponible quel que soit le jour ou l'heure pour délivrer des
certificats en quelques minutes. L'AE n'intervient plus que pour enregistrer la souscription initiale de
l’établissement au service. Elle n’intervient plus pour les modifications demandées comme la liste des
contacts administratifs ou la liste des domaines.
Par son succès, SCS a montré qu'il était une réponse pertinente à la problématique du déploiement de
certificats serveurs, TCS l’a confirmé en y ajoutant d’autres certificats (personnels, signature de code).
Aujourd'hui, la nécessité de recourir à la certification par une autorité de confiance reconnue dans les
navigateurs sans configuration spécifique ne fait plus débat. L’utilisation massive de certificats est
désormais entrée dans les habitudes. Les utilisateurs sont en confiance à la vue d’un cadenas ou d’une
« barre verte » affichée sur leur navigateur ou encore à des mails signés numériquement.
7
Documentation for the DigiCert Services API https://www.digicert.com/services/v2/documentation/
JRES 2015 - Montpellier
8/9
Bibliographie
1.
European Parliament. « Community framework for Electronic Signatures, OJ L 13. » EU
Directive 99/93, Janvier 2000: 12-20.
2.
Guezou, Jean-François. « Impacts organisationnels du déploiement des certificats de personne
TCS. » JRES 2011. 2011. https://2011.jres.org/archives/91/paper91_article.pdf.
3.
Jean-François Guezou, Dominique Launay, et Serge Aumont. « SCS est mort, vive TCS ! »
JRES 2009. 2009. https://2009.jres.org/planning_files/article/pdf/76.pdf.
4.
« TCS
Model
Process
Non­SAML
Personal
Issuance. »
TCS
Wiki.
2015.
https://wiki.geant.org/download/attachments/44892300/TCS-Model-Process-Non-SAMLPersonal-Issuance-v1-rev1.pdf?version=1&modificationDate=1426785123106&api=v2.
JRES 2015 - Montpellier
9/9