兄弟我太懂这种自签名证书卡脖子的滋味了，之前折腾CI/CD的时候也踩过一模一样的坑，给你整理几个亲测有效的解决办法，按你的场景选就行：

方案1：让系统和GitLab Runner信任自签名证书（推荐生产用） #

这是最规范的做法，从根源上解决证书信任问题：

• 先拿到你的GitLab自签名证书：可以在GitLab服务器上找，一般存放在/etc/gitlab/ssl/目录下，文件名通常是gitlab.crt；或者直接用浏览器访问GitLab，在地址栏导出证书文件。把这个证书传到Runner服务器上，建议放到/usr/local/share/ca-certificates/目录里（Debian/Ubuntu系的系统默认证书存放地）。
• 更新系统的证书信任列表，执行对应命令：

  # Debian/Ubuntu系
  update-ca-certificates
  # RHEL/CentOS系
  update-ca-trust extract
  

• 重启GitLab Runner服务，让它加载新的信任证书：

  gitlab-runner restart
  

方案2：临时跳过SSL验证（仅测试环境用！） #

如果只是测试环境不想折腾证书，可以临时让Git跳过SSL验证，但生产环境绝对别用，不安全：

• 方法一：修改Runner全局配置，找到/etc/gitlab-runner/config.toml，在[[runners]]代码块里添加环境变量：

  environment = ["GIT_SSL_NO_VERIFY=true"]
  

  改完保存后重启Runner。
• 方法二：在你的CI/CD .yml 文件里，给每个Job加前置脚本：

  before_script:
    - git config --global http.sslVerify false
  

方案3：Docker版GitLab Runner的额外处理 #

如果你的Runner是用Docker部署的，除了做方案1的系统证书配置，还要把证书挂载到Runner容器里：

• 启动容器时挂载证书（新启动Runner的场景）：

  docker run -d --name gitlab-runner --restart always \
    -v /srv/gitlab-runner/config:/etc/gitlab-runner \
    -v /usr/local/share/ca-certificates/gitlab.crt:/etc/ssl/certs/gitlab.crt:ro \
    gitlab/gitlab-runner:latest
  

• 或者修改已有的config.toml，在runners.docker块里添加挂载配置：

  volumes = ["/usr/local/share/ca-certificates/gitlab.crt:/etc/ssl/certs/gitlab.crt:ro"]
  

  改完后重启Runner容器。

验证配置是否生效 #

配置完之后，在Runner服务器上再跑一次：

openssl s_client -connect my_gitlab_server_url.com:443

如果输出里看到Verify return code: 0 (ok)，就说明证书信任成功了，再触发一次Merge Request看看Job能不能正常跑起来。

最后说句实在的，你遇到的Verify return code:19就是系统不认可自签名证书的典型报错，本质是这个证书没在Runner的信任列表里，上面的方法都是围绕把证书加入信任链来解决的，放心试！