Nginx Question posted in
The official documentation can be found here.

self-hosted Gitlab runner register failed x509 certificate signed by unknown authority on GKE with helm install – Nginx

I installed Gitlab(version 13.7.1-ee) on GKE with using helm.

and as prerequisites, because of Firewall rule, and having no controllable domain, I cannot use cert-manager’s valid certificate. Then I want to use self-signed cert or wildcard-cert supported by gitlab.

Gitlab-runner showed error when running.

status=couldn’t execute POST against https://gitlab.xxx.xxx.xxx.xip.io/api/v4/runners: Post https://gitlab.xxx.xxx.xxx.xip.io/api/v4/runners: x509: certificate signed by unknown authority

I tried several ways like,

a. setting envVars

values.yaml

gitlab-runner:
  envVars:
    - name: CI_SERVER_TLS_CA_FILE
      value: /home/gitlab-runner/.gitlab-runner/certs/gitlab.xxx.xxx.xxx.xxx.xip.io.crt
    - name: CONFIG_FILE
      value: /home/gitlab-runner/.gitlab-runner/config.toml

b. use same certificate on gitlab.web-service & gitlab-runner

made self-signed, made on my local machine using

openssl genrsa command

values.yaml

gitlab:
  webservice:
    ingress:
      tls:
        secretName: selfsigned-cert-tls

gitlab-runner:
  runners:
    certsSecretName: selfsigned-cert-tls

c. create self-signed certificate using cert-manager on GKE and use that cert.

use external cert-manager, and external nginx-ingress-controller (install both by myself using helm) and set

ingress

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: self-ingress
  namespace: gitlab
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/issuer: "selfsigned-issuer"
spec:
  tls:
    - hosts:
      - gitlab.xxx.xxx.xxx.xxx.xip.io
      secretName: selfsigned-cert-tls
  rules:
   - host: gitlab.xxx.xxx.xxx.xxx.xip.io
    http:
      paths:
      - backend:
          serviceName: gitlab-webservice-default
          servicePort: 8181
        path: /
      - backend:
          serviceName: gitlab-webservice-default
          servicePort: 8080
        path: /admin/sidekiq

values.yaml

global:
  ingress:
    configureCertmanager: false

nginx-ingress:
  enabled:false

certmanager:
  install: false

d. using wildcard self signed cert made by gitlab, and use own self-signed cert for gitlab-runner

With this way, using Gitlab-runner is not recommended
https://docs.gitlab.com/charts/installation/tls.html#option-4-use-auto-generated-self-signed-wildcard-certificate

values.yaml

certmanager:
  install: false

  ingress:
    configureCertmanager: false

gitlab-runner:
  runners:
    certsSecretName: selfsigned-cert-tls

but all of those still showed error

x509: certificate signed by unknown authority
sometimes x509: certificate is valid for ingress.local and not valid for gitlab.xxx.xxx.xxx.xxx.xip.io

I totally got lost

  • How self-signed cert must be created on GKE ?
  • What secret must be set for gitlab-runner ?
  • Possibly I cannot use xip.io for self-signed-cert ?

I sincerely appreciate your help.

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    I fixed this issue, following an article.

    Install GitLab Enterprise on Konvoy

    So, using wildcard self signed cert made by gitlab, and get cert data from wildcard-tls-gitlab

    kubectl get secret gitlab-wildcard-tls 
 --template='{{ index .data "tls.crt" }}' | base64 -D > gitlab.crt

    kubectl create secret generic gitlab-runner-certs 
 --from-file=gitlab.xxx.xxx.xxx.xxx.xip.io.crt=xxx.xxx.xxx.xxx.xip.io.crt

    I can use gitlab-runner-certs as gitlab-runner secrets.

    and I noticed my value.yaml had mistake

    gitlab-runner:
  certsSecretName: gitlab-runner-certs # correct
  runners: 
    certsSecretName: gitlab-runner-certs # wrong

  2. 0

    I’ve had a similar issue in the past, and the configuration options for the CA File have never worked for me. What does work is telling the host that runs your gitlab-runner to trust that cert.

    You’ll likely need both the Root signing cert and the intermediate cert from GKE. I’ve never used GKE or the cert-manager you mentioned, so you’ll research how to get the two certs (or it might be just one if they merge them for you). If you get both separately, you’ll have to combine them by taking the text in one of them and putting it in the second (literal copy/paste).

    Once you have the file with the root and intermediate certificates, you can follow the directions for your OS for trusting it. This will depend on your OS, but for Centos I’ve followed the instructions here: https://manuals.gfi.com/en/kerio/connect/content/server-configuration/ssl-certificates/adding-trusted-root-certificates-to-the-server-1605.html. This works for any version of Centos (up to 8 so far), but I’m unsure about the directions for Ubuntu/Debian. https://manuals.gfi.com/en/kerio/connect/content/server-configuration/ssl-certificates/adding-trusted-root-certificates-to-the-server-1605.html

    If you’re using something other than Centos/Debian-Ubuntu, or the instructions above don’t work for Debian/Ubuntu, you’ll have to research how to trust the root cert.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search