Jean-François Guezou
Dominique Launay
Serge Aumont
Comité réseau des Universités (CRU)
Résumé
SCS, service européen coordonné par TERENA1, délivre des certificats serveurs « pop-up free », c'est à dire reconnus sans configuration spécifique dans une grande majorité des clients. Le succès de ce service ouvert début 2006 a été très important, notamment en France.
Le contrat liant TERENA à l'opérateur GlobalSign pour ce service arrive à son terme fin 2009. Les représentants des NREN2 participants ont souhaité une nouvelle consultation très ouverte pour avoir l'opportunité de faire évoluer ce service.
Un nouvel opérateur a été retenu, il s'agit de Comodo. Celui-ci propose des certificats serveurs encore plus largement reconnus dans les clients (navigateurs, PDA et téléphones), et de nouvelles options de certificats. Cette nouvelle version du service est ouverte aux utilisateurs depuis octobre 2009.
Après avoir dressé un bilan du service SCS, nous évoquerons les évolutions apportées par le nouveau service TCS et les options de certificats proposées.
La procédure technique et administrative d'accès au service est totalement nouvelle, nous en décrirons les principes et expliquerons comment éviter des dysfonctionnements sur les serveurs concernés par la migration. En effet l'engagement avec l'opérateur GlobalSign prévoit la révocation de tous les certificats en cours de validité à la fin de la période contractuelle. Ce sont donc près de 4500 certificats qui seront automatiquement révoqués fin février s'ils ne sont pas remplacés d'ici là.
Mots clefs
TCS, SCS, PKI, Certificats X509, SSL, TLS, sécurité, réseau, EV certificates
Pour sécuriser les échanges orchestrés par nos serveurs et garantir la confidentialité et l'intégrité des données qui transitent, nous choisissons principalement de déployer les protocoles SSL/TLS. Ces protocoles s'appuient sur des certificats X509 pour l'authentification et le chiffrement des données.
Un certificat X509 [1] c'est essentiellement l'association d'une clef publique et du nom de son titulaire, signée par une autorité de certification (AC)3. C'est la confiance accordée par le client exploitant le certificat (un navigateur par exemple) dans l'autorité de certification, qui lui permet de vérifier la validité du certificat (on parle alors d'autorité de confiance). Dans le cas contraire, le certificat de l'AC a peut-être été signé par une autre autorité de certification qui est elle-même une autorité de confiance. Si la chaîne de certification ainsi constituée ne contient pas d'autorité de confiance la vérification du certificat présenté ne peut être faite automatiquement. Lorsque ce cas se produit avec un navigateur web, l'usager doit intervenir et décider lui-même de faire ou non confiance au certificat présenté par le serveur avec lequel il entre en communication.
Tant que les services ainsi sécurisés sont déployés en interne et accédés via des postes de travail dont l'entité a la maîtrise, il est possible de les configurer pour que l'AC utilisée devienne une autorité de confiance. Cependant, les établissements sont confrontés à la généralisation des accès à leurs services via des navigateurs web installés sur des postes dont ils n'ont pas la maîtrise.
En l'absence de tiers de confiance, le navigateur de l'usager affiche une fenêtre sous forme de « pop-up » lui proposant de vérifier le certificat. En règle générale, il accepte l'authentification sans la contrôler puisqu'il n'a presque jamais les éléments pour décider de ce qu'il convient de faire. Il court ainsi le risque de se connecter à un serveur mal intentionné. La récurrence de ces messages d'avertissement de la non reconnaissance du certificat produit, conduit à une perversion du concept de certification. Cela annihile les efforts de sécurité notamment pour ce qui concerne la lutte contre le phishing. Pour lutter contre cette tendance, certains navigateurs comme Firefox, dans leurs dernières versions, ont rendu bien plus difficile l'accès à un site utilisant un certificat qui n'a pas été émis par une AC de confiance. Il ne suffit plus d'acquitter un « pop-up » d'alarme mais au contraire d'afficher les données du certificat et d'enchaîner plusieurs pages de mise en garde.
Les navigateurs, comme la plupart des clients implémentant les protocoles SSL/TLS, reconnaissent de base un certain nombre d'autorités de certification (AC) comme autorité de confiance. Utiliser des certificats fournis par l'une de ces AC permet d'éviter l'affichage des fenêtres d'avertissement et ainsi de ne pas concourir à leur banalisation. C'est donc non seulement un moyen d'améliorer le confort d'utilisation des services, mais c'est aussi un moyen d'améliorer la sécurité des clients.
Le processus conduisant à publier un certificat dans l'ensemble des configurations par défaut de l'ensemble des navigateurs 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'offre ...) 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 peu être jugé excessif pour une généralisation dans les établissements. C'est la raison d'être du service SCS relayé depuis le début du mois d'octobre par TCS. Organisés au niveau européen, ces services sont le résultat d'appels d'offres visant à réduire les coûts pour un large déploiement. Le GIP RENATER, partie prenante de cette opération, a choisi de ne pas répercuter ces coûts directement aux établissements mais de les intégrer dans son budget de fonctionnement. Ceci afin d'encourager l'usage de ces services et de simplifier les procédures administratives.
Le service nommé SCS (pour Serveur Certificates Service) a rencontré un franc succès, notamment en France où il était opéré par le CRU et par RENATER. A échéance fin 2009, arrive le temps d'en dresser un bilan, de dégager les principales raisons de ce succès mais aussi de lever les limitations rencontrées.
Un nouveau service, nommé TCS (pour TERENA Certificate Service), a pris le relais depuis le 1er octobre. Il se veut plus souple d'utilisation, plus simple et plus rapide. À nouveau service, nouveau processus explicité dans cet article. Il offre en outre une gamme plus variée de certificats, eux-mêmes plus largement reconnus par des clients plus divers4.
L'infrastructure de gestion de clés (IGC5) que le CRU exploitait, depuis 2003 pour sa dernière version, était de toute façon condamnée car vouée à rester un projet pilote. En effet, quelle que soit la qualité d'une IGC et la confiance qu'on peut accorder à ses processus de vérification et d'identification des demandeurs, la confiance effective que lui accorde un utilisateur se résume à la présence de l'autorité de certification (AC ) racine de cette IGC dans les AC de confiance de son navigateur favori.
Or le CRU n'a jamais eu l'intention de s'investir dans un processus de certification de son IGC afin qu'elle soit présente dans les navigateurs. Ceci, notamment en raison des coûts directs ainsi que des coûts induits en termes d'assurance et de personnel [2].
Le rôle de cette IGC ne pouvait alors que se cantonner à la sphère réduite des ressources internes aux CRI, sans diffusion, même vers les étudiants. En effet, protéger des ressources avec un certificat émis par cette IGC imposait un support technique alourdi, voire même l'absence d'audience de ces ressources en raison de leur difficulté d'accès selon les navigateurs.
Le besoin se faisait de plus en plus pressant, alors que plusieurs IGC gouvernementales ou académiques (Allemagne, Australie...) promettaient la future inclusion de leurs AC dans les navigateurs. Cette piste semblait toutefois incertaine en ce qui nous concernait. Elle aurait nécessité un nouvel audit pour être sur-signée et, dans le meilleur des cas, n'aurait pas couvert la sphère de tous les navigateurs couramment utilisés dans l'enseignement supérieur.
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'Enregistrement6 (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'offre é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. Si l'objectif premier de l'appel d'offre était de baisser les prix, la participation française nous a permis de faire valoir nos problématiques (certificats multi-nommés, certificats « wildcard »,...). L'appel d'offre 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'offre, c'est la société GlobalSign7 qui avait été choisie, pour une durée initiale d'un an, renouvelée par la suite pour trois ans.
Les RSSI étaient habitués à notre procédure d'obtention de certificats serveurs dans le cadre de l'IGC du CRU. L'Autorité d'Enregistrement se basait sur deux informations connues de nous :
la qualité de RSSI du demandeur : authentification par certificat client émis par nous et vérification de la présence de la personne identifiée dans l'annuaire des RSSI maintenu sous la responsabilité de la Direction de la Recherche
la connaissance des domaines (au sens DNS) utilisés par les établissements par le biais de la base ARES
La procédure était simple pour le demandeur de certificat, car il n'avait à se préoccuper que du nom de sa machine. Nous imposions le nom d'établissement (code UAI) et nous générions à la fois le certificat et la clé privée.
Lorsque le service SCS a démarré, les procédures mises en œuvre en ont dérouté plus d'un qui regrettaient déjà le « bon vieux temps ». En effet, le demandeur de certificat devait passer par l'interface du prestataire alors que celui-ci n'avait aucun moyen de vérifier la qualité du demandeur, ni son appartenance à tel établissement, ni même si l'établissement possédait bien le domaine concerné par la demande de certificat, l'ensemble de ces vérifications incombant à l'Autorité d'Enregistrement (AE).
Pour alléger la tâche, l'identification des demandeurs de certificats a été confiée aux opérateurs d'enregistrement (RENATER, et par délégation le CRU dans notre cas), selon un formalisme conforme à la politique de certification du prestataire. La liste des documents nécessaires à la vérification de chaque demande a été négociée et fixée afin de permettre des audits de vérification du respect des bonnes pratiques pour chaque opérateur. Ces audits des opérateurs d'enregistrement sont nécessaires au maintien par défaut de l'AC dans les navigateurs.
Pour ne pas répéter la procédure à chaque demande, le prestataire a défini une « proxy letter » (ou lettre de désignation), dans laquelle le chef d'établissement ou le responsable du service informatique désignait les « contacts administratifs » ou demandeurs de certificats de son établissement, le nom de l'établissement devant correspondre aux champs de propriétaire de domaine dans les bases de données des registres Internet. L'élaboration d'une liste de tous les établissements dont nous avions la connaissance nous a permis de développer une application chargée de :
gérer les établissements et leurs contacts administratifs
faciliter les demandes de certificat en accompagnant les demandeurs dans la génération de la requête et sa soumission sur le site du prestataire
valider les demandes à partir des connaissances de nos bases et l'interrogation des bases de données des registres Internet (whois)
Mais cela ne nous affranchissait pas d'une procédure papier préalable à la signature. Dans les faits, à partir de sa demande, un contact administratif recevait du prestataire un courriel de confirmation qu'il fallait imprimer, signer puis faxer au CRU (ou à RENATER selon le guichet dont relevait l'établissement).
À réception, nous vérifiions tous les éléments présents dans le fax, à savoir : l'identité du demandeur, son courriel, sa présence dans nos bases comme contact administratif désigné, son numéro de téléphone et sa signature à côté de la requête. Nous devions ensuite vérifier cette requête : s'assurer qu'elle était bien conforme à celle présente sur le site de GlobalSign et que le « holder » du nom de domaine correspondait bien à l'établissement.
Cette procédure pouvait paraître lourde aux demandeurs, mais elle l'était surtout pour nous qui devions valider toutes les demandes au fur et à mesure.
Ces contraintes, au final, ont dû paraître bien faibles au regard des avantages procurés par ce service, avantages consolidés par la possibilité d'obtenir des certificats multi-nommés ou encore des certificats « wildcard » Mais, surtout, les contraintes associées à la dissémination des autorités de certification associées avaient disparu. Le client, à part quelques clients spécifiques pour du 802.1X ou des Keystores java, reconnaissaient par défaut ces certificats. Il n'y avait donc plus lieu d'intervenir sur le poste client.
En quatre ans d'exploitation, le CRU a validé 3581 certificats, dont 248 certificats wildcards auxquels il convient d'ajouter les 891 certificats dont 93 wildcards délivrés par l'AE RENATER pour obtenir le total en France8. Nous pouvons donc considérer qu'il s'agit 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'avère considérable.
Nous avons cependant dû faire face à quelques difficultés comme celle liée à l'impossibilité de vérifier le véritable possesseur d'un domaine, ou, au moins, sa liaison avec le demandeur. Un cas en particulier nous a particulièrement embarrassés : celui de iufm.fr. Ce domaine était en effet géré par un centre informatique en Lorraine sans aucun lien avec ses véritables utilisateurs. Ce type de cas ne se règle qu'en imaginant une solution conforme à la politique de certification telle qu'elle a été déclarée avant le démarrage du service, puis de négocier son application avec l'Autorité de Certification.
Nous souhaitions que les certificats émis puissent aller jusqu'au terme de leur période de validité, c'est à dire ne pas être révoqués à la date de fin de contrat. Nous n'avons pu leur obtenir que quelques mois de sursis. Les complications nées de cette révocation en masse de nos certificats auraient pu être évitées par le prolongement du contrat en cours. Cependant, GlobalSign ayant quitté le groupe Cybertrust (propriétaire de l'AC racine des certificats SCS), le remplacement de tous nos certificats devenait de toute façon inévitable.
L'ensemble de ces constats, ainsi que la restructuration du marché provoquant l'apparition de nouveaux acteurs et le regroupement d'autres, ont motivé la décision de TERENA de lancer un nouvel appel d'offre, publié au cours de l'année 2008, auquel RENATER et le CRU ont bien évidemment participé.
Fort 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'offre visant à faire évoluer le service. Cet appel d'offre a débouché sur la signature d'un contrat pour trois ans entre TERENA et Comodo CA Limited. Le contrat expirera donc en juin 2012 mais l'ambition demeure d'assurer la continuité du service au delà de cette date, quel que soit le prestataire qui sera alors choisi.
Dans la continuité de SCS, le coût des certificats émis n'est pas directement répercuté aux établissements. De même, l'accord du responsable de l'établissement n'est requis que lors de 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é seront maintenus au delà de la date de fin du contrat, et leurs détenteurs conserveront 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.
Ces certificats sont du même type que ceux qui étaient déjà proposés par SCS. Les principaux usages en sont HTTPS, POPS, IMAPS, STMP/TLS mais ils peuvent aussi être utilisés pour des services hors reconnaissance par un navigateur comme LDAPS par exemple. Il s'agit exclusivement de certificats serveurs SSL/TLS, ils ne doivent cependant pas être utilisés pour sécuriser des échanges concernant des transactions financières.
Un établissement peut demander autant de certificats serveurs qu'il le souhaite en choisissant pour chacun d'entre eux une durée de validité de un, deux ou trois ans. Le certificat contient obligatoirement les informations suivantes : le nom de l'établissement, son code pays et le nom du serveur9. En option, Il peut contenir des informations complémentaires comme le nom d'un service de l'établissement, la ville, l'Etat10, mais le plus utile est sans doute la possibilité d'ajouter des noms de serveurs supplémentaires. Cette dernière option donne des certificats à nom de serveur multi-valué11, c'est-à-dire un seul certificat pour plusieurs noms de machines indépendamment du domaine d'appartenance.
Les « wildcard certificates » (du type *.domaine.fr) sont aussi disponibles. Mais, si l'avantage de ces certificats est évident notamment pour la mise en œuvre de plusieurs serveurs virtuels sur un même serveur sans oublier l'économie en matière de gestion du cycle de vie des certificats, il ne faut pas pour autant en négliger les inconvénients. En effet, ce type de certificat n'apporte qu'une preuve partielle, celle du domaine. Le détenteur de la clé privée est libre d'associer le certificat à tous les sous-domaines de son choix, liberté qui peut se révéler très dommageable en cas de compromission de celle-ci. En outre, les certificats périmés ou révoqués, impactent l'ensemble des services couverts. Une méthode, qui certes multiplie les risques mais en réduit les conséquences, peut être considérée comme permettant d'atténuer les inconvénients des certificats wildcard. Elle consiste à demander plusieurs certificats pour un même nom de domaine et d'en installer un différent sur chaque machine physique. A noter que, dans le cadre de TCS, un certificat wildcard ne peut pas contenir de « Subject Alternative names ».
Destinés à l'authentification de l'usager ou à la signature de courriel, ces certificats ne sont pas encore disponibles. La délivrance de ces certificats sera régie par une Déclaration des Pratiques de Certification (DPC)12 spécifique, toujours en cours d'élaboration par TERENA et les différents NREN souscripteurs au moment de la rédaction de cet article. Il n'est donc aujourd'hui pas possible d'en décrire le processus de distribution ni leurs domaines d'application. Il est néanmoins probable qu'ils ne pourront pas être distribués à grande échelle car les contraintes inhérentes au maintien d'un niveau de confiance acceptable ne seront pas toujours à la portée de tous les établissements, notamment la présentation d'une preuve d'identité lors d'un vis-à-vis avec un agent accrédité. Selon les contraintes qui seront posées par la DPC et la charge induite pour l'autorité d'enregistrement, il conviendra d'en déterminer le champ d'usage avant son déploiement.
Destinés à assurer une double authentification serveur/usager sur les grilles de calcul, ils sont donc de deux types : les certificats serveurs e-sciences et les certificats de personne e-sciences. La DPC des certificats serveurs et celle des certificats de personne encadrent respectivement les processus de délivrance de chacun d'entre eux avec la particularité d'une durée de validité limitée à une seule année.
Non retenue par RENATER13, cette option permet d'obtenir des certificats authentifiant des logiciels ou parties de logiciels. Ils demeurent néanmoins accessibles directement auprès de Comodo. Leur durée de validité s'étage de 1 à 5 ans selon le choix du demandeur.
Les certificats SSL EV, pour Extended Validation, sont des certificats à haut niveau de confiance. Ils ne sont distribués que par des autorités de confiance accréditées. La délivrance de ces certificats est conditionnée par une vérification approfondie de l'identité du demandeur. La vérification porte notamment sur l'existence non seulement fonctionnelle mais aussi administrative de l'organisme qui doit être propriétaire en propre du domaine concerné par la demande. En outre, la personne effectuant la demande doit être identifiable et être habilitée à faire la démarche. Les dernières versions des navigateurs les font apparaître en tant que tel directement dans leur barre de navigation sur fond vert. Dans cette même barre s'affiche le nom de l'organisme porteur du certificat ainsi que celui de l'autorité de certification. Ces certificats sont intéressants pour les sites sensibles et peuvent être utilisés dans le cadre de transactions financières. Les certificats EV de type « wilcard » ne sont pas autorisés, par contre l'obtention de certificats EV multi-nommés à l'aide du champ « Subject Alternative Names » reste possible.
Les certificats SSL EV ne font pas partie de l'offre TCS. Toutefois, il possible de les obtenir à tarif préférentiel auprès de Comodo14 dans le cadre de l'accord passé avec TERENA.
Le processus mis en œuvre pour la délivrance d'un certificat est fortement dépendant de la DPC [3] élaborée à la mise en place du service. Celle-ci est elle-même étroitement liée à la politique de certification de l'AC. Si le « workflow » de SCS était assez souple au stade de la souscription au service, il exigeait des contrôles alourdissant le processus d'obtention des certificats. Cette lourdeur était sensible non seulement pour les demandeurs lors de leurs démarches mais surtout pour l'autorité d'enregistrement qui devait vérifier et valider chaque demande de certificat. Cette succession d'intervention introduisait des délais pour l'obtention du certificat demandé.
TCS, tire profit de l'expérience acquise avec son prédécesseur. Bien plus de souplesse a été introduite dans la DPC, simplifiant ainsi les démarches et raccourcissant les délais pour obtenir un certificat. La rigueur a été placée au niveau de l'adhésion des établissements au service. Une fois celle-ci obtenue, les certificats sont délivrés en quelques minutes.
Préalable indispensable, il s'agit du document par lequel un établissement demande à souscrire au service. Dans ce document, celui-ci indique les éléments permettant de l'identifier et s'engage à respecter et à faire respecter la DPC. Une liste des Contacts Administratifs, personnes habilitées à déposer, renouveler ou révoquer des certificats est jointe en annexe. Le CRU encourage les établissements à faire figurer leur RSSI parmi cette liste et d'ajouter un ou deux suppléants choisis parmi les administrateurs système. Mais il est aussi possible, par exemple dans le cadre de services mutualisés, de désigner une personne d'un autre établissement. Ainsi un Contact Administratif peut l'être pour plusieurs établissements.
Une seconde annexe dresse la liste des domaines pour lesquels des certificats seront demandés. Seuls les domaines figurant dans cette liste pourront par la suite faire l'objet d'une demande de certificat. Peu importe le nom du domaine ou son suffixe, il est indispensable que l'établissement apparaisse comme propriétaire de ces domaines lors d'une requête « whois » vers les registres Internet. Cela peut créer des difficultés, notamment pour les unités du CNRS dont le domaine est propriété du CNRS. Dans ce cas, le domaine doit soit appartenir à l'unité, soit être un sous-domaine, géré par l'unité, d'un domaine appartenant au CNRS. Un problème similaire se pose pour les IUFM devenus aujourd'hui composantes de différentes universités mais dont le domaine iufm.fr reste propriété de l'IUFM de Bretagne. Ici, les sous-domaines de iufm.fr dédiés à chaque IUFM sont à déclarer dans la lettre d'engagement de leur université de rattachement. Si d'autres cas particuliers devaient se révéler, il revient à l'AE de rechercher une solution respectueuse de la DPC.
En pratique, le document est édité à partir d'un formulaire en ligne. Ce formulaire génère un document PDF à imprimer, à faire signer par le représentant légal de l'établissement et à adresser à l'autorité d'enregistrement par voie postale. Cette lettre engage la responsabilité de l'établissement, il est donc indispensable de la faire signer par une personne disposant légalement de la possibilité d'engager cette responsabilité. Il s'agit donc du Président, du Directeur ou d'une personne disposant formellement d'une délégation de signature.
L'Autorité d'Enregistrement est chargée d'opérer une double vérification : elle vérifie que le souscripteur est bien identifiable et fait partie des ayants droit au service. Elle vérifie ensuite si les domaines listés sont bien la propriété du souscripteur.
Dans un souci d'efficience du service rendu, trois « guichets » autorités d'enregistrement sont ouverts. Le CRU reçoit les demandes des établissements d'enseignement supérieur sous tutelle du MESR, l'UREC celles des unités du CNRS et RENATER celles de tous les autres établissements disposant d'un agrément RENATER.
Après avis positif de l'AE, l'établissement est référencé dans l'application de gestion des certificats15. C'est à partir de l'interface de celle-ci que les contacts administratifs pourront déposer leurs demandes de certificats.
Contrairement au service SCS, les contacts administratifs sont ici complètement autonomes dans leur gestion des certificats serveurs.
Ils accèdent à l'interface de l'application web dédiée après s'être authentifiés via la fédération d'identité « Enseignement-Recherche »16. L'autorisation d'accès est basée sur l'adresse mail extraite des attributs délivrés par le fournisseur d'identité (IdP).
C'est à travers cette interface que les contacts administratifs vont déposer leurs demandes de certificats ou « Certificate Signing Request » (CSR). La CSR doit répondre à une syntaxe bien précise. Le CRU propose, dans les pages dédiées à TCS de son wiki17, une aide à la rédaction de la commande OpenSSL permettant d'obtenir une CSR conforme18. Dès lors, un copier-coller du résultat de la commande vers l'interface TCS simplifie grandement la démarche. La commande OpenSSL génère des clefs RSA de 2048 bits. La puissance des serveurs actuels est suffisante pour supporter la charge induite, cependant, pour des serveurs particulièrement chargés ou pour des services multipliant les tâches de cryptographie, il peut être judicieux de la réduire.
La demande se fait en deux étapes :
Dépôt de la CSR, précision de la durée de validité et du courriel du demandeur. La conformité de la CSR est vérifiée par l'application, notamment la recevabilité du nom de domaine et la présence des champs obligatoires. En cas de succès de ce contrôle, le demandeur est invité à ajouter, s'il le souhaite, les informations optionnelles. C'est à ce niveau qu'il pourra compléter le champ « Subject Alternative Names » pour obtenir un certificat valable pour plusieurs serveurs. À noter également la présence ici du champ « Organization Unit » (OU) pour spécifier le nom d'une entité interne.
Approbation de la demande par le contact administratif déclenchant son transfert vers Comodo.
À chacune de ces étapes, le demandeur reçoit un courriel de confirmation lui permettant de suivre le bon déroulement des opérations. Dès que le certificat signé est disponible, il reçoit à nouveau un courriel lui signifiant cette disponibilité et proposant un lien direct vers la page de l'application à partir de laquelle il pourra télécharger le certificat et la chaîne de certification.
Chaque fois qu'il le juge nécessaire, le contact administratif peut, à partir de l'application mise en place, consulter la liste des certificats émis pour son établissement. Un filtrage est proposé pour un affichage de tous les certificats ou seulement ceux qui sont en attente de délivrance ou encore révoqués.
Le contrat passé avec Comodo prévoit qu'il informe par courriel les demandeurs19 lors de la proche fin de validité de leurs certificats.
Les JVM sont livrées avec un magasin de certificats, le « Keystore », contenant les certificats des principales AC. C'est grâce à ce « Keystore » que les applicatifs java peuvent initier des connexions SSL avec les serveurs [4].
Cette fonctionnalité n'est pas utilisable telle quelle pour les certificats TCS. En effet, ceux-ci ne sont pas directement signés par une AC racine mais par « TERENA SSL CA », elle-même signée par une autorité intermédiaire « UTN-USERFirst-Hardware » signée par l'AC racine « AddTrust External CA Root ».
Pour que la connexion SSL fonctionne, il est donc nécessaire de concaténer le certificat signé avec la chaîne de certification obtenue en même temps que celui-ci. Il faut cependant prendre garde à l'ordre de présentation des certificats dans cette chaîne qui est inverse à celui mis en œuvre dans la chaîne fournie par TCS.
L'opération est à reproduire à chaque renouvellement de certificat. La démarche la plus simple consiste à créer chaque fois un « Keystore » spécifique contenant le nouveau certificat et sa chaîne de certification remise en ordre et de faire pointer la JVM (ou le serveur Tomcat) vers ce Keystore.
Par défaut, Unicode est la norme en vigueur pour les certificats afin d'autoriser l'usage des caractères spécifiques dans chaque pays notamment pour le champ « Organization » (O). Or, des outils comme OpenSSL sont limités aux caractères ASCII. Il ne s'agit pas ici d'un véritable problème puisque le champ « Organization » qui apparaîtra dans le certificat n'est pas celui de la CSR mais celui que nous avons enregistré au moment du traitement de la demande de souscription au service. Ainsi, la CSR peut être produite en caractère ASCII, cela n'empêchera pas le certificat de présenter correctement le nom de l'établissement avec ses caractères accentués (ce qui n'était pas le cas avec le service SCS).
Microsoft Exchange n'utilise pas les certificats uniquement pour le web, POP3 ou IMAP, il les utilise aussi pour sécuriser ses échanges avec les serveurs offrant des fonctionnalités complémentaires comme Activsync, Autodiscover, OWA par exemple. En conséquence, le certificat utilisé doit être multi-domaine et contenir dans sa liste de « Subject Alternative Names » des noms de serveurs aussi bien externes qu'internes. Les certificats délivrés par TCS ne permettent pas d'inclure des noms de serveurs internes dans le champ SAN.
Comodo propose des certificats UCC adaptés à Exchange 2007 labellisés par Microsoft, mais ils ne font pas partie de l'offre TCS et coûtent plusieurs centaines d'euros selon le nombre de serveurs couverts.
Des stratégies de contournement existent cependant [5], dépendantes de l'infrastructure dans laquelle s'intègre Exchange. Elles consistent essentiellement à installer un ou des certificats TCS sur un ou des serveurs frontaux et à utiliser un certificat auto-signé pour les échanges internes entre serveurs voire entre serveurs et clients internes. La présence d'un certificat, même auto-signé, dans la configuration d'Active Directory est considérée comme une garantie suffisante pour accorder la confiance dans ce certificat.
La déclinaison française du service TCS est le fruit d'une bonne collaboration entre RENATER, le CRU et l'UREC. Nous sommes aujourd'hui en phase de migration, période durant laquelle les deux services cohabitent. Même si plus aucun certificat n'est délivré par le service SCS, celui-ci sera maintenu jusqu'à la révocation des derniers certificats encore en cours. Nous encourageons néanmoins les établissements à ne pas attendre la « dead line » avant de renouveler l'ensemble de leurs certificats, même s'ils sont encore valides [6]. On peut légitimement craindre un engorgement de TCS au regard du volume de certificats à remplacer si la période de recouvrement n'est pas pleinement mise à profit.
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 au service et apporter les modifications demandées à la liste des contacts administratifs ou à la liste des domaines.
Par son succès, SCS à montré qu'il était une réponse pertinente à la problématique du déploiement de certificats serveurs. 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.
Une question pour terminer, à propos de l'émergence d'un nouveau type de certificat : l'« EV certificate ». Bien qu'étant encore d'un coût excessif, sensibiliseront-ils à l'étagement nécessaire de la confiance ?
[1] Serge Aumont, Claude Gross et Philippe Leca, « Infrastructures de Gestion de Clés et Certificats X500 » Tutoriel du congrès JRES2001, http://www.cru.fr/_media/activites/igc/jres01.tutoriel.igc.pdf.
[2] Serge Aumont, « faut-il brûler vos certificats ? ». Dans Actes du congrès JRES2003; http://2003.jres.org/actes/paper.21.pdf.
[3] DPC des certificats serveurs TCS : https://www.terena.org/activities/tcs/repository/TCS_CPS-1.2.pdf
[4] la page Esup-portail intitulée « utilisation
de certificats X509 en Java »
http://www.esup-portail.org/consortium/espace/SSO_1B/tech/java/java_x509.html
[5] La page dédiée de « The Micosoft Exchange Team Blog », http://msexchangeteam.com/archive/2007/07/02/445698.aspx
[6] https://tcs.cru.fr/tcs/ - https://tcs.renater.fr/tcs/ - https://tcs.urec.cnrs.fr/tcs/
1 TERENA : association européenne des réseaux nationaux de l'enseignement et la recherche.
2 NREN : National Research and Education Networks. À ce jour 20 NREN participent à ce projet.
3 ou CA pour Certification Authority.
4 nombre de navigateurs parmi lesquels on trouve Firefox, Opera, IE, Chrome, Safari, Camino, Konqueror, la plupart des smartphones, PDA ou pocketPC ainsi que toute une variété de clients.
5ou PKI pour Public Key Infrastructure.
6 L'AC signe les certificats mais c'est l'AE (ou RA pour Registration authority) qui détermine si la demande est recevable ou pas.
7 GlobalSign : autorité de certification belge, filiale du groupe américain Cybertrust. Tous les navigateurs courants contiennent par défaut l'autorité racine de Cybertrust.
8 Le cumul des NREN donne pour TERENA près de 20000 certificats délivrés.
9 Champs Organization (O), Country (C) et Common Name (CN)
10 Champs Organization Unit (OU), Locality (L) et State (ST)
11 SAN certificates pour certificats avec Subject Alternative Names. 100 domaines maximum par certificat.
12 ou CPS pour Certification Practice Statements.
13 La demande semble faible dans ce domaine. Il nous a semblé préférable que chaque établissement ayant besoin de ce type de certificats, les achète lui-même en choisissant la meilleure offre du marché.
14 Le tarif est de 150€ par certificat par année de validité à comparer aux tarifs publics allant de 450€ à plus de 1000€ selon les fournisseurs. Le prix s'entend par domaine si le certificat est multi-domaine.
15 Selon le cas : https://tcs.cru.fr/tcs/ - https://tcs.renater.fr/tcs/ - https://tcs.urec.cnrs.fr/tcs/ tous trois hébergés sur les serveurs de l'UREC comme d'ailleurs les formulaires permettant d'éditer la lettre d'engagement.
16 Pour les établissement non adhérents à la Fédération, il est possible d'utiliser un « compte CRU ».
17 http://www.cru.fr/tcs/
18 http://www.cru.fr/services/tcs/csr
19 À l'adresse indiquée lors du dépot de la CSR.
Page