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-0. Note: 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.

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: