SST项目部署中遇到的无效证书问题分析与解决

问题背景

在使用SST框架部署Next.js应用时，开发者在GitHub Actions工作流中遇到了一个奇怪的证书验证问题。具体表现为：在dev分支部署成功，但在main分支部署时出现CloudFront证书无效的错误提示。

错误现象

部署过程中系统报错显示：

InvalidViewerCertificate: The specified SSL certificate doesn't exist, isn't in us-east-1 region, isn't valid, or doesn't include a valid certificate chain.

问题分析

1. 证书区域验证：错误提示明确指出证书需要在us-east-1区域，这是CloudFront分发证书的硬性要求。初步检查确认证书确实创建在该区域。

2. 环境差异：dev分支部署成功而main失败，表明问题与环境配置相关而非证书本身。

3. AWS账户隔离：进一步排查发现，问题根源在于AWS OIDC(OpenID Connect)配置。开发环境配置了正确的OIDC，但生产环境缺少相应配置。

根本原因

当使用GitHub Actions部署到不同AWS账户时，每个账户都需要独立的OIDC身份提供商配置。生产环境账户缺少OIDC配置导致：

• GitHub Actions无法正确认证
• 部署流程无法访问目标账户的证书资源
• 系统误判为证书不存在或无效

解决方案

1. 为每个环境配置独立OIDC：为生产环境账户创建专用的OIDC身份提供商，确保GitHub Actions有正确的访问权限。

2. 验证证书可见性：确保部署角色有权限查看和使用目标账户中的ACM证书。

3. 环境隔离检查：确认dev和prod环境的AWS账户完全隔离，避免配置混淆。

最佳实践建议

1. 基础设施即代码：将OIDC配置纳入基础设施管理，确保环境一致性。

2. 权限最小化：为CI/CD流程配置精确的IAM权限，仅授予必要的证书访问权限。

3. 环境一致性检查：建立部署前的环境验证流程，确保各环境配置同步。

4. 错误处理改进：在部署脚本中添加证书预检查逻辑，提前发现配置问题。

总结

这个案例展示了多云账户环境下基础设施部署的典型挑战。通过为每个目标环境配置独立的OIDC身份提供商，不仅解决了证书验证问题，也为团队建立了更健壮的持续交付基础。开发者在处理类似跨账户部署问题时，应当特别注意权限和身份验证机制的完整配置。