Certificates in eduroam

Download as PDFDownload as PDF

Updated 15/11/2023

Contents:

  • Scope
  • Establishing trust during EAP authentication
  • What certificates to install on the RADIUS server and present during authentication
  • What certificates should be in the user’s device trust store/EAP profile and be used during authentication
  • What certificates to upload into the CAT system
  • How and where to acquire server certificates
  • Generating the CSR
  • Using the Jisc Certificate Service
  • Uploading certificates into the CAT system when creating your EAP profile
  • Renewing your certificate
  • Testing your ORPS certificate installation
  • Complete the remainder of your eduroam deployment and you will be 'good to go'

Scope

This article is relevant to two-stage authentication EAP methods based on username and password (PEAP/MSCHAPv2, EAP-TTLS/MSCHAP etc). EAP/PWD does not require a serer certificate. EAP-TLS (user certificate based authentication) requires a server certificate, but consideration of user certificate management is out of scope. 

Platform/OS-specific instructions on generating the certificate signing request CSR is outside the scope of this article due to the wide range of options (openssl, Microsoft mmc certificates snap-in etc).

Establishing trust during EAP authentication

An essential step during most EAP authentications is establishing trust between the authenticating RADIUS server and the user’s device supplicant. In the early part of the phase one stage of user authentication (e.g. PEAP phase), the RADIUS server presents its server certificate to the user’s device. That server certificate may be just the simple server certificate or it may be presented together with the issuing authority’s certificate (or even with a longer chain of certification authority certificates). The aim of including the issuing authority certificate with the server certificate is to help the user’s device suppliant to establish the trustworthiness of the certificate being presented.

The user’s device supplicant needs to validate that server certificate and will check the signature of the authority that issued the certificate against its trust store of issuing authority certificates. The certificate issuer may itself only be an intermediate certification authority, so the suppliant will seek the issuer of the intermediate CA’s certificate with the aim of establishing a chain of trust to a root certification authority certificate. Root CA certificates are issued by the relevant certification authority itself and represent the foundation of the public-key infrastructure. Most of the main root CA certificates are shipped with operating systems when devices are built.

Whilst some operating systems permit the user to opt to simply trust a presented server certificate (or issuing CA certificate), this ‘trust on first use’ option does not represent best security practice. Ultimate trust is only established when the user’s device supplicant can establish that the RADIUS server certificate has been issued by a trusted root CA. Opting to not validate the server certificate, which was available on older operating systems, is bad security practice.

What certificates to install on the RADIUS server and present during authentication

We recommend that your server certificate chain should comprise:

  • the server certificate and
  • the issuing Certification Authority (CA) intermediate certificate(s)

i.e. your server cert and e.g. the Geant OV RSA CA 4 intermediate.

What certificates should be in the user’s device trust store/EAP profile and be used during authentication

We recommend that the user device contains the following:

  • the certificate of the intermediate CA that issued the server certificate
  • the root CA certificate of the issuer of the intermediate certificate(s)

e.g. the Geant OV RSA CA 4 intermediate and the *root* version of the UserTrust RSA Certification Authority

Nb. Whilst it may technically sufficient for the server to present only the server certificate if the user devices have both the root and intermediate(s) or for the device to only have the root CA certificate if the intermediate CA certificate is presented by the RADIUS server, the ‘belt and braces’ approach above is recommended.

What certificates to upload into the CAT system

When creating the EAP profile(s) for your users' devices, the certificates to the uploaded to CAT are:

  • the certificate of the intermediate CA that issued the server certificate (*)
  • the root CA certificate of the issuer of the intermediate certificate

e.g. Geant OV RSA CA 4 intermediate and USERTrust RSA Certification Authority CA root

(*) in some cases a second intermediate CA may be involved - one that has issued the cert of the certificate issing CA. The complete chain of intermediate CA certs may be uploaded (e.g. GEANT OV RSA CA 4 intermediate and the USERTRUST RSA CA intermediate). However of you can, it is better to use the CA root version of the USERTRUST RSA CA since this will result in a smaller EAP profile for the CAT/geteduroam download to client devices.  

How and where to acquire server certificates - private Certification Authority or public Certification Authority

You can operate your own private certification authority or purchase certificates from a commercial / public certification authority. The pros and cons of private vs public CAs for your server certificates are reviewed in section 1 on https://community.jisc.ac.uk/library/janet-services-documentation/faqs-eduroam-system-administrators-and-implementation-techs-0Note: if you opt to operate your own CA then you must set it up and configure it carefully to ensure that the certificates it issues comply with the requirements set out in the Generating the CSR section and linked Certificate Properties table as below.

Jisc enables you to purchase public CA certificates at very advantageous rates through the Geant Sectigo scheme and when used with properly configured CSRs provide server certs that work well with eduroam and you can avoid the complexity and effort of running your own CA.

Which solution to choose depends on individual organisation circumstances - either option is valid, although if the maximum certificate validity period for commercial CA certs is reduced from the current 12 months, the incentive to pite the bullet and operate your own CA will increase!

Whichever option you choose you will first need to generate a certificate signing request on the server you need the certificate for. How to generate a CSR is outside the scope of this article, however https://wiki.geant.org/display/H2eduroam/EAP+Server+Certificate+considerations provides essential guidance when creating the CSR on your RADIUS server. 

Generating the CSR

Detailed instructions on how to generate a certificate signing request on the varous platforms that exist is outside the scope of this article, however the table below describes the parameters you need to include and the values required when building your CSR and for Microsoft NPS users instructions on how to create your CSR can be found in section 8 of our guide eduroam(UK) Microsoft NPS Configuration Guide

https://wiki.geant.org/display/H2eduroam/EAP+Server+Certificate+considerations provides essential guidance when creating the CSR on your RADIUS server - the Certificate Properties table a third of the way down the page is particularly useful; contents summarised below.

  • Certificate type: you need an X.509v3 certificate.
  • Organisation-Validated (OV) or Domain-Validated (DV) ideally, although Extended Validation (EV) is usually okay. There is no benefit in the use of an EV certificate and in fact there have been reports of difficulties with ChromeOS. (OV Certs can be acquired more speedily too!)
  • Signature algorithm: SHA-256 or higher is the recommended secure hash algorithm for signing of the server certificate. 
  • The public key: should be at least 2048 bits and ideally 3072.
  • Common Name: CN name, the name of the server on the certificate needs to be look like a FQDN; the CN should not be a wildcard name (e.g. *.camford.ac.uk). Whilst the Common Name (CN) does not have to match the host name of the ORPS in DNS (the CN is just 'a name' and the RADIUS server is not a web server) it is best practice to use a fully qualified domain name as the CN for reasons of maximum compatibility with devices. There should be no spaces in the CN.
  • Extension: SubjectAlternativeName:DNS parameter in the Certificate field must not be empty - the CN and SubjectAlternativeName:DNS must have the same value and there must be an exactly matching value including upper/lower case. Whilst multiple SAN:DNS names can be configured on a certificate (in multiple ORPS deployments to match all hostnames of the servers), there is no necessity for eduroam purposes since SAN:DNS is only used (with geteduroam) to validate the CN name on the server certificate.
  • Extension: Extended Key Usage: only TLS Web Server Authentication certificates should be used - not to be confused with Extended Validation (EV) certificates. 
  • Extension: CRL Distribution Point: The certificate should include a Certificate Revocation List Distribution Point extension and the (HTTP:/HTTPS:) URI needs to be valid and publicly accessible. If you acquire your certificate from a public CA this will automatically be included on your certificate and the CA will manage the CRL point so you will not need to worry about it. If you operate your own CA, then you will need to identify a publicly accessible location where you can publish the CRL e.g. on a web server. In addition, when setting up your CA you will need to include in the configuration the URI of this CRL Distribution Point and also ensure that the CA is configured to ensure that the  Extension:CRL Distribution Point is included in issued certificates. To learn about Certificate Revocation Lists see: https://www.thesslstore.com/blog/crl-explained-what-is-a-certificate-revocation-list/
  • Extension: BasicConstraint (critical): must be CA:FALSE. It is essential that your certificate is marked as not being a certification authority certificate. But setting this as 'critical' is not necessary because even if you mark the extension as critical on your CSR, many Cert authorities ignore this when generating your certificate and criticality is not known to be checked by any OS supplicant. In fact if you use MS Windows Certification Authority to generate your own certificates, a bug in the software means that you should NOT tick the 'Make the basic constraints extension critical' box - the bug results in validation failure with Android 12. 

If you deploy multiple ORPS servers, since there is no technical requirement for each server to have a different certificate, it is recommended you use one certificate, imported into all your ORPSs, thereby avoiding issues of support and client configuration/certification. The certificate will have just the one CN component in the Subject field - and that is usually a server name, e.g. eduroam.ORPS1.camford.ac.uk. Note that by using just one CN this will allow you to increase the number of ORPSs in your cluster in the future if required by importing a further copy of the certificate. Note that you can use multiple certificates if you wish, but each certificate will need a unique CN/subjectAltName pair.

Using the Jisc Certificate Service

If using the Jisc Certificate Service, you’ll be able to upload your CSR and download the server certificate and the Geant OV RSA CA 4 intermediate via the Sectigo portal. (OV certificates are recommended but EV certificates may be used, but add no benefit, take longer to deliver and can cause problems on some devices).

Creating your server certificate:

  • Log in to the Sectigo Certificate Manager and navigate Certificates > SSL Certificate page
  • Click on the (+) button to add an enrollment request
  • Click on the 'Using a Certificate Signing Request (CSR)' option and click 'Next'
  • On the 'request SSL Certificate' form scroll down to the Order info section
  • Certificate Profile - 'Jisc OV Multi-Domain SSL' is recommended
  • Certificate Term - 1 year (no other option)
  • Enter your e-mail address and in the Notifications section for 'External Requesters' and click 'Next'
  • On the CSR page, populate the CSR box - drag your CSR file into the box and click 'Next'
  • (The old interface worked by clicking on the (UPLOAD CSR) button, [Choose File] and select your CSR, then click [Submit]) 
  • On the Domains page, the Common Name is auto-filled (Old interface - click the (GET CN FROM CSR) button)
  • Populate the Suject Alternative Names field by clicking the copy icon and pasting into the field, then click 'Next'
  • If you wish, select auto renew (old interface required an annual renew passphrase) 
  • Click on the OK (old interface 'Enroll') button

Acquiring your server certificate, intermediate CA cert and CA root cert:

You will receive an e-mail containing links enabling you to download the server certificate with various options to include the chain to the CA intermediate and root.

Alternatively you can use the Sectigo Certificate Manager portal:

  • go to Certificates > SSL Certificates 
  • Select your server certificate
  • Click on [View] button on the menu bar
  • Click on the download icon on the top right of the panel
  • From the drop down options list, select Certificate (w/ issuer after), PEM encoded
  • Your certificate bundle will download to your local Downloads folder

Note that if wish you can also download the AAA Certificate Services (Comodo) root certificate along with the UserTrust RSA Certification Authority intermediate cert and the Geant OV RSA CA 4 intermediate cert bundle. Scroll to the bottom of the list and select Root/Intermediates only, PEM encoded. If you need the AAA Certificate Services (Comodo) root certificate you can extract it from the file as described below.

Preparing your certificate for a) importing into your RADIUS server b) uploading to CAT

Assuming you have followed the above and acquired your certificate bundle via Jisc Certificate Service and the Sectigo portal - the file you have downloaded comprises the following:

[Server cert issued by  - Geant OV RSA CA 4 intermediate

[Geant OV RSA CA 4 intermediate - issued by USERTrust RSA Certification Authority]

[USERTrust RSA Certification Authority intermediate - issued by AAA Certificate Services (Comodo)]

You can use the bundle as is for import into your server, but you will need to split it for when your create your EAP profile in the CAT system. 

However we recommend that you also download the CA root version of the USERTrust RSA Certification Authority certificate.

The Geant OV RSA CA 4 intermediate is issued by USERTrust RSA Certification Authority. There are both root and intermediate CA versions of this USERTrust certificate. And both validate the Geant OV RSA CA 4 intermediate which in turn validates the Sectigo server certificates. But to reduce complexity and eliminate potential issues on certain user devices we recommend that you use the root CA version of the USERTrust certificate.

Download the root CA version via >> https://crt.sh/?id=1199354 <<

Assembling the certificate for your RADIUS server:

The aim at this stage is to concatenate the server and intermediate(s) certificates into one certificate file with the server certificate at the top followed by the intermediate certificates. (i.e. in reverse of the issuing order). You do not need the [Root certificate] to be in the chain. (This will just bloat the certificate and may result in unnecessary additional RADIUS packet exchange).

An example of the order for a root and two intermediate certificates: 

[Server certificate - issued by Intermediate certificate 2]
[Intermediate certificate 2 - issued by Intermediate certificate 1] 
[Intermediate certificate 1 - issued by Root certificate] 

If using Sectigo certificates - for the file bundles you have downloaded from the Sectigo portal - locate your downloaded server certificate bundle file and open it with e.g. Notepad. You will notice that each certificate begins with -----BEGIN CERTIFICATE----- and ends with -----END CERTIFICATE-----   The BEGIN and END lines form part of the certificate and must be retained when you cut and paste the certificate components in the bundle files.

Working with the 'Certificate (w/ issuer after), PEM encoded' file, scroll down and delete the third (end) certificate, this is the USERTrust CA intermediate - this is not needed.

You now have a certificate file with the necessary issuing certificate chain - you should not include a CA root certificate

This can now be imported into your RADIUS servers. And you can then configure your PEAP etc Network Profile/Connection Profile etc to use this.

Preparing the individual certificates for use with CAT:

With Notepad open the server certificate chain file you have just edited and select and copy the second certificate. Paste this into a new file and save, this is the Geant OV RSA CA 4 intermediate certificate. 

Assuming that you will be using the USERTrust RSA Certification Authority root certificate the issuing certification authority certificate is the cert you can download from https://crt.sh/?id=1199354

You will now have the following and are ready to upload these to CAT:

[Intermediate certificate (Geant OV RSA CA 4 intermediate cert) - issued by USERTrust RSA Certification Authority]

[Root certificate (USERTrust RSA Certification Authority root)]

Uploading certificates into the CAT system when creating your EAP profile

If you are not familar with the CAT system, see https://community.jisc.ac.uk/library/janet-services-documentation/eduroam-cat-configuration-assistance-tool

Certificates to the uploaded to CAT when creating the eduroam EAP profile(s) for your user devices:

  • the certificate of the intermediate CA that issued the server certificate e.g. Geant OV RSA CA 4 intermediate
  • the root CA certificate of the issuer of the intermediate certificate e.g. USERTrust RSA Certification Authority

However! Note that the Secitgo portal delivers the *intermediate* version of the USERTrust RSA Certification Authority CA certificate. You should use the root version of this certificate in uploads into the CAT system. The root version is available at https://crt.sh/?id=1199354

When you upload the certificates you will see that the CAT portal detects the certificate type and alongside the certificate file information box displays:

(R) root CA certificate 

(I) intermediate CA certificate 

(S) server certificate! - do not upload the server certificate

The certificate information box displays useful information about the certificate you have uploaded including the Organisation to which the certificate is issued, and the CN name on the certificate.

Renewing your server certificate

Certificates from public CAs are, these days, only valid for one year. You will therefore have to get your certificate renewed and to update your RADIUS systems: 

  • acquire renewed server certificate and import it into your RADIUS system
  • update your RADIUS configuration to use the replacement certificate file

It is recommended that you keep the old certificate in your server's trust store so that the private key is retained.

If you have acquired your certificate from the Jisc Cert Service you can use the Sectigo portal to renew/auto-renew and download your certificate. Log in to the Sectigo portal and navigate to your Certificates > SSL Certificates page. Select the server cert and as above select the certificate and click on the [View] button. A pop out box will apprear and from the download options list on the top right you can select 'Certificate only, PEM encoded'. The Intermediate and CA root certificates will be unchanged so you do not need to download those too, unless these ever change.

Testing your ORPS certificate installation

Pre-requisite: an eduroam test account should be created in your user directory and registered via the eduroam(UK) Support server - as per section 5.7 of the Implementation guide https://community.jisc.ac.uk/library/janet-services-documentation/implementing-eduroam-roadmap-part-1

There are two test systems you can use:

1) eduroam(UK) Support server [Certificate Check] button test on your Troublshoot page. This test can be sent from any of the NRPSs. In fact you should conduct the test from each NRPS in turn and target the test at each one of your ORPSs.

Go to the blue Tests panel, select the NRPS you wish to run the auth from, select your target ORPS (many members have multiple ORPSs) and click on the [Certificate Check] button. 

The results are: OK, Warn and Fail. Click on the result and scroll to the bottom of the debug output to learn more. The debug output will show you information about the certificates that your ORPS is presenting during the phase 1 part of the PEAP/MSCHAPv2 authentication. An analysis is presented indicating whether it has been possible to verify the certificate chain to a trusted certification authority root certificate and what issues may have been detected by the test.

2) The CAT 'realm reachability' test. This is documented at:
https://wiki.geant.org/display/H2eduroam/A+guide+to+eduroam+CAT+for+IdP+...

Log in to CAT and go to your Identity Provider Overview page. Scroll down to the 'Profiles for this Identity Provider section. In the Profile:eduroam panel click on the [Check realm reachability] button in the top right of the panel. There are 4 tabs, Overview, Static connectivity tests, Dynamic connectivity tests and Live login tests. Click on the Live login tests tab. (Ignore the other tests - except Static connectivity may be useful for a basic test).

Real (inner) username - Enter the full username of the test user you have created for your realm - and registered with eduroam(UK) on your Configure page on Support server.

Anonymous outer ID (optional) - this is optional. If you leave it blank the test will populate it with the inner identity username. You must use a full username if you wish to test an anonymous outerID e.g. 'anonymous@camford.ac.uk'

Password - this is the password of your test user account.

Click on the [Submit credentials] button. 

The output is sef-explanatory and displays quite a lot of information about the certificate your ORPS is presenting in the authentication request. It also checks against the certificate and CN details you have entered in your eduroam profile on CAT

Complete the remainder of your eduroam deployment and you will be 'good to go'

  1. Instruct your users to make use of geteduroam to get their devices correctly configured
  2. Correct use of username and password is essential!

If you find any errors or omissions, wish to add content or have any comments on this page, please e-mail eduroamuk@jisc.ac.uk