ctrl_encrypt_cert_change: rotate ECDH cert without restart

[eriknordmark]

Summary

End-to-end test for rotation of the controller's ECDH encryption certificate (CERT_TYPE_CONTROLLER_ECDH_EXCHANGE, encrypt.pem), independent of the signing cert. Two commits:

1. Plumbing — eden utils gen-encrypt-cert, eden adam change-encrypt-cert, eden pod deploy --use-encrypt-cert. The --use-encrypt-cert flag makes prepareCipherData derive ECDH from encrypt-key.pem and tag the cipher context with the encrypt cert hash, mirroring production controller layouts where signing and ECDH are distinct certs with independent lifetimes. A new cipher-context-cert-hash filter in reencryptConfigs (and the new reencryptConfigsForEncryptCert) lets the two rotation commands coexist: each only re-encrypts cipher blocks whose context references the cert it owns.

2. Test — ctrl_encrypt_cert_change.txt, registered as smoke step 24/26. Deploys three eclient apps with --use-encrypt-cert, rotates encrypt + signing certs twice, verifies fresh-app deployment after each rotation, cross-checks the rotated cert is advertised in pubsub, and confirms reboot survival.

Why each rotation rotates both signing and encrypt

EVE's only fast trigger for /certs refetch is signing-cert mismatch in the auth-envelope SenderCertHash (controllerconn/authen.go:152-162). The cipher decrypt path returns "Controller Certificate get fail" without triggering refetch, adam doesn't populate EdgeDevConfig.controllercert_confighash so handleControllerCertsSha is dead, and the periodic controllerCertsTask defaults to CertInterval = 24h. See lf-edge/eve#5926 for the gap analysis and lf-edge/adam#152 for the fix; once that adam patch ships in an Eden-tracked release, the test can be extended with a pure encrypt-cert rotation.

Verification approach

1. Fresh-app deployment is the primary signal. After each rotation, eclient2/eclient3 is deployed with --use-encrypt-cert — the cipher block uses the just-rotated ECDH key. Reaching RUNNING means EVE pulled /certs (triggered by the paired signing rotation), published the new Type=3 cert into pubControllerCert, and decrypted the cipher block.

2. Cert-chain cross-check. check_encrypt_cert.sh walks /run/zedagent/ControllerCert/ (or /persist/... on EVE where that pubsub is Persistent: true), filters for Type=3, and byte-matches the decoded PEM against encrypt-new.pem (normalized for adam's strings.TrimSpace).

3. Reboot survival. After both rotations + a reboot, all three apps come back RUNNING and the cert chain still has the rotated encrypt cert.

Test plan

• CI smoke matrix — 3 of 4 entries reach the test and pass; the fourth (Smoke (ext4, false)) hits the upstream log_test flake that log_test flakes on Smoke (ext4, false) waiting for 'Disconnected' log #1156 addresses, before reaching step 24.
• gofmt -l pkg/ cmd/ clean
• go build ./... clean
• go test ./pkg/openevec/... passes
• Existing ctrl_cert_change.txt continues to pass (the new reencryptConfigs filter is a no-op for it — its cipher contexts all reference the signing cert hash, which is what the filter selects).

Notes for reviewers

• This branch is rebased onto lf-edge/eden#1156's log_test fix (4b0a8cd). That commit will fall away naturally once log_test flakes on Smoke (ext4, false) waiting for 'Disconnected' log #1156 merges and we rebase onto upstream master.
• adam Old config is not cleaned from SD card once RPi is updated #152 is a separate PR that this Eden PR does not depend on — adam Old config is not cleaned from SD card once RPi is updated #152 enables a future Eden test enhancement, not a current requirement.

🤖 Generated with Claude Code