Git کا HTTPS پراکسی اپنا کلائنٹ سرٹیفکیٹ مانگ سکتا ہے

پراکسی کا TLS CA، کلائنٹ سرٹیفکیٹ اور نجی کلید ریپوزٹری کی TLS اور HTTP لاگ اِن سیٹنگز سے الگ ترتیب دیں۔

کچھ HTTPS فارورڈ پراکسی Git سے پراکسی تک TLS کنکشن کے دوران کلائنٹ سرٹیفکیٹ طلب کرتی ہیں۔ یہ ریپوزٹری میں لاگ اِن ہونے سے الگ توثیقی تبادلہ ہے۔

PEM فائلیں استعمال کرنے والے موزوں Git/libcurl TLS بیک اینڈ کے لیے متعلقہ کنفیگریشن اس شکل میں ہے:

[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 دائرے میں لاگو کریں؛ ریپوزٹری سطح کی کنفیگریشن اس راستے کو اسی چیک آؤٹ تک محدود رکھ سکتی ہے۔

سیٹنگکردار
proxySSLCAInfoHTTPS پراکسی کی تصدیق کے لیے استعمال ہونے والا CA بنڈل
proxySSLCertاسی پراکسی کو پیش کیا جانے والا کلائنٹ سرٹیفکیٹ
proxySSLKeyکلائنٹ سرٹیفکیٹ سے مطابقت رکھنے والی نجی کلید
proxySSLCertPasswordProtectedمحفوظ پراکسی سرٹیفکیٹ اور کلید کے مواد کے لیے Git کا پاس ورڈ پرامپٹ فعال کرتا ہے

اس TLS تبادلے کے لیے https:// پراکسی URL لازمی ہے۔ HTTPS ریپوزٹری کی طرف CONNECT لے جانے والی عام HTTP پراکسی اس طرح اپنے سننے والے پر TLS کلائنٹ سرٹیفکیٹ توثیق نہیں کرتی۔

ریپوزٹری کے سرٹیفکیٹ پر اعتماد اور کوئی بھی ریپوزٹری کلائنٹ سرٹیفکیٹ اپنی ssl کنفیگریشن رکھتے ہیں۔ اسی طرح Proxy-Authenticate استعمال کرنے والا HTTP پراکسی چیلنج ایک اور توثیقی طریقہ ہے۔

یہ سیٹ اپ برقرار رکھتے وقت منسلک libcurl ورژن، TLS بیک اینڈ اور معاون سرٹیفکیٹ فارمیٹ جانچیں۔ PEM سرٹیفکیٹ کا راستہ ہر پلیٹ فارم سرٹیفکیٹ اسٹور انٹرفیس کے لیے قابلِ منتقلی متبادل نہیں ہے۔

متعلقہ مضامین