Portail des services RENATER

Au 1er mai 2020, les certificats TCS sont délivrés par Sectigo.

L'une des principales motivations de TCS est l'élimination du problème 'pop-up', lorsque les utilisateurs qui visitent un site Web reçoivent un avertissement signalant que le site n'est pas fiable. C'est parce que même si le protocole HTTPS peut être utilisé pour créer un canal sécurisé, il n'est pas possible de vérifier que le certificat d'un site distant est vérifié et approuvé à moins que le certificat racine de la CA d'origine soit pré-installé dans le système d'exploitation du client ou un logiciel de navigation. Il est possible d'ajouter manuellement des certificats, mais cela oblige l'utilisateur à comprendre le processus et à entreprendre leur propre vérification, et il y a le risque que les utilisateurs inexpérimentés puissent choisir, par inadvertance, de faire confiance à des sites falsifiés ou frauduleux.

Les certificats racines utilisés pour signer les certificats TCS sont pris en charge par les navigateurs modernes et la majorité des applications. Pour plus d'information, veuillez consulter les chaines de certification TCS4 et la documentation de Sectigo

En pratique nous faisons déjà confiance à ces certificats, puisqu'ils sont installés par défaut dans les navigateurs des utilisateurs et sont utilisés pour des sites grand public. Très rares sont les établissements qui ont une politique pour les supprimer des navigateurs de leurs utilisateurs, car il est extrêmement difficile voir impossible de le faire correctement.

Il existe trois risques associés à l'utilisation de certificats serveur émis par une IGC :

1. une attaque délibérée de la part de l'opérateur de l'IGC, par exemple l'émission indue d'un faux certificat pour le serveur d'un établissement, pour pouvoir décrypter les flux chiffrés avec le véritable certificat du serveur de cet établissement ;
2. une mauvaise protection de la clé privée des certificats d'autorités, qui permettrait à un attaquant de les copier pour ensuite forger des faux certificats qui seraient indiscernables d'authentiques certificats ;
3. une négligence d'un opérateur enregistrement qui aboutirait à la délivrance d'un certificat contenant des informations intentionnellement erronées ou non.

Le premier risque est extrêmement improbable, du fait du risque en terme d'image par rapport aux gains potentiels. Le deuxième est moindre dans le cas du prestataire retenu qu'il ne l'était pour l'IGC du CRU par exemple, car les mesures de protection des clés sont bien plus conséquentes.

Le troisième risque est extrêmement limité du fait que les informations concernant l'établissement (nom, domaines, demandeurs désignés) sont vérifiées une seule fois au moment de la validation de l'organisation (Ancre OV) et du contrôle du domaine (DCV) et que ces critères sont ensuite automatiquement vérifiés voire bloqués par l'application qui permet de faire les demandes.