GitLab 14在CA/证书处理上的核心变更 #

针对你遇到的Pages服务与内部API通信的证书信任问题，GitLab 14主要有以下几处关键调整：

• 内部API通信验证收紧：GitLab 13中，Pages服务与内部API通信时可能默认信任系统级别的所有证书（包括自签CA），但v14开始要求显式配置受信任的CA证书，不再自动继承系统信任池的全部证书。
• 证书链完整性要求提升：v14对SSL证书链的完整性验证更严格，如果你的证书是由中间CA签发的，必须确保完整的链（根CA+中间CA）被Pages服务信任，否则会触发"未知权威"错误。
• Pages服务的CA证书配置独立化：v14新增了pages['internal_api_ca_file']配置项，用于指定Pages服务与内部API通信时使用的CA证书文件，之前v13可能依赖全局配置，现在需要明确指定。

针对性排查方向 #

按照以下步骤逐步定位问题：

• 检查GitLab Pages的CA证书配置
  打开/etc/gitlab/gitlab.rb，确认是否配置了pages['internal_api_ca_file']，指向你的根CA证书路径（比如/etc/gitlab/trusted-certs/your-ca.crt）。如果之前v13没配置这一项，v14必须添加后执行gitlab-ctl reconfigure生效。
• 验证证书及链的有效性
  用openssl命令测试gitlab-vm.intranet的证书是否能被你的CA信任：

  openssl s_client -connect gitlab-vm.intranet:443 -CAfile /path/to/your/ca.crt
  

  如果输出末尾显示Verify return code: 0 (ok)，说明证书本身没问题；如果返回其他错误（比如20表示无法获取本地 issuer证书），则需要补充完整的证书链。
• 确保CA证书被GitLab Pages加载
  将你的CA证书复制到/etc/gitlab/trusted-certs/目录，然后执行gitlab-ctl reconfigure。GitLab会自动将该目录下的证书添加到所有服务的信任池中，包括Pages服务。
• 检查内部API证书的域名匹配
  确认GitLab主服务的SSL证书（对应external_url的配置）中，Subject Alternative Name (SAN)字段包含gitlab-vm.intranet这个域名。你可以用以下命令查看证书的SAN：

  openssl x509 -in /path/to/gitlab-cert.crt -text -noout | grep -A 1 "Subject Alternative Name"
  

  如果gitlab-vm.intranet不在列表中，需要重新签发包含该域名的证书。
• 启用Debug日志排查细节
  在gitlab.rb中添加pages['log_level'] = 'debug'，执行gitlab-ctl reconfigure && gitlab-ctl restart gitlab-pages，然后查看/var/log/gitlab/gitlab-pages/current的日志，会有更详细的证书验证失败原因，比如是根CA未被信任，还是证书过期等。

内容的提问来源于stack exchange，提问作者steveq