This page and its child pages contains all documentation, deployment guides, instructions and manuals related to the service operations. RESPONSIBLE: Information provided here is initially populated by the development team (during the transition phase), and revised based on the need or in a yearly service check by eduroam Managed IdP Service Manager. |
Installation and Configuration
The generic installation and configuration instructions are publicly available at https://github.com/GEANT/CAT/blob/master/tutorials/Configuration.md
After following all these, some amount of fine-tuning in the config files is needed. Most items are self-explanatory; specific documentation to be added here for neuralgic spots.
The development team will provide the initial and production-ready product configuration. The crucial parts that differentiate a normal CAT from Managed IdP deployment are:
- config-master.php → FUNCTIONALITY_LOCATIONS → CONFASSISTANT_RADIUS = "NONE"
- config-master.php → FUNCTIONALITY_LOCATIONS → CONFASSISTANT_SILVERBULLET = "LOCAL"
- generate and install all the per-NRO server cert CAs in config/SilverbulletServerCerts/* (GitHub scripts available, will be executed by dev team)
- generate and install the client cert issuing CA and corresponding (unprotected) private key in config/SilverbulletClientCerts/real.key and real.pem (see next section)
eduroam Managed IdP Client Certificate Root CA
It is crucial to have a trust anchor for all issued client certificates which is stable on the long-term. To that end, an offline hardware-backed CA is provisioned and kept in a physically safe position in GEANT property (TBD: where exactly is it stored, access controls to physical location). The CA itself is created with the CA generation script publicly available on GitHub.
The scripts require at least openssl 1.1.0.
IMPORTANT: adapt the settings/openssl-rsa.cnf and settings/openssl-ecdsa.cnf settings before issuing the CA. In particular:
- crlDistributionPoints
- caIssuers;URI.0
- OCSP;URI.0
In the generation scripts themselves, change the following parameters:
- CA.bootstrapnewRootCA: "randomsource" → /dev/hwrng as provided by the Raspberry Pi
need to point to the future URL of the CRL/OCSP Responder.
The script
CA.bootstrapNewRootCA
will generate TWO CAs, one with RSA/4096 bit keys, one with ECDSA/NIST P-521 keys. The latter one is future-proofing.
You are prompted for the CA password interactively on the keyboard. TBD: who has the password, how is it stored, how is long-term accessibility ensured.
Afterwards, edit again settings/openssl-rsa.cnf and settings/openssl-ecdsa.cnf settings with new URLs for the intermediate (Issuing) CA.
Subsequently, issue the command
CA.generateNewIntermediateCA
During the interactive creation, use a CN like "eduroam Managed IdP Central Issuing CA G1" (you have to do this twice, once for RSA and once for ECDSA).
Immediately after creation, create a new CRL (to assert that there are no revoked certificates at this point in time) and a new OCSP statement for the newly created intermediates:
CA.newCRL
CA.newOCSPStatementForSerial_RSA <serial number in decimal of the new RSA intermediate certificate>
CA.newOCSPStatementForSerial_ECDSA <serial number in decimal of the new ECDSA intermediate certificate>
The result of this set of commands are the files needed for CA operation:
| Technology | Certificate | Contains Private Key? | CRL | OCSP | Needed where? |
|---|---|---|---|---|---|
| RSA | ROOT-RSA/cacert.pem | ROOT-RSA/crl.der // ROOT-RSA/crl.pem | ROOT-RSA/OCSP/<serial>.response.der | RADIUS servers: trust root for chain validation | |
| ROOT-RSA/certs/N.N./cert-rsa.pem | X | RADIUS servers: trust chain building (certificate only) web interface: certificate and OCSP issuance (certificate + private key) | |||
| ECDSA | ROOT-ECDSA/cacert.pem | ROOT-ECDSA/crl.der // ROOT-ECDSA/crl.pem | ROOT-RSA/OCSP/<serial>.response.der | RADIUS servers: trust root for chain validation | |
| ROOT-ECDSA/certs/N.N./cert-ecdsa.pem | X | RADIUS servers: trust chain building (certificate only) web interface: certificate and OCSP issuance (certificate + private key) |
All of these files, but no others, are copied out of the CA environment for further use in operations (e.g. onto a USB stick).
If you ever need to revoke an intermediate, the corresponding scripts can be used (one variant for RSA, one for ECDSA, both to be called with the correspodning serial number of the certificate).
eduroam Managed IdP Server Certificate and CA set
eduroam installers will need to be configured with a server certificate trust (i.e. a root CA and a server name). To support the partitionability of the RADIUS service, each eduroam NRO gets its own self-signed root. This means approx. 200 self-signed CA certificates and server certificates need to be provisioned, all served by the RADIUS servers. The code to generate both the CA hierarchy and the FreeRADIUS configuration snippets to activate all those distinct personalities is available on GitHub.
In principle, one calls the script addnro.py with the ISO country code of a eduroam NRO and a URL to the future CRL Distribution Point, i.e.
scripts/addnro.py
LU
http://hosted.eduroam.org/server-ca/LU.der
For initial bootstrapping, there is a list of NROs and a script TBD which generates the needed NRO,CRLDP pairs. After running that script, the full list of all server certificates is generated with
scripts/addnro.py filename.txt
This will take a LONG while to complete.
Copy the CA certificates (without private key) to the web interface.
Copy the server certificates, the private keys and the FreeRADIUS config snippets to the RADIUS servers.
Interplay of the eduroam Managed IdP system components
eduroam Managed IdP includes multiple components which need to interwork correctly for the service as a whole to work. The following external dependencies between the components exist
eduroam Managed IdP web frontend → OCSP responder
issues OCSP statements for each of the certificates known to the system, using a cron job. See documentation on GitHub above. Make sure the cron job is running and verify that updated statements end up in the correct directory on the OCSP responder.
eduroam Managed IdP RADIUS Server → OCSP responder
makes request at OCSP responder during every user authentication. Make sure the HTTP communication between RADIUS server and OCSP Responder is possible.