skip to content

IT Help and Support

University Information Services
 

The information given here may help configure eduroam on wireless devices, operating systems and client software not listed in the main eduroam documentation.  It also gives some technical information about how it's provided at the University of Cambridge.

Note that the user and server authentication details are also used for SSIDs provided on the University Wireless Service using WPA2 Enterprise with Lookup security.

Contents

Wireless settings

This is the details of the wireless network itself:

Network Name (SSID) eduroam
Security Type WPA2 Enterprise
Data Encryption AES

User authentication settings

These specify the method and details required to prove your identity to the network:

EAP Authentication Type or Outer Authentication Protocol PEAP or PEAPv0
Authentication Method/Protocol or Inner Authentication Protocol MS-CHAPv2
Username

"CRSid+device@cam.ac.uk" [for new tokens]
e.g. "abc123+laptop@cam.ac.uk", or

"CRSid@cam.ac.uk" [for legacy tokens]
e.g. "abc123@cam.ac.uk", or

"inst-num@cam.ac.uk" [for institutional tokens]
e.g. "botolphs-100@cam.ac.uk"

Password The password for the same Network Access Token — note that this is NOT your Raven password.
Outer/Roaming/Anonymous Identity See server authentication settings below

Alternative EAP methods

The recommended authentication protocols to use (EAP-PEAP with MS-CHAPv2) are given above, there are many other available combinations:

  • EAP-TTLS with CHAP, MS-CHAP and MS-CHAPv2 will work but are unsupported.
  • EAP-TTLS with PAP will work but is unsupported and strongly advised against: if used, the server must be authenticated by certificate and name) else it can reveal your Network Access Token to third party sites.
  • EAP-LEAP is not supported and will not work.
  • EAP-FAST is not supported and will not work.

Combinations other than those listed above must not be used and are unlikely to work.

Server authentication settings

These are used so your device can confirm that it is securely talking to the University of Cambridge systems, before your username and password are handed over.  These settings can often be omitted but you may be giving your credentials to a third party system.

There are two ways this can be accomplished, each using server certificates signed by a different Root Certification Authority (CA): one a local (University) CA and the other using a well-known public CA.  Which method you use is a matter of preference but will be influenced by the operating system your device is running.  The following table summarises the differences:

Signing root Certificate Authority (CA) Local (University of Cambridge Wireless Service) CA Public (well known) CA
Certificate installation Requires installation of special root CA certificate. No need to install a special root CA.
Security risk

On some operating systems (e.g. Windows), installing a new root CA trusts it for all activities (including general web browsing): you could be open to security threats, if the root CA certificate is compromised from the UIS.

Other platforms can restrict the use of the use of a local root CA to just a particular function (e.g. Android and iOS will limit a certificate to being used for WiFi connections only, by default)

You are trusting the public root CA.  You are open to the same type of threats but a CA's business is based around securing their certificates, so the security tends to be greater.
Interval between reconfigurations The root CA certificate has a long lifespan and devices should not require reconfiguring during their lifetime (>10 years). The device may need reconfiguring every year, as the certificate is updated.
Validation support Some platforms can only validate against a non-public CA (e.g. Android). Most platforms can validate against both local and public CAs.
Recommended for

Android
iOS
Linux
macOS

Windows
Windows Phone

The separate instructions provided for each platform by the UIS use the recommended certificate for that particular platform.  However, at the present time, Windows (desktop) will use the local CA — this will likely be changed at some point.

Certificate selection by outer identity

The University of Cambridge service allows you to select which certificate is desired by using the outer identity (also known as the roaming or anonymous identity):

Outer identity Signing root Certificate Authority (CA) selected
_token@cam.ac.uk [note the leading underscore] Local (University of Cambridge Wireless Service) CA

_public@cam.ac.uk [note the leading underscore]
_publicYYYYMM@cam.ac.uk [note the leading underscore]
@cam.ac.uk
username@cam.ac.uk

Public (well known) CA

The outer ID cannot be any other value; if the username portion is specified before the "@" symbol, it MUST match that used in the inner ID field (i.e. the username).

If your system does not have the ability to specify the outer identity, it will usually use the username itself, forcing you to use the public CA-signed certificate.  Also note that some operating systems (e.g. Windows) only require you to enter the portion before the "@" symbol in the outer identity field and will automatically append the "@cam.ac.uk" from the username field. 

Local (University of Cambridge) CA

To use this certificate, you must download and install the University of Cambridge Wireless Service Root CA on your device.  The actual certificate which will be provided will be signed by this root CA.

When installing the root certificate, you are strongly advised to verify the fingerprint of if against one of the values shown below.  Note that they are the fingerprints of the certificate and NOT those of the downloaded file.

Algorithm Fingerprint
SHA-1 02:61:03:C0:D8:36:C9:EF:01:87:F2:94:34:75:9E:C3:06:2E:28:DA
SHA-256 8D:E6:D1:30:F1:32:B3:D7:05:84:56:58:22:7F:53:78:56:0B:70:E8:CB:0B:F0:E8:62:94:4C:14:BB:AE:E5:CF

If your operating system supports it, we strongly advise you to restrict the use of this certificate to connecting to wireless networks (and eduroam in particular, if possible), rather than be used as a general root CA.  This root CA is not intended to be used for any purpose other than authenticating wireless SSIDs on the University Wireless Service, or other services federated to it (e.g. other eduroam sites).

To use this certificate, you should configure the following authentication settings:

Outer/roaming/anonymous identity _token@cam.ac.uk
Issuer / trusted certification authority University of Cambridge Wireless Service Root CA
Server name / CN (Common Name) token.wireless.cam.ac.uk

The actual certificate used by the wireless service will change over time, but it will continue to be signed by the above certificate authority and use the same server name. 

Public (well known) CA

There are two ways to configure the use of a public certificate: which you use is selected by the outer identity and depends on whether you wish to manage the rollover to a new certificate automatically or manually:

  Automatic Manual
Outer identity _public@cam.ac.uk [recommended]
@cam.ac.uk
username@cam.ac.uk
_public202012@cam.ac.uk
[includes the year and month of issue]
Issuer / trusted certification authority chain QuoVadis Root CA 2 G3 [root]

QuoVadis Global SSL ICA G3

Server name / CN (Common Name) token-public.wireless.cam.ac.uk
Serial number 0A:75:C4:69:FE:6C:5D:F5:38:F5:47:B3:C0:25:D1:40:D8:D3:90:8F
SHA-1 fingerprint 2C:82:46:DA:71:B5:9F:12:D6:4D:3A:D8:6C:C1:3D:C8:8D:E9:09:DF
SHA-256 fingerprint

EC:D9:55:15:2B:E5:74:AF:A4:50:12:
F6:94:E1:A8:EF:DA:08:71:6E:BF:A3:
68:90:FD:A9:28:93:16:17:C4:7E

Expiry of current certificate Prior to 16-Dec-2021 @ 16:02 GMT
[rollover will be ahead of this]

16-Dec-2021 @ 16:02 GMT

Certificate rollover behaviour The new certificate and configuration comes into effect at an advertised time. The certificate and configuration does not change but must be manually updated in advance of the expiry of the old certificate.
Advance reconfiguration required

None, unless the CA or other aspects of the certificate change.  If this is required, this will be advertised in advance.

Required — the outer identity must be updated and any updated certificate settings made.
Rollover experience Likely seamless, although devices relying on certificate pinning will likely be prompted to authorise the new certificate. Seamless.

Note: separate serial number / fingerprint details for each method will only be shown during an overlap period, as a rollover is being prepared.

Most users will want to use the automatic method (if not the local CA method).  The manual method is more complicated to administer but some users may prefer it, if they wish to perform any reconfiguration activities at a known point in time.

In both cases, users using the public CA method are strongly advised to check the serial numbers and fingerprints and reject the connection, if alternative information is displayed, otherwise you may be handing over your credentials to a third party.  If this happens, please report it to the Service Desk, especially if you are on University or College premises.

When a new certificate is introduced the changeover process will be as follows:

  1. The new certificate will be introduced, selected with a new outer identity, "_publicYYYYMM@cam.ac.uk", in parallel with the old one.
  2. The UIS advertise this, along with the time and date of the rollover, as well as the time and date of for the expiry of the old certificate.  Manual method users will need to reconfigure their devices before the old certificate expires.
  3. At the advertised rollover time, the identities selecting the automatic method will be switched over to the new certificate.  Users making use of these identities and using certificate pinning will receive a warning that the new certificate will need to be authorised, at this point.
  4. The old certificate, selected by the old outer identity, will continue to work until it expires.  At this point, users who have not reconfigured their devices will most likely fail to connect after this point.  Any devices which are ignoring the expiry date may continue to work for short while after this, until the old certificate is completely removed.

Last modified: 7th January 2021

UIS Service Desk

UIS Service Status

Phone padded  Service status line: (01223 7)67999
Website  Sign up for SMS/email status alerts
Website  Read major IT incident reports

UIS bITe-size bulletin

A regular newsletter aimed at the University's IT community, highlighting service and project news from UIS.

Sign up >

Latest news

Moodle maintenance Tuesday 3 August 07:00-09:00

28 July 2021

The Moodle service will be subject to interruption on Tuesday 3 August 07:00–09:00 due to essential maintenance. While Moodle is unavailable, users will not be able to log in to the Panopto cloud service. Panopto recordings can still be made offline for later upload. If you have any questions, please contact the Moodle...

Internet Explorer 11 will no longer be supported by Microsoft 365 apps and services from 17 August 2021

23 July 2021

Microsoft has announced that from 17 August 2021, all Microsoft 365 apps and services will no longer support Internet Explorer 11 (IE11). This follows Microsoft’s announcement last November that Microsoft Teams would no longer support IE11. After 17 August 2021, you'll have a degraded experience or will be unable to...

Moodle maintenance Thursday 29 July 07:00-09:00

23 July 2021

We’re updating Moodle on Thursday 29 July between 07:00 and 09:00. The service will be unavailable during this period. Users will also not be able to log in to the Panopto cloud service while Moodle is unavailable, Panopto recordings can be still be made offline for later upload. Following this update, the Checklist (both...