证书过期导致构建失败
项目上线前夜，流水线突然卡在部署环节，日志显示“SSL certificate has expired”。这种情况并不少见。证书不是一劳永逸的配置，尤其是内部CA签发的证书，有效期通常较短。团队可能在年初配置过一次，后续没人跟进，等到自动续签机制失效时，问题就集中爆发了。
建议在CI/CD流程中加入证书有效期检查步骤。比如在流水线早期阶段运行一个轻量脚本，检测目标服务器或密钥库中的证书剩余天数。低于30天时标记为警告，低于7天则直接中断部署。
openssl x509 -in cert.pem -noout -enddate | awk -F= \'{print $2}\'这个命令可以提取证书的过期时间，配合date命令做差值计算，就能判断是否临近过期。
多环境证书混淆
开发、测试、预发布、生产四个环境，每个都有独立的域名和证书。但在配置流水线时，有人图省事，把测试环境的证书路径复制到生产任务里，结果部署到线上后服务无法启动，前端访问直接报“您的连接不是私密连接”。
这类问题根源在于变量管理混乱。正确的做法是使用环境变量隔离敏感信息。Jenkins可以用Credentials Binding插件，GitLab CI推荐用CI/CD Variables，并按环境设置不同的保护级别。确保生产环境的证书变量只能由特定分支触发时才注入。
证书权限配置错误
流水线运行在容器中，挂载了宿主机的证书文件。但容器内的构建用户没有读取权限，导致命令执行时报“Permission denied”。这种错误在本地调试时不容易发现，因为开发者往往用root跑脚本。
解决方法是在部署前显式调整权限。比如：
chmod 644 /etc/ssl/certs/app-cert.pem
chown builder:builder /etc/ssl/private/key.pem同时在Docker镜像中明确声明运行用户，避免权限错位。
中间证书缺失
有些团队自己搭建了私有CA，签发证书时只导出了终端实体证书，没把中间CA链一起打包。结果服务启动后，客户端验证失败，提示“unable to get local issuer certificate”。
正确做法是生成完整的证书链文件。例如：
cat app.crt intermediate.crt root.crt > fullchain.crt然后在Nginx或应用配置中引用fullchain.crt，而不是单独的app.crt。
自动化续签未生效
用了Let's Encrypt的certbot自动续签，也配置了cron任务，但某天发现网站证书还是过期了。排查发现是流水线中硬编码了证书路径，而certbot续签后生成了新目录，旧路径失效。
应该通过符号链接或配置管理工具动态指向最新证书。比如certbot默认会维护latest链接，CI脚本应始终引用/etc/letsencrypt/live/your-domain/fullchain.pem，而不是具体版本路径。
","seo_title":"CI/CD流水线管理证书故障排查指南","seo_description":"详解CI/CD流水线中证书管理常见问题，包括过期、权限、链不完整等实际场景及解决方案","keywords":"CI/CD,流水线,证书管理,SSL证书,构建失败,证书过期,自动化部署"}