0

My company has a certificate for https://data.ddl.at, which has, among others, a SAN (Subject Alternative Name) for gitlab.ddl.at. This Gitlab-Server is internal, and the domain name is only resolved by our internal DNS-Server. For reference, there is also the SAN https://sicher.ddl.at, which is public, and is valid in a browser.

I have configured this certificate on the Gitlab-Server, and when I go to gitlab.ddl.at, the certificate is validated by the browser and considered valid.

The problems arise, once I try to use a Gitlab-Runner. I have one installed and registered on another machine, and after having some problems at first, I got it to connect to the main instance, but the jobs still cannot check-out submodules, the runner is getting server certificate verification failed.

Now here for what I believe to be a root symptom of the problem: If I run openssl s_client -connect data.ddl.at:443, I get:

CONNECTED(00000005)
depth=2 OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Extended Validation CA - SHA256 - G3
verify return:1
depth=0 businessCategory = Private Organization, serialNumber = FN 374566h, jurisdictionC = AT, jurisdictionL = Wels, jurisdictionST = Oberoesterreich, C = AT, ST = Oberoesterreich, L = Ruestorf, street = Erwin Greiner-Str. 4, OU = GIS, O = DDL GmbH, CN = data.ddl.at
verify return:1
---
Certificate chain
 0 s:businessCategory = Private Organization, serialNumber = FN 374566h, jurisdictionC = AT, jurisdictionL = Wels, jurisdictionST = Oberoesterreich, C = AT, ST = Oberoesterreich, L = Ruestorf, street = Erwin Greiner-Str. 4, OU = GIS, O = DDL GmbH, CN = data.ddl.at
   i:C = BE, O = GlobalSign nv-sa, CN = GlobalSign Extended Validation CA - SHA256 - G3
 1 s:C = BE, O = GlobalSign nv-sa, CN = GlobalSign Extended Validation CA - SHA256 - G3
   i:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
---
Server certificate
[...]

And at the end: Verify return code: 0 (ok)

Now when I run openssl s_client -connect gitlab.ddl.at:443, I get:

CONNECTED(00000005)
depth=0 businessCategory = Private Organization, serialNumber = 374566h, jurisdictionC = AT, jurisdictionL = Wels, jurisdictionST = Oberoesterreich, C = AT, ST = Oberoesterreich, L = Ruestorf, street = Erwin Greiner-Stra\C3\9Fe 4, OU = GIS, O = DDL GmbH, CN = data.ddl.at
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 businessCategory = Private Organization, serialNumber = 374566h, jurisdictionC = AT, jurisdictionL = Wels, jurisdictionST = Oberoesterreich, C = AT, ST = Oberoesterreich, L = Ruestorf, street = Erwin Greiner-Stra\C3\9Fe 4, OU = GIS, O = DDL GmbH, CN = data.ddl.at
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:businessCategory = Private Organization, serialNumber = 374566h, jurisdictionC = AT, jurisdictionL = Wels, jurisdictionST = Oberoesterreich, C = AT, ST = Oberoesterreich, L = Ruestorf, street = Erwin Greiner-Stra\C3\9Fe 4, OU = GIS, O = DDL GmbH, CN = data.ddl.at
   i:C = BE, O = GlobalSign nv-sa, CN = GlobalSign Extended Validation CA - SHA256 - G3
---
Server certificate
[...]

With the first error being unable to get local issuer certificate.

I have also tried this with the publicly accessible sicher.ddl.at, with the same error as gitlab.ddl.at.

The certificate it gets is for data.ddl.at, but it has the SAN gitlab.ddl.at, shouldn't this make it valid? What am I doing wrong?

Pipelynx
  • 3
  • 2

1 Answers1

0

It looks like the server at gitlab.ddl.at is missing the issuer certificate.

If the client and server do not have the proper root and intermediate certificates then you can run into validation errors.

I always make sure to install the full chain on the server to make sure all clients can get all certificates in the chain.

You have a couple of options.

  1. Export the full chain from data.ddl.at and then import it to gitlab.ddl.at.

  2. Use a tool like OpenSSL to combine the chain into one certificate then install to gitlab.ddl.at

  3. Install all the certificates in the chain to the server.

AutoGnome
  • 161
  • 6
  • Option number 1 was my solution, once I had the entire certificate chain in the CRT-File and restarted the server, the error was gone. Thanks a lot @AutoGnome! – Pipelynx Aug 16 '21 at 07:26