Spring Cloud Config 支持多版本密钥共存需启用密钥别名机制，使用JKS密钥库、配置key-store.alias指定默认密钥，并通过自定义NamedKeyTextEncryptor解析密文前缀（如{cipher:v2}）自动选密钥，确保新旧密钥双轨运行、历史数据可解密、满足等保2.0与密评要求。
定期轮换配置中的应用级密码与密钥，不是“换个值再重启服务”那么简单；它必须确保旧密钥仍能解密历史配置、新密钥用于新增敏感项、客户端无感知切换，同时满足等保2.0第三级“加密密钥生命周期管理”和商用密码应用安全性评估（密评）中对密钥轮换频次、审计日志、多版本共存的硬性要求。
如何配置 Spring Cloud Config 支持多版本密钥共存
Config Server 默认只认一个 encrypt.key 或 key-store.alias，强行替换会导致老配置无法解密、服务启动失败。必须启用密钥别名机制，让新旧密钥并存、按需调用。
- 使用 JKS 密钥库而非明文密钥：避免
encrypt.key配置被泄露或误提交到 Git - 在
application.yml中明确指定密钥库位置与默认别名：encrypt:<br> key-store:<br> location: classpath:/configserver.jks<br> password: changeme<br> alias: config-server-key-v1<br> secret: changeme
- 新增密钥时，用
keytool为同一 JKS 添加新别名：keytool -genseckey -alias config-server-key-v2 -keyalg AES -keysize 256 -storetype JCEKS -keystore configserver.jks - Config Server 启动后，可通过
/encrypt/{cipher}和/decrypt/{cipher}端点验证不同别名是否可用（需配合请求头X-Config-Key-Alias: config-server-key-v2）
为什么不能直接删掉旧密钥——解密兼容性陷阱
一旦从 JKS 中删除旧别名（如 config-server-key-v1），所有已加密但尚未重写为新密钥格式的配置项（例如数据库密码字段）将在客户端启动时触发 IllegalBlockSizeException 或静默返回空值，而不是报错提示，极易漏检。
- 等保2.0 要求“历史数据可追溯、可还原”，意味着至少保留上一周期密钥 6 个月以上（日志保存期下限）
- 密钥轮换不是“一刀切”，而是“双轨运行”：新配置走
v2，存量配置继续由v1解密，直到全量配置完成迁移 - Config Server 不会自动识别密文该用哪个别名解密——它依赖密文头部隐式标记或请求头显式指定；若未带
X-Config-Key-Alias，默认使用key-store.alias配置的值 - 建议在 CI/CD 流水线中加入检查：扫描 Git 历史配置文件，统计含
{cipher}的行数及首次出现时间，辅助判断旧密钥下线窗口
怎么让服务端自动选密钥——避免每次请求都手动传 header
让每个客户端请求都带上 X-Config-Key-Alias 不现实，尤其在已有大量微服务接入的情况下。Config Server 本身不支持“按配置路径路由密钥”，但可通过自定义 TextEncryptor 实现透明识别。
- 继承
NamedKeyTextEncryptor，重写decrypt方法：解析密文前缀（如{cipher:v2}xxx）提取版本标识 - 在 Spring Boot
@Configuration类中注册 Bean 替换默认TextEncryptor，注意保持线程安全（ThreadLocal存储当前别名） - 密文格式需统一约定，例如：
password: "{cipher:v2}AQE8b6d"，否则无法解析 - 此方案绕过官方推荐路径，升级 Spring Cloud 版本时需重新验证兼容性；更稳妥的做法是：在配置中心前端加一层网关，根据请求路径或标签自动注入 header
真正难的不是生成新密钥，而是确认所有服务实例都已完成新密钥配置、所有历史密文都已被重刷、所有日志和监控中不再出现旧密钥解密失败告警——这些动作没有自动回执，只能靠交叉验证。等保测评时，检查项不是“有没有轮换”，而是“轮换过程是否有记录、有验证、有回滚能力”。
