Git-ის HTTPS პროქსის შეიძლება დასჭირდეს საკუთარი კლიენტის სერტიფიკატი

კონფიგურირდით პროქსის TLS CA, კლიენტის სერტიფიკატი და პირადი გასაღები ცალკე რეპოზიტორის TLS და HTTP შესვლის პარამეტრებისგან.

ზოგიერთი HTTPS გადამისამართებადი პროქსი ითხოვს კლიენტის სერტიფიკატს TLS კავშირის დროს Git-იდან პროქსიმდე. ეს არის ცალკე აუტენტიფიკაციის გაცვლა რეპოზიტორიში შესვლისგან.

PEM ფაილების გამოყენებადი თავსებადი Git/libcurl TLS backend-ისთვის შესაბამის კონფიგურაციას ასეთი ფორმა აქვს:

[http]
    proxy = https://proxy.example:8443
    proxySSLCAInfo = /secure/proxy-ca.pem
    proxySSLCert = /secure/proxy-client.pem
    proxySSLKey = /secure/proxy-client.key
    proxySSLCertPasswordProtected = true

გამოიყენეთ პროქსის TLS მოწყობისთვის მოწოდებული ფაქტობრივი ფაილები. გამოიყენეთ კონფიგურაცია განზრახული Git არეალში; რეპოზიტორიის ლოკალური კონფიგურაცია შეიძლება ეს გზა მხოლოდ იმ სამუშაო ასლზე შემოფარგლოს.

პარამეტრიროლი
proxySSLCAInfoCA პაკეტი, რომელიც გამოიყენება HTTPS პროქსის შესამოწმებლად
proxySSLCertკლიენტის სერტიფიკატი, რომელიც წარედგინება ამ პროქსის
proxySSLKeyპირადი გასაღები, რომელიც შეესაბამება კლიენტის სერტიფიკატს
proxySSLCertPasswordProtectedრთავს Git-ის პაროლის მოთხოვნას დაცული პროქსის სერტიფიკატისა და გასაღების მასალისთვის

https:// პროქსის URL აუცილებელია ამ TLS გაცვლისთვის. ჩვეულებრივი HTTP პროქსი, რომელიც CONNECT-ს გადააქვს HTTPS რეპოზიტორიაზე, ამით არ ასრულებს TLS კლიენტის სერტიფიკატის აუტენტიფიკაციას საკუთარ მსმენელზე.

რეპოზიტორიის სერტიფიკატების ნდობას და ნებისმიერ რეპოზიტორიის კლიენტის სერტიფიკატს აქვს საკუთარი ssl კონფიგურაცია. ასევე, HTTP პროქსის გამოწვევა Proxy-Authenticate-ით სხვა აუტენტიფიკაციის მექანიზმია.

ამ მოწყობის მოვლისას შეამოწმეთ დაკავშირებული libcurl ვერსია, TLS backend და მხარდაჭერილი სერტიფიკატის ფორმატი. PEM სერტიფიკატამდე მიმავალი გზა არ არის გადატანადი შემცვლელი ყოველი პლატფორმის სერტიფიკატების საცავის ინტერფეისისთვის.

დაკავშირებული სტატიები