Implement admin POST method to change controller signing certificate in runtime

[milan-zededa]

Recently, we have seen many issues where EVE didn't properly handle a change in the controller signing certificate. It would be therefore beneficial to prepare an eden test in which the signing certificate used by Adam is changed after device is onboarded. This can be combined with poor network connectivity (which can be modeled with eden), etc. (conditions that triggered aforementioned issues).

However, even though there is a POST method declared for /certs (to presumably change the controller certificate), it is not implemented. Handler apiv2.certs does not check the request method type and always behaves as GET method, returning the set of installed certificates.

Edit: As pointed out by @giggsoff, instead of using the mentioned /certs endpoint, which is actually used between EVE and Adam, we should add a new POST method under the Admin handler, that could be then used from Eden CLI to update the controller certificate in runtime.

CC @eriknordmark @rouming

[giggsoff]

The endpoint you point onto responsible for communication between Adam and EVE-OS (described here). It is quite strange that there are POST handler there, but I think that endpoints for communication between admin (Eden?) and Adam should be separated (probably into admin handler).

Small question: as I can see currently signing certificate configured using command line option, which points onto file from Eden. Will the re-creation of the file (and probably re-start of Adam) be enough in the workflow you want to check? Do we really need to implement any handler?

[eriknordmark]

I guess one additional question is whether some POST should take the identical payload as what's returned by the GET, which is the full set of controller certificates (signing, encryption, plus zero or more intermediate certs). Plus the questions from Petr about the file and command line option etc.

[milan-zededa]

Will the re-creation of the file (and probably re-start of Adam) be enough in the workflow you want to check? Do we really need to implement any handler?

@giggsoff Wouldn't a restart of Adam lead to a loss of same state information (device UUID, device config, etc.)?

[giggsoff]

Will the re-creation of the file (and probably re-start of Adam) be enough in the workflow you want to check? Do we really need to implement any handler?

@giggsoff Wouldn't a restart of Adam lead to a loss of same state information (device UUID, device config, etc.)?

It is true, we have the driver with no persistent state, it is memory one. But I hope nobody use it in production (or how we can name it). We have file driver and redis driver as well, both of them recover after restart. Eden uses redis one with persistent redis.

Potentially we can avoid restart of Adam, assume the next request will read novel certificate file.