আপনার VPN ক্লায়েন্ট একটি সার্টিফিকেটে ভরসা করার আগে কী কী যাচাই করে
সার্টিফিকেট সতর্কবার্তাটি আপনার ক্লায়েন্টের যাচাই করা চারটি গেট দিয়ে যাচাই করুন: CA-তে ভরসা, চেইন তৈরি, পিয়ার নাম ও উদ্দেশ্য, এবং প্রত্যাহার নীতি।
আপনার VPN ক্লায়েন্ট বলে সার্টিফিকেটটি যাচাই করা যায়নি, আর ডায়ালগটি সেখানেই থেমে যায়। ফাইলটি আছে, সার্ভার চালু আছে, আর একই প্রোফাইল গত মাসে অন্য একটি ল্যাপটপে কাজ করেছিল। ওই এক-লাইনের সতর্কবার্তার নিচে ক্লায়েন্ট পিয়ার সার্টিফিকেটটি চারটি গেট দিয়ে চালিয়েছে: আপনি কনফিগার করা একটি সার্টিফিকেট কর্তৃপক্ষ স্বাক্ষর পথের জামিন দেয়, সেই পথটি কর্তৃপক্ষ পর্যন্ত পৌঁছায়, পিয়ার নামটি আপনার চাওয়া নাম, এবং সার্টিফিকেটটি এখন এই উদ্দেশ্যে ব্যবহারযোগ্য। কোন গেটটি বন্ধ হয়েছে তা খুঁজুন, আর সমাধান সাধারণত একটি ফাইল; এই ধাপটি বাদ দিলে সারা বিকেল বান্ডেল আবার আমদানি করবেন।
প্রোফাইল সম্পাদনার আগে ডায়ালগটি পড়ুন
সার্টিফিকেট ত্রুটির ভাষা দেয় নিচের লাইব্রেরি, আপনি যে VPN পণ্য ইনস্টল করেছেন সেটি নয়, তাই সঠিক স্ট্রিংটিই আপনার প্রথম প্রমাণ। «স্থানীয় ইস্যুয়ার সার্টিফিকেট পাওয়া যায়নি» পথটি বা ট্রাস্ট অ্যাঙ্করের দিকে ইশারা করে। «সার্টিফিকেটের মেয়াদ শেষ বা এটি এখনো বৈধ নয়» সময়ের দিকে ইশারা করে। «অসমর্থিত সার্টিফিকেট উদ্দেশ্য» বর্ধিত কী ব্যবহারের দিকে ইশারা করে। নামের অমিল আপনাকে বলে এটি কোন নাম চেয়েছিল। চারটির কোনোটিই ক্লায়েন্ট পুনরায় ইনস্টল করে সারানো যায় না।
কিছু বদলানোর আগে লগের মাত্রা বাড়ান। OpenVPN --verb 4 দিয়ে চালালে হ্যান্ডশেকের আশেপাশে যাচাইয়ের ব্যর্থতা জানায়, আর strongSwan তার পরিচয় ও চেইনের সিদ্ধান্ত charon লগে লেখে। তারপর নিশ্চিত করুন আপনি কোন সার্টিফিকেট পরীক্ষা করছেন, কারণ মানুষ সাধারণত ডিস্কের ফাইল পরীক্ষা করে, অথচ প্রোফাইল পুরোনো একটি কপি ভেতরে রাখে। প্রোফাইল যখন PEM ব্লক ভেতরে রাখে, তখন ভেতরে রাখা সার্টিফিকেটই পরীক্ষার বিষয়।
সার্টিফিকেট কর্তৃপক্ষ পরিচয় স্বাক্ষর করে, অনুমতি নয়
কর্তৃপক্ষ একটি নাম ও একটি স্বাক্ষর কী ধরে রাখে। এটি নিজের নীতির অধীনে একটি পাবলিক কী-কে সেই নামের সঙ্গে বেঁধে সার্টিফিকেট ইস্যু করে, সঙ্গে বৈধতার সময়সীমা ও ব্যবহারের সীমাবদ্ধতা যুক্ত থাকে। আপনার ক্লায়েন্টের ইস্যুয়ার চেনার জন্য কেবল কর্তৃপক্ষের সার্টিফিকেটই দরকার; স্বাক্ষর কী তার কখনো দরকার হয় না, আর সেই কী ক্লায়েন্টদের পাঠানো মানে ডিপ্লয়মেন্ট যেসব পরিচয়ে ভরসা করে সেগুলো বানানোর ক্ষমতা তুলে দেওয়া।
একটি কর্তৃপক্ষে ভরসা করলে তার স্বাক্ষর করা প্রতিটি সার্টিফিকেট প্রার্থী হয়ে যায়, সঠিক পিয়ার নয়। একই অভ্যন্তরীণ CA-র একটি ওয়েব সার্ভার সার্টিফিকেটও প্রার্থী। এজন্যই নাম ও উদ্দেশ্যের গেট আছে, আর এজন্যই একটি আপসকৃত CA কী যেকোনো একক সার্ভারের চেয়ে বেশি গুরুত্বপূর্ণ: এটি কর্তৃপক্ষের কখনো ইস্যু করা প্রতিটি পরিচয়ে পৌঁছায়। প্রতিটি ডিভাইসের জন্য আলাদা ক্লায়েন্ট সার্টিফিকেট দিন, যাতে হারানো ল্যাপটপ পুরো ডিপ্লয়মেন্টের কী পুনর্গঠন নয়, বরং একটি প্রত্যাহার হয়।
ক্লায়েন্ট যে পথ তৈরি করতে চায় সেটি আবার গড়ুন
পথটি পিয়ার সার্টিফিকেট থেকে শুরু হয়ে শূন্য বা তার বেশি মধ্যবর্তী সার্টিফিকেটের মধ্য দিয়ে আপনার ট্রাস্ট স্টোরের একটি রুটে পৌঁছায়। অনুপস্থিত মধ্যবর্তী সার্টিফিকেটই সবচেয়ে সাধারণ চেইন ব্যর্থতা, আর ক্লায়েন্টের দিক থেকে এটি অবিশ্বস্ত রুটের মতোই দেখায়। প্রথমে লিফটি পড়ুন, তারপর যে উপাদান আপনি পাঠাতে চান তা থেকে OpenSSL-কে পথ তৈরি করতে দিন।
openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crtশূন্য এক্সিট স্ট্যাটাস মানে ওই ফাইলগুলো থেকে পথ তৈরি হয়েছে; ব্যর্থতা যে সার্টিফিকেটে পৌঁছানো যায়নি তার নাম বলে। যদি openssl verify সফল হয় অথচ ক্লায়েন্ট এখনো অস্বীকার করে, পার্থক্যটি সার্ভার আসলে যা পাঠায় বা প্রোফাইল কোন ট্রাস্ট ফাইল লোড করে সেখানে। OpenVPN-এ মধ্যবর্তী সার্টিফিকেট সার্ভার সার্টিফিকেট ফাইলের সঙ্গে যেতে পারে বা --extra-certs দিয়ে আলাদাভাবে দেওয়া যায়, আর একই সাবজেক্ট নামে লেখা দুটি রুট ধরা একটি বান্ডেল আপনার একটি ক্লায়েন্টকে ভুল শাখায় পাঠাবে।
নাম ও উদ্দেশ্য আলাদা গেট
চেইন তৈরি কখনো জিজ্ঞেস করে না নামটি আপনার কি না। OpenVPN এটি যাচাই করে কেবল তখনই যখন প্রোফাইল --verify-x509-name সেট করে, আর শুধু কমন নেম মেলানোর পুরোনো অভ্যাস সেই সার্টিফিকেটে ভেঙে পড়ে যাদের পরিচয় subjectAltName-এ থাকে। IKEv2 ডিপ্লয়মেন্ট কনফিগার করা পরিচয়কে SAN এন্ট্রি বা ডিস্টিংগুইশড নেমের সঙ্গে মেলায়, ক্লায়েন্টের উপর নির্ভর করে, আর একটি ওয়াইল্ডকার্ড বা %any মান আপনার মনে করা তুলনাটি চুপচাপ বন্ধ করে দেয়।
এরপর আসে সময় ও উদ্দেশ্য। যে ল্যাপটপের ঘড়ি কয়েক ঘণ্টা এগিয়ে, সে এখনো বৈধ নয় এমন সার্টিফিকেট প্রত্যাখ্যান করে, আর মেয়াদোত্তীর্ণ মধ্যবর্তী সার্টিফিকেট লিফ বৈধ থাকলেও পথ ব্যর্থ করে। উদ্দেশ্যের ব্যর্থতা আসে বর্ধিত কী ব্যবহারে serverAuth ছাড়া সার্টিফিকেট থেকে, বা এমন keyUsage থেকে যা হ্যান্ডশেক স্বাক্ষর অনুমোদন করে না, যা OpenSSL অসমর্থিত সার্টিফিকেট উদ্দেশ্য হিসেবে জানায়। সঠিক টেমপ্লেট থেকে পুনরায় ইস্যু করুন; ওই বার্তায় যাচাই বন্ধ করার কোনো কারণ নেই।
প্রত্যাহার চলে কেবল যদি কেউ এটি কনফিগার করে
CRL বা OCSP প্রতিক্রিয়া স্বয়ংক্রিয়ভাবে দেখা হয় না। OpenVPN সার্ভারে ক্লায়েন্ট সার্টিফিকেট একটি তালিকার সঙ্গে মেলানো হয় কেবল যখন --crl-verify এমন একটি তালিকা দেখায়। সার্ভার সার্টিফিকেটের ক্লায়েন্ট-পক্ষ যাচাই বাস্তবায়নের উপর নির্ভর করে এবং প্রায়ই থাকে না। strongSwan-এর পিয়ারের জন্য CRL দেখার আগে নিজের প্রত্যাহার প্লাগইন ও একটি নীতি দরকার।
এতেই বোঝা যায় আপনি শেষে যে টিকিট পাবেন: প্রত্যাহৃত ক্লায়েন্ট সার্টিফিকেট এখনো সংযোগ করে, আর সবাই ধরে নেয় প্রত্যাহার নষ্ট। কিছুই যাচাই করছিল না। CRL প্রকাশ করুন ও রিফ্রেশ করুন, বা ক্লায়েন্ট সার্টিফিকেট এত কম আয়ু দিন যে পুরোনো প্রত্যাহার অল্প সময়ের জন্য গুরুত্বপূর্ণ থাকে, আর কোনো ঘটনার সময় দরকার হওয়ার আগে ল্যাব সার্টিফিকেটে প্রত্যাহারের পথটি মহড়া দিন।
যাচাই চালু রেখে সারানোর ক্রম
ফাইলে হাত দেওয়ার আগে উপসর্গ অনুযায়ী সাজান, কারণ সারণির প্রতিটি সারি আপনাকে ভিন্ন একটি বস্তুতে পাঠায়।
| Client says | Most likely gate | First check |
|---|---|---|
| unable to get local issuer certificate | trust anchor or missing intermediate | your own openssl verify against the files the profile loads |
| expired or not yet valid | validity window | leaf and intermediate dates against the device clock |
| unsupported certificate purpose | extended key usage | serverAuth present, keyUsage allows the handshake |
| name mismatch | peer identity | subjectAltName entries versus the profile name |
তালিকাটি একবারেই শেষ করুন: প্রোফাইল যে ফাইল লোড করে তা নিশ্চিত করুন, পথটি নিজেই গড়ুন, সার্ভার মধ্যবর্তী সার্টিফিকেট পাঠায় কি না দেখুন, ঘড়ি মেলান, SAN পড়ুন, EKU পড়ুন, তারপর আবার সংযোগ করে একই লগ লাইনটি মিলিয়ে যেতে দেখুন। যদি কোনো ডিভাইসকে আদৌ CA দেওয়া না যায়, পিনিং-ই সৎ বিকল্প, কারণ OpenVPN 2.6 --peer-fingerprint গ্রহণ করে এবং যাচাই সরানোর বদলে ভরসা একটি কী-তে সংকুচিত করে। এই ক্ষেত্রগুলোর প্রতিটির অর্থ কী, তার রেফারেন্স RFC 5280।