Table des matières
Les certificats électroniques pour les authentifications EAP
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.
Les certificats
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)
AC commerciale ou privée ?
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.
Le service TCS version HARICA, les certificats utilisés dans sa chaîne de confiance expirant au plus tôt en 2045, c'est la solution que nous vous recommandons.
RSA ou ECC ?
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.
Nous vous conseillons d'utiliser des certificats ECC.
TCS - HARICA : Les ACs de confiance
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-HARICA 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 : CN=HARICA OV TLS RSA, O=Hellenic Academic and Research Institutions CA, C=GR
- Intermédiaire 2 : CN=HARICA TLS RSA Root CA 2021, O=Hellenic Academic and Research Institutions CA, C=GR
- Racine : C = GR, L = Athens, O = Hellenic Academic and Research Institutions Cert. Authority, CN = Hellenic Academic and Research Institutions RootCA 2015
- La chaîne courte :
- Intermédiaire : C = GR, O = Hellenic Academic and Research Institutions CA, CN = HARICA OV TLS RSA
- Racine : C = GR, O = Hellenic Academic and Research Institutions CA, CN = HARICA TLS RSA Root CA 2021
Les certificats HARICA TLS 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.
Si vous avez des modifications importantes à apporter dans CAT qui vont impliquer un redéploiement sur l'ensemble des postes de vos utilisateurs, nous vous conseillons d'utiliser la chaîne courte.
Les chaînes de certifications TCS-HARICA sont disponibles :
Changement d'une autorité de certification
Dans le cadre d’un changement d’Autorité de Certification (AC) emettrice des certificats Serveur. Tous les appareils des utilisateurs EDUROAM, dont le serveur d'authentification RADIUS utilise actuellement un certificat émis par l'ancienne AC, doivent être mis à jour.
Vous trouverez de la documentation détaillé pour ce point → Lien ici.
CAT et votre service d'authentification RADIUS
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.
