Apache APISIX 使用 GCP Secret Manager 时的 SSL 证书验证问题解析

问题背景

在使用 Apache APISIX 3.11.0 版本集成 Google Cloud Platform (GCP) Secret Manager 时，当配置了 ssl_verify: true（默认值）并同时设置了 ssl_trusted_certificate 参数时，系统会出现 unable to get local issuer certificate 错误，导致无法正常获取 GCP 上的密钥信息。而当关闭 SSL 验证（ssl_verify: false）时，功能却能正常工作。

问题现象

具体表现为当尝试通过 GCP Secret Manager 获取密钥时，APISIX 会返回 401 未授权错误，并在错误日志中记录以下信息：

[lua] google-cloud-oauth.lua:62: refresh_access_token(): failed to refresh google oauth access token, 20: unable to get local issuer certificate

技术分析

这个问题本质上是一个 SSL/TLS 证书验证问题。当 APISIX 尝试与 GCP 的 OAuth2 服务进行通信以获取访问令牌时，SSL 握手过程中无法验证服务器证书的合法性。具体原因可能包括：

1. 系统缺少必要的根证书
2. 证书链不完整
3. 证书路径配置不正确

在 APISIX 中，ssl_trusted_certificate 参数用于指定受信任的 CA 证书文件路径，而 ssl_verify 参数控制是否启用 SSL 证书验证。理论上，当两者都正确配置时，SSL 验证应该能够正常工作。

解决方案

经过测试验证，在 APISIX 3.11.0 版本中，只需在配置文件中正确设置以下内容即可解决此问题：

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

这个配置指定了系统信任的 CA 证书存储路径，通常这个路径包含了大多数主流 CA 的根证书，包括 Google 使用的证书颁发机构。

最佳实践建议

1. 证书管理：确保系统中有完整的 CA 证书链，特别是在容器化环境中，可能需要显式安装 ca-certificates 包。

2. 配置验证：在配置 GCP Secret Manager 集成时，建议先测试基础连接性，再逐步添加安全限制。

3. 版本兼容性：注意不同 APISIX 版本间的行为差异，某些问题可能在新版本中已得到修复。

4. 安全权衡：虽然设置 ssl_verify: false 可以快速解决问题，但在生产环境中不建议这样做，这会降低系统的安全性。

总结

SSL/TLS 证书验证是保障系统间通信安全的重要机制。在 APISIX 与 GCP 服务集成时，正确配置证书信任链是关键。通过合理设置 ssl_trusted_certificate 参数，可以在保持安全性的同时确保功能正常运作。随着 APISIX 版本的迭代，这类集成问题通常会得到更好的支持和更简单的配置方式。