Since version 0.7.0 the GitLab Runner allows you to configure certificates that are used to verify TLS peer when connecting to the GitLab server.
This allows to solve the
x509: certificate signed by unknown authority problem when registering runner.
GitLab Runner provides these options:
Default: GitLab Runner reads system certificate store and verifies the GitLab server against the CA’s stored in system.
GitLab Runner reads the PEM (DER format is not supported) certificate from predefined file:
/etc/gitlab-runner/certs/hostname.crton *nix systems when GitLab Runner is executed as root.
~/.gitlab-runner/certs/hostname.crton *nix systems when GitLab Runner is executed as non-root.
./certs/hostname.crton other systems.
If the address of your server is:
https://my.gitlab.server.com:8443/. Create the certificate file at:
Note: You may need to concatenate the intermediate and server certificate for the chain to be properly identified.
Note: Running GitLab Runner as a service on Windows does not recognize certificates in
./certs/hostname.crt. Use Option 3 instead.
GitLab Runner exposes
tls-ca-fileoption during registration (
gitlab-runner register --tls-ca-file=/path) and in
[[runners]]section. This allows you to specify a custom file with certificates. This file will be read every time when the runner tries to access the GitLab server.
The runner injects missing certificates to build CA chain to build containers.
This allows the
git clone and
artifacts to work with servers that do not use publicly trusted certificates.
This approach is secure, but makes the runner a single point of trust.