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. It is intended for technical users such as Computer Science students.
The user and server authentication details are also used for SSIDs provided on the University Wireless Service using WPA2 Enterprise with Lookup security.
What this information covers
Wireless settings
These are 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
For new tokens: "CRSid+device@cam.ac.uk", for example, "abc123+laptop@cam.ac.uk".
For legacy tokens: "CRSid@cam.ac.uk", for example, "abc123@cam.ac.uk".
For institutional tokens: "inst-num@cam.ac.uk", for example, "botolphs-100@cam.ac.uk".
Password
The password for the same Network Access Token. Please note that this is not your University password.
Outer, Roaming or 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 MS-CHAPv2 will work but is 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-TTLS with CHAP and MS-CHAP will not work.
- EAP-LEAP will not work.
- EAP-FAST will not work.
- EAP-TLS is not supported and will not work, although we plan to offer this in future.
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 2 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 (for example, 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 (for example, 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 (for example, Android). | Most platforms can validate against both local and public CAs. |
| Recommended for |
|
|
The separate instructions provided for each platform by UIS use the recommended certificate for that particular platform. However, at present, 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):
-
Local (University of Cambridge Wireless Service) CA
Outer identities:
_token@cam.ac.uk(note the leading underscore) - Public (well known) CA
Outer identities:
_public202311@cam.ac.uk(note the leading underscore)
_publicYYYYMM@cam.ac.uk(note the leading underscore)
@cam.ac.uk
username@cam.ac.uk
The outer identity cannot be any other value. If the username portion is specified before the "@" symbol, it must match that used in the inner ID field (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. Some operating systems, for example 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 its fingerprint against one of the values shown below. Note that they are the fingerprints of the certificate and not those of the downloaded file.
- 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. For example, 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 2 ways to configure the use of a public certificate. Which method 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
- Outer identity:
_public@cam.ac.uk[recommended]@cam.ac.ukusername@cam.ac.uk
- Issuer / trusted certification authority chain
- AAA Certificate Services [root]
- USERTrust RSA Certification Authority
- GEANT OV RSA CA 4
- Server name / CN (Common Name)
token-public.wireless.cam.ac.uk
- Serial number
- 0B:71:CC:54:63:12:B7:61:4B:99:C4:E5:01:7D:DF:0B
- SHA-1 fingerprint
- AB:29:20:2B:C9:BA:5E:21:04:8C:93:F0:60:6D:FB:98:F9:DC:AA:46
- SHA-256 fingerprint
- FC:88:21:08:64:C0:9C:17:28:00:80:8D:04:85:CF:7F:D5:45:5F:82:EE:30:62:27:0B:4B:F9:2A:62:CC:37:92
- Expiry of current certificate
- Prior to 27 November 2024 at 23:59:59 GMT [rollover will be ahead of this]
- Certificate rollover behaviour:
- The new certificate and configuration come into effect at an advertised time.
- Advance reconfiguration required
- None, unless the CA or other aspects of the certificate change. If this is required, this will be advertised in advance.
- Rollover experience
- Likely seamless, although devices relying on certificate pinning will likely be prompted to authorise the new certificate.
Manual
- Outer identity:
_public202311@cam.ac.uk[includes the year and month of issue]
- Issuer / trusted certification authority chain
- AAA Certificate Services [root]
- USERTrust RSA Certification Authority
- GEANT OV RSA CA 4
- Server name / CN (Common Name)
token-public.wireless.cam.ac.uk
- Serial number
- 0B:71:CC:54:63:12:B7:61:4B:99:C4:E5:01:7D:DF:0B
- SHA-1 fingerprint
- AB:29:20:2B:C9:BA:5E:21:04:8C:93:F0:60:6D:FB:98:F9:DC:AA:46
- SHA-256 fingerprint
- FC:88:21:08:64:C0:9C:17:28:00:80:8D:04:85:CF:7F:D5:45:5F:82:EE:30:62:27:0B:4B:F9:2A:62:CC:37:92
- Expiry of current certificate
- 27 November 2024 at 23:59:59 GMT
- Certificate rollover behaviour:
- The certificate and configuration do not change but must be manually updated in advance of the expiry of the old certificate.
- Advance reconfiguration required
- Required: the outer identity must be updated and any updated certificate settings made.
- Rollover experience
- Seamless.
Note: separate serial numbers and 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:
- The new certificate will be introduced, selected with a new outer identity, "
_publicYYYYMM@cam.ac.uk", in parallel with the old one. - UIS advertises 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.
- 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.
- 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 December 2023