Last updated: 
2 months 2 weeks ago
Blog Manager
eduroam Service News Follow us on Twitter @eduroamuk - for news, interest, information, photos and fun. Contents - click on item and scroll to bottom of box to read item 15/04/19 - Advisory: EAP-PWD Vulnerability 12/10/18 - Advisory: Injection of Operator-Name attribute by the NRPSs 23/02/18 - eduroam Seminar pre-Networkshop 2018 - FreeRADIUS 4 etc 24/10/17 - Advisory: WPA2 Key Reinstallation Attacks vulnerability, KRACK 14/07/16 - Release of Technical Specification v1.4 10/05/16 - Advisory: Ending of RADIUS Accounting within eduroam(UK) 22/01/15 - eduroam Support Clinic Tues March 1st 14:15-15:30 18/09/15 - Advisory: Impact of change of Certificate Service CA for eduroam Home (IdP) service providers 27/01/15 - eduroam now available at seven hospitals in Cardiff 22/01/15 - eduroam Support Clinic Tues January 27th 10:45-12:00am 23/12/14 - Calling Station Identity 01/12/14 - New DNS Name for eduroam(UK) Support Server 19/12/14 - eduroam Support Clinic Tues January 6th 10:45am 28/11/14 - eduroam Support Clinic Tues December 2nd 10:45am 19/11/14 - Advisory: Microsoft Security Bulletin Affecting NPS and IAS 27/05/14 - eduroam training course June 11-12 Birmingham; Aug 6-7 Aug Bristol 08/04/14 - Advisory: OpenSSL TLS Heartbleed Vulnerability rev 1.1 21/02/14 - Auth Timestamp Feature on eduroam(UK) Support Server 30/10/13 - Release of FreeRADIUS 2.2.2 07/10/13 - Release of FreeRADIUS 3.0.0 17/09/13 - Release of FreeRADIUS 2.2.1 13/06/13 - Release of Technical Specification v1.3 13/06/13 - eduroam training course June 27 Glasgow 23/04/13 - eduroam training courses July 24-25 London 23/04/13 - Chargeable User Identity how-to guide now available in Library 25/03/13 - eduroam training courses May 2-3 Manchester 24/02/13 - Time for a review of your eduroam deployment - Technical Specification v 1.2 Main Changes from v 1.1 30/01/13 - Configuration Assistant Tool (CAT) now available - builds eduroam client installers for user devices 23/01/13 - Advice regarding keeping eduroam credentials secure 09/01/13 - eduroam(UK) Announcement of Change of Name of the Janet Roaming Service to eduroam(UK) 19/11/12 - Uptake of NAPTR record definition in DNS (to enable RadSec DD) is increasing 31/10/12 - eduroam(UK) Support Server Update: Nagios LG and check for NAPTR records 30/10/12 - Cisco ACS 5.4 released: now support Operator-Name 29/10/12 - Unscheduled service outage Friday 26/10/2012 1:02 AM - 9:48 AM 03/10/12 - Advisory: Improving Efficiency of International Authentication through utilisation of RadSec at National Level 11/09/12 - Advisory: FreeRADIUS 2.1.10,11,12 Security

Group administrators:

Advisory: Impact of change of Certificate Service CA for eduroam Home (IdP) service providers

January 2016 - 20/01/2016

This advisory is relevant to all eduroam(UK) Home (IdP) service organisations that are using server certificates supplied through the Jisc Certificate Service (Janet Certificate Service) for RADIUS servers acting as authenticators. It describes the effect of the change to the new certificate authority which occurred in May 2015, together with the measures that need to be planned for and put into effect.

Originator: Edward Wincott

Background and Scope

The certificate authority (CA) which issues server certificates provided through the Jisc Certificate Service (Janet Certificate Service/JCS) changed from Comodo to QuoVadis on 12/05/15. This resulted from the move away from the TERENA service, which co-incidentally also changed its CA in early 2015, to a directly procured Jisc service. The switch to QuoVadis enables Jisc to provide an even better value service as well as allowing operational improvements. However, the change of CA has implications for all eduroam organisations using EAP methods that utilise CA certificates (effectively all) and whose authenticating RADIUS servers’ certificates have been supplied through the Jisc Certificate Service. This advisory relates to the changes to client supplicant configuration necessitated by the change of CA. Organisations which use their own self-signed certificates on authenticating RADIUS servers are not affected.

Unless the certificate expiry date of your certificate is imminent, no immediate is necessary for existing Comodo based certificate installations. Certificates are typically issued for 2 or 3 years and current deployments can remain as they are until expiry dates approach. When Comodo certificates do expire they will have to be replaced. Replacement certificates issued through the Janet Certificate Service will be from QuoVadis. 

Potential Problem

Properly setup client devices should validate the CA of the certificate installed on authenticating RADIUS servers (and should also check the common name (CN) defined on the certificate) during the TLS handshake phase. Unless the configuration of the supplicant on users’ devices is modified and in some cases the certificates stores too, replacing the expired certificate of the RADIUS server with one signed by a different CA will cause properly set up client devices to fail to authenticate.

Actions to be taken

Before an organisation using Comodo server certificates issued by the Jisc Certificate Service for its authenticating RADIUS servers renews these with QuoVadis certificates, it must take certain measures to ensure the continuance of successful authentication of its users’ devices with the minimum of disruption.

Essentially, the configurations of all client devices will have to be updated. The method chosen and the timing of this depend on the mechanism by which users’ devices are configured at your organisation.

The following need to be achieved:

  • QuoVadis root and intermediate certificates must be in the client certificate store (specifically QuoVadis Root CA 2, QuoVadis EV SSL ICA G1 and/or  QuoVadis Global SSL ICA G2 depending on the type of certificate you have purchased, see )
  • The QuoVadis CA 2 root must be trusted by the supplicant
  • The CN defined on the authenticating RADIUS servers’ certificate must be configured in the supplicant (this should not change unless you are changing your chosen CN on the certificate)
  • The new QuoVadis server certificate needs to be installed on the authenticating RADIUS server(s) together with its associated private key file and the relevant EAP module needs to be configured to use it.


Regarding CA certificates in client device cert stores - most manually configured machines will already have these and so reconfiguration should be a straightforward matter of simply changing the CA in the Trusted Root Certification Authority selection panel of the Wi-Fi supplicant (see screen shot in Appendix). If you support manual configuration of clients and have produced manual configuration instructions, these will need to be updated and your user base advised of the changed instructions.

CAT configured machines - all parts of the certificate required to validate the certificate by the client must be uploaded to CAT; ie root, intermediates and server certificate for assured compatibility.  Root and intermediates is the minimum. Best practice recommendation is that intermediates only is not sufficient since less well known CAs may not be distributed with the OS or otherwise have been saved in the client cert store. (This certainly applies if you are using self-signed/private certificates!) Similar considerations will apply to other automated client setup tools. You will need to make the requisite changes to CAT and advise your user base to re-run the eduroam installer.

If you are running multiple authenticating RADIUS servers, for simplicity we recommend that you use the same certificate for all servers. This will of course also require the private key file to be copied to all servers sharing the certificate. Whilst you can use separate certificates for each server, using just one simplifies client configuration since it means that only one CN need be defined in the ‘connect to these servers’ box.

Whilst this advisory applies to organisations using the Jisc Certificate Service, which provides highly cost effective server certificates from a CA whose certs are widely distributed in clients, it remains best practice for organisations to use self-signed certificates. The benefits of setting up as your own CA are security, performance, control and I you utilise EAP-TLS, client certificates can readily be produced. The downsides are: operating your own CA and distributing certificates (but that’s only a small issue these days with on-boarding tools such as CAT).

Recommended reading: EAP Server Certificate guidance on the wiki can be found at:


Windows 7 PEAP Properties Screenshot

Manually configured clients should already have the public QuoVadis CA certificates in their certificate stores, so reconfiguration should be a straightforward matter of simply changing the CA in the Trusted Root Certification Authorities selection panel in the PEAP Settings config box.

For PEAP (for on certificate):