Πώς να διορθώσετε το πρόβλημα πιστοποιητικού SSL: Unable to Get Local Issuer Certificate στο Git

Δεν υπάρχει καμία ουσιαστική αλλαγή το 2026 που να καθιστά την παλιά παράκαμψη «απενεργοποίηση επαλήθευσης SSL» μια καλή λύση. Η τρέχουσα τεκμηρίωση του Git εξακολουθεί να ορίζει ως προεπιλογή την τιμή http.sslVerify σε true, και το Git εξακολουθεί να υποστηρίζει τόσο την εμπιστοσύνη CA βάσει αρχείων όσο και επιλέξιμα backends TLS όπως το OpenSSL και το Schannel. Η μόνιμη λύση είναι να κάνετε το Git να εμπιστεύεται την σωστή αρχή πιστοποίησης (Certificate Authority) ή να επισκευάσετε μια ελλιπή αλυσίδα πιστοποιητικών διακομιστή, και όχι να απενεργοποιήσετε την επαλήθευση.

Το σφάλμα SSL certificate problem: unable to get local issuer certificate σημαίνει ότι η βιβλιοθήκη TLS που χρησιμοποιεί το Git δεν μπόρεσε να δημιουργήσει μια έγκυρη αλυσίδα πιστοποιητικών από το πιστοποιητικό του διακομιστή έως μια αρχή πιστοποίησης στην οποία εμπιστεύεται. Αυτό μπορεί να συμβεί επειδή η τοπική αποθήκη CA δεν περιέχει την εκδίδουσα CA, ένας εταιρικός proxy επιθεώρησης HTTPS υπογράφει εκ νέου την κίνηση με μια εσωτερική CA, το Git διαβάζει το λανθασμένο bundle CA, ή ένας αυτοδιαχειριζόμενος διακομιστής Git δεν παρουσιάζει τα απαιτούμενα ενδιάμεσα πιστοποιητικά.

Μια τυπική αποτυχία HTTPS του Git: η απομακρυσμένη τοποθεσία είναι προσβάσιμη, αλλά η επαλήθευση της αλυσίδας πιστοποιητικών δεν μπορεί να βρει μια έμπιστη αρχή έκδοσης.

Ξεκινήστε με την ασφαλέστερη απάντηση

Χρησιμοποιήστε αυτήν τη σειρά:

1. Επιβεβαιώστε ποιες ρυθμίσεις SSL του Git και ποιο backend TLS είναι ενεργές.
2. Αποφασίστε αν η έλλειψη εμπιστοσύνης ανήκει στην αποθήκη εμπιστοσύνης του λειτουργικού συστήματος ή σε ένα bundle CA του Git.
3. Εάν πολλοί πελάτες αποτυγχάνουν εναντίον του ίδιου αυτοφιλοξενούμενου διακομιστή, επισκευάστε την αλυσίδα πιστοποιητικών του διακομιστή αντί να επιδιορθώνετε κάθε πελάτη ξεχωριστά.
4. Επαναλάβετε τη δοκιμή με ενεργή την επαλήθευση SSL και αφαιρέστε οποιαδήποτε προσωρινή ή παλαιά ρύθμιση παράκαμψης.

Η τρέχουσα τεκμηρίωση git-config του Git ορίζει τα http.sslVerify, http.sslCAInfo, http.sslCAPath, http.sslBackend, και τη συμπεριφορά ειδική για το Schannel που χρησιμοποιείται στα Windows. Η προεπιλογή για την επαλήθευση πιστοποιητικών παραμένει ενεργοποιημένη.

Η αξιόπιστη επισκευή είναι η αποκατάσταση μιας έγκυρης αλυσίδας εμπιστοσύνης αντί η καταστολή του ελέγχου πιστοποιητικών.

Βήμα 1: Βρείτε τι χρησιμοποιεί πραγματικά το Git

Πριν εγκαταστήσετε πιστοποιητικά ή επεξεργαστείτε τη διαμόρφωση, επιθεωρήστε τις τιμές και από πού προέρχονται:

git --version
git config --show-origin --get http.sslVerify
git config --show-origin --get http.sslCAInfo
git config --show-origin --get http.sslBackend
git config --show-origin --get http.proxy
git config --show-origin --get http.proxySSLCAInfo

Εάν μια εντολή δεν εκτυπώνει τίποτα, αυτή η επιλογή μπορεί απλώς να χρησιμοποιεί την προεπιλογή του Git ή του libcurl. Η επιλογή --show-origin είναι σημαντική επειδή μια τιμή μπορεί να προέρχεται από αρχεία διαμόρφωσης συστήματος, global, τοπικού αποθετηρίου ή συμπεριλαμβανομένων αρχείων. Η διόρθωση του λάθους επιπέδου μπορεί να αφήσει την ενεργή ρύθμιση αμετάβλητη.

Ελέγξτε επίσης την απομακρυσμένη τοποθεσία με την οποία επικοινωνείτε πραγματικά:

git remote -v
git ls-remote https://git.example.com/team/repo.git

Εάν το Git αποτυγχάνει μόνο για έναν εταιρικό ή ιδιωτικό host ενώ οι δημόσιες τοποθεσίες HTTPS λειτουργούν, το πρόβλημα είναι πιθανότατα εμπιστοσύνη συγκεκριμένη για τον host ή διαμόρφωση διακομιστή. Εάν το Git αποτυγχάνει για πολλές άσχετες απομακρυσμένες τοποθεσίες HTTPS, επιθεωρήστε πρώτα την τοπική εγκατάσταση του Git, τη διαδρομή του bundle CA, τον proxy και τη διαμόρφωση εμπιστοσύνης του συστήματος.

Μην κάνετε αυτήν την εντολή την πρώτη σας

git config --global http.sslVerify false

Αυτό απενεργοποιεί την επαλήθευση πιστοποιητικών διακομιστή για αιτήματα HTTPS του Git σε επίπεδο global χρήστη. Μπορεί να κάνει το σφάλμα να εξαφανιστεί, αφαιρώντας ταυτόχρονα την προστασία που επαληθεύει ότι επικοινωνείτε με τον επιθυμητό διακομιστή. Το Git τεκμηριώνει ότι η επαλήθευση είναι ενεργοποιημένη από προεπιλογή για έναν λόγο.

Εάν ανακαλύψετε μια παλιά global παράκαμψη που δεν απαιτείται πλέον, επαναφέρετε την προεπιλεγμένη συμπεριφορά:

git config --global --unset http.sslVerify

ή ορίστε ρητά:

git config --global http.sslVerify true

Βήμα 2: Στα Windows, επιλέξτε μεταξύ της αποθήκης πιστοποιητικών των Windows και ενός bundle CA PEM

Οι προγραμματιστές στα Windows συναντούν συχνά αυτό το σφάλμα όταν ένα πρόγραμμα περιήγησης λειτουργεί αλλά το Git όχι. Αυτό δεν σημαίνει απαραίτητα ότι ο διακομιστής είναι χαλασμένος. Το πρόγραμμα περιήγησης μπορεί να εμπιστεύεται μια εταιρική ριζική πιστοποίηση εγκατεστημένη στα Windows, ενώ το Git διαμορφωμένο με backend τύπου OpenSSL μπορεί να χρησιμοποιεί ένα ξεχωριστό bundle CA.

Το Git υποστηρίζει τιμές http.sslBackend όπως openssl και schannel. Η επίσημη τεκμηρίωση πιστοποιητικών TLS του curl εξηγεί ότι το Schannel χρησιμοποιεί από προεπιλογή την εγγενή αποθήκη CA των Windows.

Επιλογή Α: Χρησιμοποιήστε το Schannel όταν τα Windows έχουν ήδη την έμπιστη εταιρική CA

git config --global http.sslBackend schannel

Αυτή είναι συχνά μια καλή επιλογή για σταθμούς εργασίας μόνο Windows που διαχειρίζεται ένας οργανισμός που διανέμει έμπιστες ριζικές και ενδιάμεσες πιστοποιήσεις μέσω πολιτικής των Windows. Επιτρέπει στο Git να βασίζεται στο ίδιο σύστημα εμπιστοσύνης πιστοποιητικών των Windows που μπορούν να χρησιμοποιήσουν άλλες εγγενείς εφαρμογές.

Υπάρχει ένα αντάλλαγμα: η αλλαγή του backend αλλάζει τη συμπεριφορά πιστοποιητικών HTTPS του Git global για αυτόν τον χρήστη. Εάν ο οργανισμός σας διαχειρίζεται σκόπιμα ένα αφιερωμένο bundle PEM για το Git ή την αυτοματοποίηση, η παραμονή με το OpenSSL μπορεί να είναι πιο προβλέψιμη.

Η τρέχουσα τεκμηρίωση του Git σημειώνει επίσης μια λεπτή συμπεριφορά του Schannel: όταν το Schannel επιλέγεται μέσω http.sslBackend, το Git συνήθως αποφεύγει να εφαρμόσει το http.sslCAInfo επειδή ένα παρεχόμενο bundle CA θα μπορούσε να παρακάμψει την Αποθήκη Πιστοποιητικών των Windows. Η ρύθμιση http.schannelUseSSLCAInfo υπάρχει για περιβάλλοντα που θέλουν σκόπιμα αυτήν τη συμπεριφορά.

Επιλογή Β: Κρατήστε το OpenSSL και δείξτε στο Git ένα εγκεκριμένο bundle CA

Εάν ο οργανισμός σας σας παρέχει ένα bundle PEM που περιέχει τις απαιτούμενες εσωτερικές ριζικές και ενδιάμεσες πιστοποιήσεις, διαμορφώστε το Git να χρησιμοποιεί αυτό το αρχείο:

git config --global http.sslCAInfo "C:/certs/company-ca-bundle.pem"

Το Git ορίζει το http.sslCAInfo ως το αρχείο που περιέχει πιστοποιητικά που χρησιμοποιούνται για την επαλήθευση του peer. Μπορείτε επίσης να περιορίσετε τη διαμόρφωση HTTP σε μια ταιριάζουσα URL αντί να αλλάξετε κάθε προορισμό HTTPS. Η διαμόρφωση http.<url>.* του Git υποστηρίζει αντιστοίχιση συγκεκριμένη για URL με βάση το σχήμα, τον host, τη θύρα και τη διαδρομή.

Για παράδειγμα:

git config --global http."https://git.example.com/".sslCAInfo "C:/certs/company-ca-bundle.pem"

Αυτή η στενότερη ρύθμιση είναι χρήσιμη όταν μόνο ένας εσωτερικός διακομιστής Git χρειάζεται μια ιδιωτική CA, ενώ οι δημόσιοι hosts Git πρέπει να συνεχίσουν να χρησιμοποιούν το κανονικό bundle εμπιστοσύνης.

Βήμα 3: Σε macOS, Linux, CI και containers, διορθώστε την πηγή CA που χρησιμοποιεί πραγματικά η διαδικασία

Η αρχή είναι η ίδια εκτός Windows: η διαδικασία Git πρέπει να έχει πρόσβαση στο πιστοποιητικό CA που εξέδωσε το πιστοποιητικό του διακομιστή ή του proxy. Οι ακριβείς εντολές αποθήκης εμπιστοσύνης του συστήματος διαφέρουν ανά λειτουργικό σύστημα και διανομή Linux, οπότε χρησιμοποιήστε τον επίσημο μηχανισμό διαχείρισης πιστοποιητικών της πλατφόρμας ή ένα ρητό bundle CA του Git που παρέχεται από τον διαχειριστή σας.

Το Git πρέπει να είναι σε θέση να συνδέσει το παρουσιαζόμενο πιστοποιητικό διακομιστή μέσω των ενδιάμεσων εκδοτών του με μια τοπικά έμπιστη CA.

Για μια ελεγχόμενη εργασία CI ή container όπου δεν θέλετε να τροποποιήσετε την global αποθήκη εμπιστοσύνης του host, ένα bundle CA μπορεί να είναι ρητό:

git config --global http.sslCAInfo /etc/company/git-ca-bundle.pem

ή, για μια μεμονωμένη διαδικασία, το Git αναγνωρίζει επίσης τη μεταβλητή περιβάλλοντος GIT_SSL_CAINFO. Η τρέχουσα τεκμηρίωση του Git δηλώνει ότι αυτή η μεταβλητή περιβάλλοντος μπορεί να παρακάμψει το http.sslCAInfo.

Μην αντιγράψετε ένα τυχαίο αρχείο cacert.pem από ένα φόρουμ. Εάν το πιστοποιητικό που λείπει είναι μια εταιρική CA, αποκτήστε το από την ομάδα IT ή PKI σας. Εάν η απομακρυσμένη τοποθεσία είναι μια δημόσια υπηρεσία και το bundle CA σας είναι απλώς παλιό, ενημερώστε το λειτουργικό σας σύστημα, τη διανομή Git, τη base image του container ή το πακέτο έμπιστων CA μέσω του κανονικού καναλιού ενημέρωσης.

Η εταιρική επιθεώρηση TLS είναι μια ειδική περίπτωση

Ορισμένοι enterprise proxies επιθεωρούν το HTTPS και παρουσιάζουν ένα αντικαταστάσιμο πιστοποιητικό υπογεγραμμένο από μια εσωτερική εταιρική CA. Σε αυτήν την περίπτωση, το πρόγραμμα περιήγησης μπορεί να πετύχει επειδή η εταιρική CA είναι εγκατεστημένη στην αποθήκη εμπιστοσύνης του OS, ενώ το ξεχωριστό bundle CA του Git δεν την περιέχει.

Η σωστή διόρθωση είναι να εμπιστευτείτε την CA του οργανισμού μέσω της κατάλληλης αποθήκης εμπιστοσύνης ή bundle του Git. Μην εξάγετε το τρέχον leaf πιστοποιητικό και μην το εμπιστεύεστε μόνιμα ως υποκατάστατο της εκδίδουσας εταιρικής CA.

Διακρίνετε επίσης δύο ξεχωριστές περιπτώσεις proxy:

• Παρεμβολή TLS στη σύνδεση διακομιστή Git: η εταιρική CA που υπογράφει το αντικαταστάσιμο πιστοποιητικό διακομιστή πρέπει να είναι έμπιστη μέσω της κανονικής διαδρομής πιστοποιητικού διακομιστή, όπως το Windows Schannel ή το http.sslCAInfo.
• Ένας HTTPS proxy του οποίου η δική του σύνδεση proxy χρησιμοποιεί TLS: Το Git παρέχει το http.proxySSLCAInfo συγκεκριμένα για το bundle CA που χρησιμοποιείται για την επαλήθευση αυτής της σύνδεσης HTTPS proxy.

Το Git τεκμηριώνει τα http.proxy και http.proxySSLCAInfo ξεχωριστά, οπότε χρησιμοποιήστε τη ρύθμιση που ταιριάζει στη σύνδεση που αποτυγχάνει.

Βήμα 4: Εάν η αλυσίδα του διακομιστή είναι ελλιπής, διορθώστε τον διακομιστή όταν μπορείτε

Εάν πολλοί χρήστες ή καινούργιες μηχανές αποτυγχάνουν εναντίον του ίδιου αυτοφιλοξενούμενου διακομιστή Git, το πρόβλημα μπορεί να είναι πλευρά διακομιστή και όχι μια συλλογή χαλασμένων πελατών. Ο διακομιστής πρέπει να παρουσιάζει την αλυσίδα πιστοποιητικών που απαιτείται για τους πελάτες να συνδέσουν το leaf πιστοποιητικό με μια έμπιστη αρχή έκδοσης.

Όταν πολλοί πελάτες αποτυγχάνουν εναντίον ενός ιδιωτικού host Git, ελέγξτε την αλυσίδα του διακομιστή και τη διαδρομή του proxy πριν διανείμετε παρακάμψεις πλευράς πελάτη.

Η επίσημη τεκμηρίωση αντιμετώπισης προβλημάτων SSL του GitLab περιγράφει συγκεκριμένα το unable to get local issuer certificate ως μια περίπτωση όπου ο πελάτης δεν μπορεί να αποκτήσει τον απαιτούμενο εκδότη και συνιστά είτε την εμπιστοσύνη της κατάλληλης CA στον πελάτη είτε τη διόρθωση του διακομιστή για να παρουσιάζει μια πλήρη αλυσίδα πιστοποιητικών.

Εάν διαχειρίζεστε τον διακομιστή, επισκευάστε το διαμορφωμένο πλήρες αλυσίδα πιστοποιητικό και επαναλάβετε τη δοκιμή από έναν καθαρό πελάτη. Αυτό είναι προτιμότερο από το να ζητάτε από κάθε προγραμματιστή να προσθέτει ad hoc εξαιρέσεις.

Επαληθεύστε τη διόρθωση χωρίς να εξασθενίσετε το TLS

Αφού διορθωθεί η διαμόρφωση εμπιστοσύνης, επαναλάβετε την ίδια λειτουργία Git:

git ls-remote https://git.example.com/team/repo.git

Εάν αυτό πετύχει, δοκιμάστε ξανά το αρχικό clone, fetch, pull ή push.

Στη συνέχεια, επιθεωρήστε την τελική διαμόρφωση σχετική με την ασφάλεια:

git config --show-origin --get http.sslVerify
git config --show-origin --get http.sslBackend
git config --show-origin --get http.sslCAInfo

Η αναμενόμενη κατάσταση είναι ότι η επαλήθευση πιστοποιητικών παραμένει ενεργοποιημένη και το Git μπορεί να δημιουργήσει μια έγκυρη αλυσίδα μέσω της επιθυμητής πηγής εμπιστοσύνης.

Ποια διόρθωση ταιριάζει στην περίπτωσή σας;

Τι γίνεται με την εναλλαγή της απομακρυσμένης τοποθεσίας Git σε SSH;

Το SSH μπορεί να είναι μια έγκυρη εναλλακτική μεταφορά εάν η υπηρεσία φιλοξενίας Git σας την υποστηρίζει και ο οργανισμός σας την επιτρέπει. Η αλλαγή από μια απομακρυσμένη τοποθεσία HTTPS σε μια απομακρυσμένη τοποθεσία SSH αποφεύγει εντελώς την αλυσίδα πιστοποιητικών HTTPS, αλλά δεν επισκευάζει το αρχικό πρόβλημα εμπιστοσύνης TLS. Το SSH έχει το δικό του μοντέλο επαλήθευσης host-key και διαχείρισης διαπιστευτηρίων.

Χρησιμοποιήστε το SSH επειδή ταιριάζει στον σχεδιασμό αυθεντικοποίησης και ανάπτυξής σας—όχι απλώς για να κρύψετε ένα σφάλμα διαμόρφωσης πιστοποιητικών που άλλα εργαλεία HTTPS θα συνεχίσουν να συναντούν.

Συνηθισμένα λάθη που πρέπει να αποφύγετε

• Απενεργοποίηση της επαλήθευσης SSL global. Αυτό αφαιρεί την επαλήθευση πιστοποιητικών διακομιστή για μελλοντικές συνδέσεις HTTPS του Git.
• Εμπιστοσύνη του leaf πιστοποιητικού αντί της εκδίδουσας CA. Τα leaf πιστοποιητικά λήγουν και περιστρέφονται· η εμπιστοσύνη πρέπει συνήθως να αγκυροβολείται στην εγκεκριμένη αλυσίδα CA.
• Χειροκίνητη επεξεργασία του bundle CA του Git χωρίς τεκμηρίωση. Μια αναβάθμιση μπορεί να αντικαταστήσει το αρχείο, και η αλλαγή μπορεί να είναι αδύνατο να αναπαραχθεί από συναδέλφους ή CI.
• Υποθέτοντας ότι η επιτυχία του προγράμματος περιήγησης αποδεικνύει ότι το Git έχει την ίδια πηγή εμπιστοσύνης. Το Git μπορεί να χρησιμοποιεί OpenSSL και ένα ξεχωριστό bundle PEM ενώ το πρόγραμμα περιήγησης χρησιμοποιεί την αποθήκη του OS.
• Χρήση του http.proxySSLCAInfo για τη λάθος σύνδεση. Αυτή η ρύθμιση είναι για την επαλήθευση ενός HTTPS proxy, όχι για μια γενική αντικατάσταση της διαμόρφωσης CA του διακομιστή προέλευσης.
• Επιδιόρθωση κάθε σταθμού εργασίας προγραμματιστή όταν ο διακομιστής Git στέλνει μια ελλιπή αλυσίδα. Διορθώστε τον διακομιστή όταν τον ελέγχετε.

Το συμπέρασμα

Το σφάλμα Git SSL certificate problem: unable to get local issuer certificate είναι ένα πρόβλημα αλυσίδας εμπιστοσύνης, όχι ένα πρόβλημα διαπιστευτηρίου αυθεντικοποίησης και όχι κάτι που πρέπει κανονικά να λύνεται απενεργοποιώντας την επαλήθευση πιστοποιητικών. Βρείτε αν το Git χρησιμοποιεί OpenSSL, Schannel, ένα προσαρμοσμένο bundle CA ή έναν HTTPS proxy· στη συνέχεια τοποθετήστε την εγκεκριμένη εκδίδουσα CA στην πηγή εμπιστοσύνης που χρησιμοποιεί πραγματικά το Git.

Στα Windows, το Schannel είναι μια πρακτική επιλογή όταν η εταιρική CA διαχειρίζεται ήδη στην Αποθήκη Πιστοποιητικών των Windows. Σε CI, containers ή περιβάλλοντα που χρειάζονται αναπαραγώγιμη εμπιστοσύνη βάσει αρχείων, το http.sslCAInfo είναι συχνά πιο σαφές. Και όταν πολλοί πελάτες αποτυγχάνουν εναντίον μιας αυτοφιλοξενούμενης υπηρεσίας, επισκευάστε την αλυσίδα πιστοποιητικών του διακομιστή αντί να διανέμετε μη ασφαλείς παρακάμψεις.