ক্রস-সাইনড CA: কী মেলে, AKI বাইন্ডিং মেলে না

দুটি CA সার্টিফিকেট একই পাবলিক কী ও একই সাবজেক্ট ধারণ করতে পারে, তবুও সেগুলো বিনিময়যোগ্য নয়। একটি স্ব-স্বাক্ষরিত, অন্যটি পুরোনো রুট দ্বারা ক্রস-স্বাক্ষরিত, এবং তাদের ইস্যুয়ারের নাম, সিরিয়াল নম্বর ও স্বাক্ষর আলাদা। একটি লিফ তার Authority Key Identifier-এর মাধ্যমে নির্দিষ্টভাবে একটির সাথে বাঁধতে পারে। এই বাইন্ডিং অদৃশ্য থাকে যতক্ষণ না কোনো ক্লায়েন্ট ভুল চেইন বেছে নেয় এবং handshake কোনো স্পষ্ট কারণ ছাড়াই ব্যর্থ হয়।

এই পাঁচটি পরীক্ষা ক্রমানুসারে করুন: প্রতিটি ভিন্ন একটি ব্যর্থতা বাদ দেয়।

পরীক্ষা 1: টেমপ্লেটে হাত দেওয়ার আগে দুটি চেইনই আঁকুন

পথগুলো লিখে রাখুন। পুরোনো পপুলেশন পুরোনো রুট A-কে বিশ্বাস করে, যা CA B ইস্যু করেছে, যা সার্ভার লিফ ইস্যু করেছে। নতুন পপুলেশন সরাসরি স্ব-স্বাক্ষরিত CA B-কে বিশ্বাস করে। দুটি B সার্টিফিকেটই একই কী ও সাবজেক্ট বহন করে, ঠিক সে কারণেই সাবজেক্ট লাইন পড়া ব্যক্তি একটি CA দেখেন যেখানে ক্লায়েন্ট দুটি দেখে।

ক্রস-স্বাক্ষরিত কপিটিও একটি প্রকৃত CA সার্টিফিকেট হতে হবে, যাতে basic constraints ও key usage স্বাক্ষরের অনুমতি দেয়।

পরীক্ষা 2: শুধু কী নয়, AKI ফিল্ডগুলো তুলনা করুন

লিফের ইস্যুয়ারের নাম B-এর সাবজেক্টের সাথে মিলতে হবে, এবং সেই অংশ সাধারণত মেলে। দুটি কপি যেখানে আলাদা হয় তা হলো Authority Key Identifier, কারণ এটি কী আইডেন্টিফায়ার, একটি ইস্যুয়ার সার্টিফিকেট ও একটি সিরিয়াল নম্বর বহন করতে পারে। কী আইডেন্টিফায়ার দুটি কপির সাথেই মেলে, কারণ কী অভিন্ন। ইস্যুয়ার ও সিরিয়াল ফিল্ড ঠিক একটির সাথে মেলে, তাই যে চেইন স্ব-স্বাক্ষরিত কপির বিপরীতে তৈরি হয় সেটি ক্রস-স্বাক্ষরিত কপির বিপরীতে ব্যর্থ হতে পারে।

অনুমান না করে লিফ পরীক্ষা করুন: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier।

তারপর দুটি প্রার্থীকে openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier" দিয়ে তুলনা করুন, এবং একই কমান্ড স্ব-স্বাক্ষরিত কপির বিপরীতে চালান।

লিফ যদি ইস্যুয়ার ও সিরিয়াল বহন করে, তবে কেবল সেই সার্টিফিকেটই চেইন সম্পূর্ণ করে যেটি ওই মানগুলো বর্ণনা করে, ক্লায়েন্ট যে কপিই লোড করুক।

পরীক্ষা 3: ইস্যুয়িং পলিসি বদলান, স্বাক্ষরিত বাইট কখনো নয়

এক্সটেনশনগুলো স্বাক্ষরের ভেতরে থাকে। বিদ্যমান লিফে একটি যোগ, বাদ বা সম্পাদনা করা মেরামত নয়, সেটি ভিন্ন সার্টিফিকেট, এবং তাতে পুনঃইস্যু দরকার। পরিবর্তনটি ইস্যুয়িং পলিসির জায়গায়: authorityKeyIdentifier = keyid,issuer:always নতুন লিফগুলোকে সার্টিফিকেট-নির্দিষ্ট বাইন্ডিং বহন করায়, আর একা keyid ইচ্ছাকৃত ক্রস-সাইনিং ট্রানজিশনের উপযোগী শিথিল রূপটি ধরে রাখে। পরবর্তী ব্যাচ স্বাক্ষরিত হওয়ার আগে আপনার PKI কোনটি চায় তা ঠিক করুন।

একটি শেয়ারড টেমপ্লেট সম্পাদনা করলে আপনার সামনের সার্ভারটিই নয়, প্রতিটি ভবিষ্যৎ সার্টিফিকেটও বদলে যায়।

পরীক্ষা 4: প্রতিটি ট্রাস্ট পপুলেশন আলাদাভাবে যাচাই করুন

পুরোনো পথ ও নতুন পথ আলাদা রান হিসেবে পরীক্ষা করুন। openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem ক্রস-স্বাক্ষরিত রুটটি চালায়, এবং নতুন রুট ও কোনো untrusted ফাইল ছাড়া একই কমান্ড স্ব-স্বাক্ষরিত রুটটি চালায়। দুটি রুট একই বান্ডলে মেশালে কোন চেইন বেছে নেওয়া হয়েছে তা লুকিয়ে যায়। এরপর বাস্তব ক্লায়েন্ট দিয়ে পুনরাবৃত্তি করুন, কারণ একটি VPN ব্যাকএন্ড এমনভাবে চেইন পছন্দ করতে পারে বা একটি সার্টিফিকেট পিন করতে পারে যেভাবে openssl করে না।

মধ্যবর্তী সার্টিফিকেটটি ক্লায়েন্ট যে সার্ভিস কনফিগারেশন সত্যিই পড়ে তার মাধ্যমে দিন, কোনো উইকি পেজের মাধ্যমে নয়।

পরীক্ষা 5: পুরোনো পথকে অবসরের ঘড়িতে রাখুন

ক্রস-সাইনিং ডিজাইন অনুযায়ীই একটি পুরোনো ট্রাস্ট পথ সচল রাখে, যা একইসাথে উদ্দেশ্য ও ঝুঁকি। এটি আপোসকৃত পুরোনো রুটের সমাধান করে না, এবং কোনো ক্লায়েন্ট থেকে সেই রুট সরায়ও না। পুরোনো পথ কখন ট্রাস্ট দেওয়া বন্ধ করবে তা লিখে রাখুন, এবং সেই দিনটি সত্যিই আসে কি না নিশ্চিত করুন।

লিফগুলো সরে যাওয়ার আগেই যদি প্রতিটি ক্লায়েন্ট নতুন রুট নিতে পারে, তবে সাধারণ ডুয়াল-ট্রাস্ট রোলআউট ক্রস-সাইনিংয়ের চেয়ে সরল, এবং অবসর দেওয়ার জন্য একটি জিনিস কম রাখে।