Docker-GitLab 容器中 AWS S3 备份失败的 SSL 证书问题解析与解决方案

问题现象

在使用 sameersbn/docker-gitlab 项目部署的 GitLab 容器环境中，当配置了 AWS S3（或兼容 S3 协议的自建存储如 MinIO）作为备份存储后，从 17.1.1 版本升级到 17.3.2 版本时，备份任务会失败并出现 SSL_CTX_load_verify_locations: system lib 的 OpenSSL 错误。该问题在使用 Let's Encrypt 等有效证书的情况下也会发生。

技术背景

这个问题本质上是 Ruby 运行时的 SSL 证书验证路径配置问题。在 Linux 系统中，OpenSSL 通常会在以下路径查找证书：

• /etc/ssl/certs/ca-certificates.crt（Debian/Ubuntu 系）
• /etc/pki/tls/certs/ca-bundle.crt（RHEL/CentOS 系）

然而 Ruby 的某些版本（特别是容器环境中）会默认查找 /usr/lib/ssl/cert.pem 这个路径。当这个路径不存在时，就会导致 SSL 验证失败。

解决方案

临时解决方案（适用于紧急修复）

可以通过在容器内创建符号链接来临时解决：

ln -s /etc/ssl/certs/ca-certificates.crt /usr/lib/ssl/cert.pem

永久解决方案

对于 sameersbn/docker-gitlab 项目的用户，该问题已在后续版本中通过以下方式修复：

1. 在容器构建阶段自动创建正确的证书链接
2. 确保所有 SSL 证书路径都被正确配置

最佳实践建议

1. 版本升级注意事项：在升级 GitLab 容器前，建议先测试备份功能
2. 证书管理：对于自建存储，确保：
   • 使用有效的 TLS 证书
   • 证书链完整
   • 中间证书正确安装
3. 容器维护：定期检查容器内的证书链接是否有效

问题影响范围

该问题主要影响：

• 使用 S3 协议存储备份的用户
• 从较旧版本升级到 17.3.x 版本的用户
• 使用自定义证书或特定证书颁发机构证书的环境

技术原理深入

OpenSSL 在验证证书时需要访问系统的信任存储（trust store）。在容器环境中，由于文件系统隔离和精简的基础镜像，有时会缺少某些标准路径。Ruby 的 SSL 实现会按照特定顺序查找证书，当默认路径不存在时就会报错。解决方案的核心就是确保 Ruby 能够找到系统的证书存储。