কিছু 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 সার্টিফিকেটের পথ প্রতিটি প্ল্যাটফর্মের সার্টিফিকেট-স্টোর ইন্টারফেসের বহনযোগ্য বিকল্প নয়।

সম্পর্কিত নিবন্ধ