Windows Runner - CERT_TRUST_REVOCATION_STATUS_UNKNOWN error when using self-signed certificate / cert with no CRL

Summary

The error CERT_TRUST_REVOCATION_STATUS_UNKNOWN is produced while using a self-signed/auto-generated wildcard certificate or certificate otherwise not providing a CRL when the Windows runner performs git operations.

Steps to reproduce

  1. Configure GitLab to use a self-signed certificate, such as Option 4 in the installation documentation.
  2. Configure and attempt to run a job on a Windows runner (Only tested with Kubernetes executor)

Actual behavior

The error below is observed in the job log:

Created fresh repository.
powershell : fatal: unable to access 
'https://gitlab.redacteddomain/runners/windows.git/': schannel: 
CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN
At C:\scripts-5-1312\terminate_with_json_script.ps1:7 char:1
+ powershell -File $Path
+ ~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (fatal: unable t..._STATUS_UNKNOWN 
   :String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

The same is seen when manually using curl with supplied cert:

C:\builds\runners\windows.tmp>curl -v --cacert ./CI_SERVER_TLS_CA_FILE https://gitlab.redacteddomain
*   Trying 18.170.16.138:443...
* Connected to gitlab.redacteddomain (18.170.16.138) port 443 (#0)
* schannel: disabled automatic use of client certificate
* ALPN: offers http/1.1
* schannel: added 2 certificate(s) from CA file './CI_SERVER_TLS_CA_FILE'
* schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN
* Closing connection 0
* schannel: shutting down SSL/TLS connection with gitlab.redacteddomain port 443
curl: (60) schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Expected behavior

The job should not fail TLS handshake with the GitLab server and git operations should complete successfully.

Environment description

  • Tested on helm deployed GitLab: gitlab-7.1.1 (16.1.1)
  • Runner: gitlab-runner-0.54.0 16.1.0
  • Tested only with the kubernetes executor
config.toml contents 
runners:
  name: cms-gitlab-runner-k8s-b2d-windows-2019
  privileged: false
  outputLimit: 16384
  config: |
    [[runners]]
      executor = "kubernetes"
      shell = "powershell"
      environment = [ "FF_USE_POWERSHELL_PATH_RESOLVER=1" ]
      [runners.kubernetes]
        poll_interval = 3
        poll_timeout = 3600
        pull_policy = ["always", "if-not-present"]
        namespace = "{{.Release.Namespace}}"
        image = "mcr.microsoft.com/windows:ltsc2019"
        helper_image = "registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-${CI_RUNNER_REVISION}-servercore1809"
        privileged = false
      [runners.kubernetes.node_selector]
        "kubernetes.io/os" = "windows"
        "kubernetes.io/arch" = "amd64"
        "node.kubernetes.io/windows-build" = "10.0.17763"
nodeSelector:
  kubernetes.io/os: linux

Possible fixes

It appears this may be a result of https://github.com/git-for-windows/git/issues/4467 and likely needs to be addressed upstream.

Two workarounds have been identified at this time:

  1. Configure http.sslBackend to use openssl

Adding pre_get_sources_script as below to the [[runners]] configuration:

    [[runners]]
      executor = "kubernetes"
      shell = "powershell"
      environment = [ "FF_USE_POWERSHELL_PATH_RESOLVER=1" ]
      pre_get_sources_script = "git config --global http.sslBackend openssl"
  1. Use GIT_SSL_NO_VERIFY:
    [[runners]]
      executor = "kubernetes"
      shell = "powershell"
      environment = [ "FF_USE_POWERSHELL_PATH_RESOLVER=1", "GIT_SSL_NO_VERIFY=1" ]

Another likely solution would be to include a working CRL in the cert, this has not been attempted.

Edited by Chris Stone