☰

Zertifikat für Gitlab-Server ist ungültig für Subject Alternative Name

tag-icon • tag-icon ssl-certificate openssl gitlab subject-alternative-names
Zertifikat für Gitlab-Server ist ungültig für Subject Alternative Name

Mein Unternehmen verfügt über ein Zertifikat fürhttps://data.ddl.at, das unter anderem einen SAN (Subject Alternative Name) für hat gitlab.ddl.at. Dieser Gitlab-Server ist intern und der Domänenname wird nur von unserem internen DNS-Server aufgelöst. Als Referenz gibt es auch den SANhttps://sicher.ddl.at, das öffentlich ist und in einem Browser gültig ist.

Ich habe dieses Zertifikat auf dem Gitlab-Server konfiguriert und wenn ich auf gehe gitlab.ddl.at, wird das Zertifikat vom Browser validiert und als gültig betrachtet.

Die Probleme treten auf, wenn ich versuche, einen Gitlab-Runner zu verwenden. Ich habe einen auf einer anderen Maschine installiert und registriert, und nachdem es anfangs einige Probleme gab, konnte ich ihn mit der Hauptinstanz verbinden, aber die Jobs können immer noch keine Untermodule auschecken, der Runner bekommt server certificate verification failed.

Und hier nun das, was ich für das Grundsymptom des Problems halte: Wenn ich ausführe openssl s_client -connect data.ddl.at:443, erhalte ich:

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
[...]

Und am Ende:Verify return code: 0 (ok)

Wenn ich jetzt ausführe openssl s_client -connect gitlab.ddl.at:443, erhalte ich Folgendes:

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
[...]

Der erste Fehler ist unable to get local issuer certificate.

Ich habe dies auch mit dem öffentlich zugänglichen versucht sicher.ddl.at, mit demselben Fehler wie gitlab.ddl.at.

Das Zertifikat, das es erhält, ist für data.ddl.at, aber es hat den SAN gitlab.ddl.at. Sollte es dadurch nicht gültig sein? Was mache ich falsch?

Antwort1

Es sieht so aus, als ob auf dem Server gitlab.ddl.atdas Ausstellerzertifikat fehlt.

Wenn Client und Server nicht über die richtigen Stamm- und Zwischenzertifikate verfügen, können Validierungsfehler auftreten.

Ich stelle immer sicher, dass die vollständige Kette auf dem Server installiert wird, um sicherzustellen, dass alle Clients alle Zertifikate in der Kette erhalten können.

Sie haben mehrere Möglichkeiten.

  1. Exportieren Sie die vollständige Kette aus data.ddl.atund importieren Sie sie dann nach gitlab.ddl.at.

  2. Verwenden Sie ein Tool wie OpenSSL, um die Kette in einem Zertifikat zu kombinieren, und installieren Sie es dann ingitlab.ddl.at

  3. Installieren Sie alle Zertifikate in der Kette auf dem Server.

verwandte Informationen