Problem statement

When a device certificate is renewed we must be sure the new certificate is trusted by the cloud endpoint
before substituting this new certificate for the current one.

Implementing this validity check with the current implementation of tedge cert renew and tedge connect is feasible but fragile.
One has to back up the current certificate, to ask a renewal, disconnect then reconnect -
and, if things are going wrong, to restore the previous certificate before reconnect.

• It's too easy to forget a back-up of the current certificate before a renewal
• A user might also forget to reconnect, still using the near-to-expire certificate,
  and be fooled by a tedge cert show command that is related to the new certificate.

To make things less fragile:

• the renew command should not erase the current device certificate
  but provides a new certificate to be checked by the connect command
• the connect command should check and promote as current the new certificate in an atomic manner
• the cert show and cert needs-renewal command should be related to the certificate actually in use and not to the new one.

Proposal

• Thin-edge maintains 2 certificates (current and new) for each cloud profile.
• The paths to these certificates are derived from the device.cert_path tedge config setting.
  • "$(tedge config get device.cert_path)" is the path to the certificate currently used to connect the cloud endpoint
  • "$(tedge config get device.cert_path).new" is the path to a new certificate, if any, still to be validated.
• The command tedge cert renew uses the current certificate but doesn't replace it (as done today)
  • instead the new certificate is stored into "$(tedge config get device.cert_path).new"
  • and will be promoted as the current certificate only after appropriate checks.
• The promotion of a new certificate as the current certificate is done by the tedge connect command.
• If there is no new certificate, tedge connect proceeds as today using the current certificate.
• If there is a new certificate, tedge connect uses the new certificate to connect
  • On a successful connection the new certificate is promoted as the current one (with mv new current),
    meaning that on subsequent connects the new certificate will be the default
  • If the connection fails with the new certificate, tedge connect proceeds with the current certificate
    and let the certificates unchanged, meaning that on a subsequent connect the new certificate will be checked again.
• If tedge cert renew is called while there is still a new unvalidated certificate,
  the renew command proceeds replacing the new certificate with a new candidate certificate to be checked by tedge connect.

Describe alternatives you've considered

Additional context