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:
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.
CA operations are performed on the project-procured Raspberry Pi 3. The Pi needs the following preparatory actions:
Q to the SM: is it acceptable to take the preparatory steps before traveling to the signing ceremony? Or do everything live?
IMPORTANT: adapt the settings/openssl-rsa.cnf and settings/openssl-ecdsa.cnf settings before issuing the CA. In particular:
|
In the generation scripts themselves, change the following parameters:
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 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.
The script will be executed by the dev team during initial installation, directly on one of the RADIUS servers so that the server certificate private keys are immediately on the right host and need no copying.
The instructions to follow are in the Git repo.
The entire process 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.
Store the CA certificate private key set offline in a safe place. (TBD: where, access controls)
Main Services:
Logs:
Main Services:
Logs:
Main Services:
Logs:
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
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.
makes request at OCSP responder during every user authentication. Make sure the HTTP communication between RADIUS server and OCSP Responder is possible.