GitLab

Caucase (before these changes) produces a single revocation list, which is signed by the active CA (which depends on rollover phases).

This is incorrect: once the new CA becomes active, no more CRL is produced with the old CA (and the existing CRLs are overwritten), which causes the validation of all certificates issued by the older CA to fail (because there is no CRL with an issuer matching the certificate being checked).

The python level logic should be all present. The 3rd commit should be either squashed in the 2nd, or dropped (and maybe the code it removes made a bit less ugly). The 2nd commit could maybe be split into a few smaller preparatory commits (but not much), and caucase.sh must be adatped. The extra commits are now squashed or dropped. Backward-compatibility at protocol-level is pointless: it does not solve any issue as the CRL served on the historic endpoint cannot be the correct one. Backward-compatibility at database level will be assured and tested.

The intended upgrade path is:

• upgrading caucase egg everywhere (ideally without starting caucased as it will likely fail on some operations, but it should be relatively harmless)
• exporting up the service ca certificates with caucased-manage --db /.../caucase.sqlite --export-ca my_caucase.ca.pem
• removing the old database: rm /.../caucase.sqlite
• importing the service ca certificates into a new database with caucased-manage --db /.../caucase.sqlite --import-ca my_caucase.ca.pem (and possibly also --import-crl with CRLs you recovered from existing caucase clients, if you revoked any service certificate)
• starting caucased as normal
• reissuing all user certificates and re-bootstraping trust on user's machines (there should be few users per caucased instance, so this is not expected to be a major hassle)
• restarting all caucase processes

Subtasks before merging & releasing:

• Update caucase.sh
• Update CHANGES.txt