Service mobilité pour la communauté RENATER

Les méthodes EAP utilisent toutes des certificats électroniques (TLS). Ces certificats sont utilisés par le service RADIUS et par les supplicants 802.1X (sauf EAP-PWD) des terminaux utilisateurs.

La configuration des certificats coté supplicant permet de garantir à l'utilisateur qu'il s'adresse au bon serveur d'authentification, elle est primordiale pour éviter le vol d'identifiants.
Pour les méthodes EAP de type login/password il faut indiquer :

• Pour tous les supplicants : le certificat complet (i.e. certificat racine et éventuels certificats intermédiaires) de l'AC (Autorité de Certification) de confiance ayant signée le certificat de votre service RADIUS.
• Pour certains supplicants : le CN (Common Name) correspondant au paramètre CN et/ou SAN (Subject Alternative Name) du certificat de votre service RADIUS.

L'implémentation des supplicants étant dépendante du système d'exploitation, ils n'utilisent pas toujours les magasins “système” de certificats : même si vous utilisez une AC de confiance commerciale qui est nativement reconnue par tous les navigateurs web, il faudra quand même l'indiquer explicitement aux supplicants.

Dans eduroam nous avons de nombreuses combinaisons possibles entre les types de serveurs RADIUS et les supplicants utilisés, cette page regroupe les conseils qui prennent en compte ces contraintes et qui doivent fonctionner pour tous les établissements.
Cela signifie que dans le cas particulier de votre établissement, une autre configuration que celle présentée ici peut aussi fonctionner.

Que les certificats soient commerciaux (signés à partir d'une autorité racine connue par les clients; TCS par exemple) ou privés (signés par une AC privée), un certificat eduroam doit au minimum avoir :

• Un CN long (i.e. de type FQDN, pas de nom court), sans wildcard (*), sans espace.
• Au moins un SAN (Subject Alternative Name) identique au CN.
• Une AC racine (même privée).
• Une clé publique d'une longueur d'au moins 2048 bits pour RSA et 256 bits pour ECC (voir + bas)

Le principal intérêt des certificats privés se trouve dans leur AC : vous pouvez utiliser une AC unique ayant une date d’expiration très éloignée minimisant ainsi son renouvellement coté supplicant.
Mais cette solution a aussi des inconvénients comme l’expertise nécessaire à la génération de certificats robustes et fonctionnels (méthode de chiffrement, longueur, algorithme de signature, extensions obligatoires, CRL, …) et la mise en oeuvre de procédures de protection de la clé privée utilisée par l'autorité de certification. De plus, cette AC peut éventuellement avoir des effets de bord lors de l’importation sur le terminal client (l’AC privée ajoutée au magasin de certificats pourra être utilisée par d’autres services).
Vous trouverez plus d’informations sur ce sujet ici.

Les certificats peuvent être chiffrés par un algorithme cryptographique de type RSA (Rivest–Shamir–Adleman) ou ECC (Elliptic Curve Cryptography).

Les certificats ECC ont l'avantage d'être plus courts que les certificats RSA, ils permettent d'éviter des fragmentations UDP qui peuvent être problématiques avec certains serveurs RADIUS et/ou firewall.

Le service TCS supporte les certificats RSA et ECC. C'est dans la demande de signature du certificat (CSR) que vous précisez le type d'algorithme cryptographique à utiliser.

Les certificats TCS-Sectigo ont la particularité d'avoir 2 chaînes (ou chemins) de confiance :

• La chaîne longue. C'est celle qui est indiquée dans le mail TCS reçu avec le certificat du serveur :
  • Intermédiaire 1 : C = NL, O = GEANT Vereniging, CN = GEANT OV ECC CA 4
  • Intermédiaire 2 : C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority
  • Racine : C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
• La chaîne courte :
  • Intermédiaire : C = NL, O = GEANT Vereniging, CN = GEANT OV ECC CA 4
  • Racine : C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority

Les certificats USERTrust présents dans ces chaînes ont exactement le même nom (Subject) mais ils sont différents :

• Dans la chaîne longue c'est un certificat intermédiaire.
• Dans la chaîne courte c'est un certificat racine.

Les informations déclarées dans CAT et celles configurées sur votre service d'authentification RADIUS doivent être cohérentes entre elles.

Dans CAT vous devez renseigner :

• Le CN de votre serveur
• La chaîne de certification complète : certificat(s) intermédiaire(s) si vous en avez et certificat racine.

Coté RADIUS vous devez avoir :

• Le certificat du serveur
• En théorie uniquement le certificat de l'AC ayant signée le certificat de votre serveur. En pratique, si vous avez une chaîne de certification ayant plusieurs certificats intermédiaires il faut tous les indiquer, il y a des bugs identifiés sur ce point avec certains supplicants.

Exemples de chaînes de certification à renseigner, ces exemples sont donnés avec des certificats ECC, c'est le même principe avec des certificats RSA.

1. TCS-Sectigo avec chaîne de confiance courte :
   • CAT :
   • RADIUS : le certificat du serveur et le certificat intermédiaire l'ayant signé : C = NL, O = GEANT Vereniging, CN = GEANT OV ECC CA 4
2. TCS-Sectigo avec chaîne de confiance longue :
   • CAT :
   • RADIUS : le certificat du serveur et les 2 certificats intermédiaires :
     • C = NL, O = GEANT Vereniging, CN = GEANT OV ECC CA 4
     • C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority
3. AC privée (sans certificat intermédiaire) :
   • CAT : <AC racine>
   • RADIUS : le certificat du serveur et <AC racine>

Les chaînes de certifications TCS-Sectigo sont disponibles :