Apache APISIX 中 GCP 密钥管理器 SSL 证书验证问题解析

问题背景

在使用 Apache APISIX 3.11.0 版本集成 Google Cloud Platform (GCP) 密钥管理器时，当配置了 ssl_verify 为 true 且同时设置了 ssl_trusted_certificate 参数时，系统会出现证书验证失败的问题。具体表现为返回 401 未授权错误，并在错误日志中显示"unable to get local issuer certificate"的证书验证失败信息。

问题现象

当开发者按照标准流程配置 APISIX 与 GCP 密钥管理器的集成时，如果启用了 SSL 证书验证功能，系统会无法正常获取 OAuth 访问令牌，导致后续的密钥获取操作失败。错误日志中会明确显示本地颁发机构证书获取失败的信息。

技术分析

这个问题本质上是一个 SSL/TLS 证书链验证问题。当 APISIX 尝试与 GCP 的 OAuth 服务进行通信以获取访问令牌时，系统需要验证 GCP 服务器的证书。验证过程需要：

1. 服务器提供的证书
2. 中间证书颁发机构的证书
3. 根证书颁发机构的证书

在默认配置下，APISIX 可能无法找到完整的证书链来完成验证过程，特别是当运行环境缺少某些系统根证书时。

解决方案

经过测试验证，在 APISIX 3.11.0 版本中，可以通过以下配置解决此问题：

apisix:
  ssl:
    ssl_trusted_certificate: /etc/ssl/certs/ca-certificates.crt

这个配置指定了系统信任的证书存储路径，通常包含了大多数公共证书颁发机构的根证书。在 Docker 环境中，这个路径通常包含了完整的证书链，能够满足与 GCP 服务通信时的证书验证需求。

最佳实践建议

1. 证书管理：确保你的 APISIX 实例能够访问完整的证书链。在生产环境中，可以考虑定期更新证书文件。

2. 版本兼容性：确认你使用的 APISIX 版本已经包含了相关修复。3.11.0 版本已经验证可以正常工作。

3. 安全权衡：虽然将 ssl_verify 设置为 false 可以临时解决问题，但这会降低安全性，不建议在生产环境中使用。

4. 环境一致性：在不同环境(开发、测试、生产)中保持证书配置的一致性，避免因环境差异导致的问题。

总结

SSL/TLS 证书验证是保障系统间通信安全的重要机制。通过正确配置 ssl_trusted_certificate 参数，开发者可以在保持安全性的同时，实现 APISIX 与 GCP 密钥管理器的无缝集成。这个问题也提醒我们，在现代微服务架构中，正确处理证书链验证是确保系统间可靠通信的关键环节。