Skip to content

[1.17] Fix Ed key parsing for 1.18 downgrade#9904

Merged
JoshVanL merged 1 commit into
dapr:release-1.17from
JoshVanL:fix-ed-key-type-parsing
May 8, 2026
Merged

[1.17] Fix Ed key parsing for 1.18 downgrade#9904
JoshVanL merged 1 commit into
dapr:release-1.17from
JoshVanL:fix-ed-key-type-parsing

Conversation

@JoshVanL

@JoshVanL JoshVanL commented May 7, 2026

Copy link
Copy Markdown
Contributor

Sentry fails to start with "unsupported key type" when the issuer key is Ed25519 or RSA

Problem

Operators who downgraded a control plane from 1.18 back to 1.17 saw dapr-sentry crash on startup with:

fatal: error creating CA: failed to get CA bundle: failed to verify CA bundle: unsupported key type ed25519.PrivateKey

The same failure mode also rejected RSA-keyed issuer bundles. The crash is hit before sentry serves any traffic, so every sidecar that depends on sentry for its identity certificate stops being able to obtain or rotate one.

Impact

Any 1.17 control plane whose dapr-trust-bundle secret was generated by, or migrated through, a newer Dapr release that issues Ed25519 (or RSA) issuer keys is affected. In practice this includes:

  • Downgrade from Dapr 1.18 to 1.17 against the same cluster.
  • Existing 1.17 deployments where the issuer key was rotated or replaced with an Ed25519 / RSA key by the operator.

Sentry crash-loops, no new mTLS identities are issued, and existing certificates are not rotated. Sidecars whose certs have not yet expired keep working; sidecars that come up fresh, restart, or hit cert expiry start failing to obtain identities.

Root Cause

dapr/kit's crypto/pem.EncodePrivateKey (used by sentry to re-encode the issuer key it just decoded from the trust bundle) only matched *ecdsa.PrivateKey and *ed25519.PrivateKey in its type switch. ed25519.PrivateKey is itself a []byte alias rather than a struct, so the *ed25519.PrivateKey case never matched a real Ed25519 key. RSA private keys were never listed at all.

When sentry called EncodePrivateKey on an Ed25519 or RSA issuer key it fell through to the default branch and returned unsupported key type %T, which the CA initialiser surfaced as a fatal error.

Solution

dapr/kit's EncodePrivateKey now matches ed25519.PrivateKey (value form) and *rsa.PrivateKey alongside *ecdsa.PrivateKey. All three round-trip through PKCS#8 unchanged. Dapr 1.17.7 picks up this fix by bumping github.com/dapr/kit to v0.17.1, which also includes table-driven roundtrip tests for ECDSA P-256, RSA-2048, and Ed25519 to guard the regression.

No operator action is required beyond upgrading sentry to 1.17.7. Existing trust bundles are read as-is; the issuer key is not regenerated.

Sentry fails to start with "unsupported key type" when the issuer key is Ed25519 or RSA

Problem

Operators who downgraded a control plane from 1.18 back to 1.17 saw `dapr-sentry` crash on startup with:

```
fatal: error creating CA: failed to get CA bundle: failed to verify CA bundle: unsupported key type ed25519.PrivateKey
```

The same failure mode also rejected RSA-keyed issuer bundles. The crash is hit before sentry serves any traffic, so every sidecar that depends on sentry for its identity certificate stops being able to obtain or rotate one.

Impact

Any 1.17 control plane whose `dapr-trust-bundle` secret was generated by, or migrated through, a newer Dapr release that issues Ed25519 (or RSA) issuer keys is affected. In practice this includes:

- Downgrade from Dapr 1.18 to 1.17 against the same cluster.
- Existing 1.17 deployments where the issuer key was rotated or replaced with an Ed25519 / RSA key by the operator.

Sentry crash-loops, no new mTLS identities are issued, and existing certificates are not rotated. Sidecars whose certs have not yet expired keep working; sidecars that come up fresh, restart, or hit cert expiry start failing to obtain identities.

Root Cause

`dapr/kit`'s `crypto/pem.EncodePrivateKey` (used by sentry to re-encode the issuer key it just decoded from the trust bundle) only matched `*ecdsa.PrivateKey` and `*ed25519.PrivateKey` in its type switch. `ed25519.PrivateKey` is itself a `[]byte` alias rather than a struct, so the `*ed25519.PrivateKey` case never matched a real Ed25519 key. RSA private keys were never listed at all.

When sentry called `EncodePrivateKey` on an Ed25519 or RSA issuer key it fell through to the default branch and returned `unsupported key type %T`, which the CA initialiser surfaced as a fatal error.

Solution

`dapr/kit`'s `EncodePrivateKey` now matches `ed25519.PrivateKey` (value form) and `*rsa.PrivateKey` alongside `*ecdsa.PrivateKey`. All three round-trip through PKCS#8 unchanged. Dapr 1.17.7 picks up this fix by bumping `github.com/dapr/kit` to `v0.17.1`, which also includes table-driven roundtrip tests for ECDSA P-256, RSA-2048, and Ed25519 to guard the regression.

No operator action is required beyond upgrading sentry to 1.17.7. Existing trust bundles are read as-is; the issuer key is not regenerated.

Signed-off-by: joshvanl <[email protected]>
Copilot AI review requested due to automatic review settings May 7, 2026 17:54
@JoshVanL
JoshVanL requested review from a team as code owners May 7, 2026 17:54

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Updates Dapr 1.17 to consume a dapr/kit patch release that fixes private key PEM encoding for Ed25519 (value type) and RSA keys, preventing dapr-sentry startup failures when trust bundles contain those issuer key types (notably after downgrades from newer control planes).

Changes:

  • Bump github.com/dapr/kit from v0.17.0 to v0.17.1.
  • Update go.sum to reflect the new dapr/kit version and checksums.
  • Add a v1.17.7 release note entry describing the Sentry crash-loop issue and resolution.

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated no comments.

File Description
go.mod Updates the github.com/dapr/kit dependency to v0.17.1 to pick up the key parsing/encoding fix.
go.sum Refreshes module sums for the dapr/kit v0.17.1 update.
docs/release_notes/v1.17.7.md Documents the Sentry “unsupported key type” downgrade/startup failure and its fix via the kit bump.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@JoshVanL
JoshVanL merged commit 8d6f2a4 into dapr:release-1.17 May 8, 2026
38 checks passed
cicoyle pushed a commit to WhitWaldo/dapr-cli that referenced this pull request May 22, 2026
The E2E - KinD non-HA matrix has been red for 10 days (since 2026-05-11).
TestRenewCertificateMTLSEnabled hangs at the 25-minute suite timeout in
the "Renew certificate which expires in less than 30 days" subtest.

Root cause: PR dapr#1629 bumped github.com/dapr/dapr from v1.17.3 to a
pseudo-version (commit f8d0f6142987, 2026-04-25) to pull in the workflow
proto renames. That commit also includes #9598 (Sentry: Ed25519 for
X.509 cert key generation, merged 2026-03-18). The CLI now generates
Ed25519 root/issuer certs via bundle.GenerateX509().

The E2E pinned runtime was 1.17.3, whose sentry cannot parse Ed25519
keys -- it crashes on startup with "unsupported key type
ed25519.PrivateKey" (a known issue documented in the 1.18 release notes
as the "rollback floor is 1.17.7" caveat). After the cert renewal step,
sentry crash-loops and the post-renewal `kubectl rollout status` call
(which has no timeout) blocks until the 25-minute test alarm fires.

Bumping the pinned version to 1.17.7 -- the first stable release that
includes the Ed25519 PEM-decoder fix (dapr/dapr#9904) -- aligns the
E2E runtime with the minimum compatible sentry for a 1.18 CLI.

Only non-HA matrix legs were affected because TestRenewCertificateMTLSEnabled
is skipped in HA mode (DaprModeNonHA guard at the top of the test).

Note: the unbounded `kubectl rollout status` in `restartControlPlaneService`
is a separate latent bug that turned this incompatibility into a 25-min
hang instead of a clean failure. Worth fixing in a follow-up.

Signed-off-by: Nelson Parente <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants