IKEv2-এ দুটি স্বাক্ষর: সার্টিফিকেট ও IKE_AUTH

আপনার টিকিট বলছে সার্টিফিকেটটি SHA-256, অথচ গেটওয়ে লগ অন্য একটি স্বাক্ষর অ্যালগরিদমের নাম দিচ্ছে, এবং কেউ ইতিমধ্যে CA পুনরায় ইস্যু করার অনুরোধের খসড়া তৈরি করেছে। সেই অনুরোধ কোথাও যাওয়ার আগে দুটি স্বাক্ষর আলাদা করুন: একটি হলো প্রকাশ্য কী-এর উপর ইস্যুকারীর সিল, অন্যটি হলো IKE_AUTH চলাকালে পিয়ার প্রমাণ করে যে তার কাছে মিলে যাওয়া ব্যক্তিগত কী আছে। ভিন্ন ভিন্ন উপাদান এগুলো বেছে নেয়, এবং তাদের আলাদা হওয়া অনুমোদিত। প্রতিটি যেখানে থাকে সেখান থেকে পড়তে দুটি কমান্ড ও একটি টেবিল লাগে।

সার্টিফিকেট থেকে ইস্যুকারীর স্বাক্ষর পড়ুন

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

openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"

দুটি লেবেলই আলাদা এন্ট্রি হিসেবে লিখুন। প্রথমটি CA বর্ণনা করে, দ্বিতীয়টি সাবজেক্টের কী বর্ণনা করে, এবং কোনোটিই অনলাইন স্বাক্ষর পূর্বাভাস দেয় না।

IKE বিনিময় থেকে অনলাইন স্বাক্ষর পড়ুন

প্রমাণীকরণের সময় প্রতিটি পিয়ার নিজের ব্যক্তিগত কী দিয়ে বিনিময়ের উপাত্ত স্বাক্ষর করে, আর বিপরীত পক্ষ সেই প্রমাণ সার্টিফিকেটের পরিচয়, বিশ্বাস-শৃঙ্খল ও নীতির বিপরীতে যাচাই করে। RSA-র ক্ষেত্রে প্যাডিং ও হ্যাশ এই অনলাইন স্কিমের অন্তর্গত, তাই দীর্ঘতর কী বা নতুন SHA-256 সার্টিফিকেট নিজে থেকে প্রমাণীকরণ স্বাক্ষরের জন্য RSA-PSS বেছে নিতে পারে না। সমঝোতায় আসা পদ্ধতিটি ডেমন লগে বা তার সংযোগ-তালিকায় দেখা যায়, কখনোই সার্টিফিকেটে নয়। প্রতিটি পক্ষকে জিজ্ঞাসা করুন সে কী নিয়ে সমঝোতা করেছে, কারণ দুই দিক আলাদা হতে পারে।

ipsec statusall | grep -i "auth\|proposal"

যখন এক পক্ষ এমন স্কিমের নাম দেয় যা অন্য পক্ষ তৈরি করতে পারে না, তখন আপনি টিকিটের সেই অমিলটিই পেয়েছেন। CA পুনরায় ইস্যু করা এর ভুল প্রতিকার, কারণ ব্যর্থ হয়েছে সার্টিফিকেট কখনোই নয়।

RFC 7427 কী বদলায়, আর কী বদলায় না

মূল পদ্ধতিগুলো RFC 7296-এ প্রতিটি অ্যালগরিদম সমন্বয় অনুসারে নম্বরযুক্ত। পরবর্তী RFC 7427 স্বাক্ষর এক্সটেনশন একটি সাধারণ Digital Signature পদ্ধতি যোগ করে স্বাক্ষর-হ্যাশ সমর্থনের সংকেতসহ, ফলে নতুন হ্যাশের আর নিজস্ব পদ্ধতি-নম্বর দরকার হয় না। এটি সমঝোতার বিষয়, অনুমানের নয়: পিয়ার এক্সটেনশনটি পায় না কারণ তার লাইব্রেরি একই সার্টিফিকেট পার্স করতে পারে, আর যে পিয়ার কেবল মূল পদ্ধতিগুলো বাস্তবায়ন করে সে গেটওয়েকে সেগুলোর একটি রাখতে বাধ্য করে। এটি সম্মতিযোগ্যতার খরচসহ একটি নীতি-বিনিময়, ত্রুটি নয়।

সমর্থন প্রতি দিক ও প্রতি সংযোগে পৃথক, তাই পরিবার-স্তরের দাবিতে ভরসা না করে আপনার সামনে থাকা বিল্ডটি পরীক্ষা করুন। তিন বছর আগে লেখা একটি সক্ষমতা-ম্যাট্রিক্স তিন বছর বয়সী বিল্ড বর্ণনা করে।

ইনভেন্টারিতে চারটি সারি বসান

বিতর্ক শেষ করা রেকর্ডে চারটি লাইন থাকে, প্রতিটি ভিন্ন জায়গা থেকে পড়া এবং প্রতিটি ভিন্ন ব্যক্তির বদলানো। কিছুই সিদ্ধান্ত নেওয়ার আগে এটি পূরণ করুন, কারণ যে সারিটি ভুল সেটিই প্রতিকার বেছে নেয়।

প্রতিটি সারি নিজস্ব সম্মতিযোগ্যতার পরিণতি বহন করে। ESP সাইফার বদলালে ইস্যুকারীর স্বাক্ষর বেছে নেওয়া হয় না, আর CA যাচাই শিথিল করলে এমন অনলাইন পদ্ধতি যোগ হয় না যা পিয়াররা কখনো সমঝোতা করেনি। টিকিট যখন স্বাক্ষর-অমিল দাবি করে, তখন সত্যিই ভুল সারিটি প্রায় কখনোই প্রথমটি নয়।

PKI দুর্বল না করে পুরোনো কেসটির নিষ্পত্তি করুন

পুরোনো পিয়ার কেবল এমন স্কিম দিতে পারে যা আপনার নীতি আর অনুমোদন করে না। বিকল্প হলো সময়সীমাবদ্ধ সম্মতিযোগ্যতা-ব্যতিক্রম, ক্লায়েন্ট হালনাগাদ, বা কেবল সেই পিয়ারের জন্য ভিন্ন প্রমাণীকরণ ব্যবস্থা। দুর্বলতর সার্টিফিকেট স্বাক্ষরকে ঘিরে PKI পুনর্নির্মাণ অনলাইন বিনিময়ের সীমাবদ্ধতা সারায় না, বরং একই CA-তে ভরসা করা প্রতিটি অন্য সেবাকে দুর্বল করে। কোন সারি বদলেছেন এবং ব্যতিক্রম কখন শেষ হবে তা লিখে রাখুন।

তারপর দুই পড়া আবার উপর থেকে চালান, কারণ এক সারির পরিবর্তন অন্যের সমঝোতাকে সরিয়ে দিতে পারে। পুরো ইনভেন্টারি দুটি কমান্ড ও একটি টেবিল, আর পিয়ার রাউটার, ল্যাপটপ বা অ্যাপ্লায়েন্স যা-ই হোক কাজটি একই।