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.
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. 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).
Specific Instructions to make CAT instance a Managed IdP one
- 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/*
- generate and install the client cert issuing CA and corresponding (unprotected) private key in config/SilverbulletClientCerts/real.key and real.pem
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.