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. |
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.
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:
|
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).
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