git und https scheint sich hier zur „ne­ve­r­en­ding story“ zu mau­sern :-) Trotz­dem muß ich zu die­sem Thema noch­mals drin­gend etwas los­wer­den. Si­tua­ti­on: Ser­ver ist ein­ge­rich­tet, be­nutzt aber ent­we­der ein selbst­si­gnier­tes Zer­ti­fi­kat oder von einer CA, die nicht „all­ge­mein ver­brei­tet“ ist (Fir­men-CA, CA­cert, etc.). Folge: Git mel­det

error: SSL certificate problem: self signed certificate in certificate chain while accessing https://...
fatal: HTTP request failed

Klar, woher soll git auch das Zer­ti­fi­kat ken­nen… wirft man die Mel­dung in Goog­le, lan­det man bei Emp­feh­lun­gen wie die­ser hier auf stack­over­flow: Per Um­ge­bungs­va­ria­ble GIT_SSL_NO_VERIFY=true oder git-Kon­fi­gu­ra­ti­on git config --global http.sslVerify false am bes­ten gleich glo­bal die Über­prü­fung ab­schal­ten, dann gibt’s keine ner­vi­gen Feh­ler­mel­dun­gen mehr… JESUS H. CHRIST, DON’T DO THAT!

Hin­ter­grund

(Wer’s eilig hat, kann zum nächs­ten Ab­schnitt sprin­gen)

Wer eine der obi­gen Lö­sun­gen nutzt, ist zwar die läs­ti­ge Mel­dung los, öff­net einem An­grei­fer aber die Mög­lich­keit, sich selbst als der Ser­ver aus­zu­ge­ben - und so alle Daten im Klar­text mit­zu­le­sen. Genau das soll die Prü­fung des Zer­ti­fi­kats ver­hin­dern, schal­tet man diese aus, ist man sol­chen An­grif­fen schutz­los aus­ge­lie­fert. Das ist das ex­ak­te äqui­va­lent zur „nicht ver­trau­ens­wür­di­gen Ver­bin­dung“, die der Web­brow­ser bei ma­chen Sei­ten mel­det… wenn diese Seite zu­fäl­lig ge­ra­de die der ei­ge­nen Bank ist, soll­ten ja auch die Alarm­glo­cken schril­len (und man nicht nur ein­fach auf „jaja, ok“ kli­cken).

Wie man’s rich­tig macht

Zu­erst be­nö­tigt man das Zer­ti­fi­kat der CA, wel­che der Ser­ver be­nutzt – aus einer ver­trau­ens­wür­di­gen Quel­le. Das be­deu­tet (wenn man’s ganz genau ma­chen will) ein Te­le­fo­nat mit dem Ad­mi­nis­tra­tor der Ma­schi­ne. Al­ter­na­tiv kann man sich das Zer­ti­fi­kat ein­mal(!) vom Ser­ver holen und spei­chern:

openssl s_client -connect mein.server:443

Den Zer­ti­fi­kats­block ko­piert man sich in eine se­pa­ra­te Datei. Aus Si­cher­heits­sicht gibt es nun zwei Si­tua­tio­nen: Ent­we­der man hat tat­säch­lich das Or­gi­nal­zer­ti­fi­kat er­wischt – Glück ge­habt, oder aber man bekam es be­reits von einem An­grei­fer: Das be­deu­tet, daß man eine Feh­ler­mel­dung be­kom­men wird, wenn der An­grei­fer ein­mal ab­we­send ist (und man eine di­rek­te Ser­ver­ver­bin­dung be­kommt). Ob man diese Un­si­cher­heit ris­kie­ren will oder den auf­wen­di­ge­ren ers­ten Weg be­schrei­tet, muß jeder selbst ent­schei­den.

Nun muß man git das Zer­ti­fi­kat noch be­kannt ma­chen. Einen neuen Clon legt man mit fol­gen­dem Be­fehl an:

GIT_SSL_CAINFO=/pfad/zum/zertifikat.crt git clone https://repo.url

In einem be­ste­hen­den Clon kon­fi­gu­riert man das zu­ge­hö­ri­ge Ser­ver­zer­ti­fi­kat fol­gen­der­ma­ßen:

git config http.sslCAinfo /pfad/zum/zertifikat.crt

Bot­tom line: Kaum Mehr­auf­wand, und dafür eine sau­be­re Prü­fung der Ge­gen­sei­te. Oh, und tut mir bitte den Ge­fal­len und ratet die ent­spre­chen­den „Tips“ auf stack­over­flow ‘run­ter…