发布日期: 2026-06-11
版本号: v1.16.15

Dapr 1.16.15版本发布，主要修复了一个错误：当颁发者密钥为Ed25519或RSA类型时，Sentry服务会因不支持的密钥类型而启动失败。该问题影响那些从1.18版本降级回1.16的控制平面，或使用过新版生成的信任包密钥的1.16部署。由于Sentry无法启动，依赖其签发或轮换身份证书的Sidecar服务将受到影响。根本原因在于加密库在处理私钥编码时未能正确匹配Ed25519和RSA类型的密钥。修复方案通过更新dapr/kit依赖库，增加了对Ed25519和RSA密钥的支持，确保它们能正确通过PKCS#8格式转换。

更新内容 （中文）

Dapr 1.16.15

本次更新包含一项错误修复：

Sentry 因"不支持的密钥类型"无法启动（当颁发者密钥为 Ed25519 或 RSA 时）

问题描述

将控制平面从 1.18 版本降级至 1.16 版本的运维人员发现，dapr-sentry 在启动时崩溃并显示：

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

使用 RSA 密钥的颁发者证书包也会出现相同的故障模式。 崩溃发生在 Sentry 开始服务任何流量之前，因此所有依赖 Sentry 获取身份证书的边车都将无法获取或轮换证书。

影响范围

任何其 dapr-trust-bundle 密钥由或通过较新 Dapr 版本（该版本颁发 Ed25519 或 RSA 颁发者密钥）生成或迁移的 1.16 控制平面均受影响。实际包括：

  • 在相同集群上从 Dapr 1.18 降级至 1.16。
  • 颁发者密钥已由运维人员轮换或替换为 Ed25519 / RSA 密钥的现有 1.16 部署。

Sentry 持续崩溃循环，无法颁发新的 mTLS 身份，且现有证书不会被轮换。证书尚未过期的边车可继续工作；新启动、重启或证书过期的边车则无法获取身份。

根本原因

dapr/kit 的 crypto/pem.EncodePrivateKey（Sentry 用于重新编码刚从信任证书包中解码的颁发者密钥）在其类型转换中仅匹配 *ecdsa.PrivateKey 和 *ed25519.PrivateKey。ed25519.PrivateKey 本身是 []byte 的别名而非结构体，因此 *ed25519.PrivateKey 分支从未匹配真正的 Ed25519 密钥。RSA 私钥则完全未被列出。

当 Sentry 对 Ed25519 或 RSA 颁发者密钥调用 EncodePrivateKey 时，会进入默认分支并返回 unsupported key type %T，CA 初始化器将其作为致命错误抛出。

解决方案

dapr/kit 的 EncodePrivateKey 现在匹配 ed25519.PrivateKey（值形式）和 *rsa.PrivateKey，同时保留对 *ecdsa.PrivateKey 的匹配。三者均通过 PKCS#8 格式保持不变。 Dapr 1.16.15 通过将 github.com/dapr/kit 升级至 v0.16.3 采纳此修复，该版本还包含针对 ECDSA P-256、RSA-2048 和 Ed25519 的表驱动往返测试以防止回归。

更新内容 （原始）

Dapr 1.16.15

This update contains a bug fix:

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.16 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.16 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.16 against the same cluster.
  • Existing 1.16 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.16.15 picks up this fix by bumping github.com/dapr/kit to v0.16.3, which also includes table-driven roundtrip tests for ECDSA P-256, RSA-2048, and Ed25519 to guard the regression.

下载链接