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
- Configure GitLab to use a self-signed certificate, such as Option 4 in the installation documentation.
- 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:
- Configure
http.sslBackend
to useopenssl
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"
- 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.