OCSP বনাম CRL: প্রতিটি রিভোকেশন চেক আসলে কীভাবে কাজ করে

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

ধাপ 1: প্রতিটি চেক কী ফেরত দেয় এবং কতদিন ব্যবহারযোগ্য থাকে

একটি CRL একটি স্বাক্ষরিত অবজেক্ট হিসেবে প্রকাশিত হয় যা একটি ইস্যুয়ারের রিভোক করা প্রতিটি সার্টিফিকেট ঢেকে রাখে, তাই ভেরিফায়ার এটি একবার আনে এবং তালিকার nextUpdate পার না হওয়া পর্যন্ত পুনরায় ব্যবহার করে। OCSP রেসপন্স সংকীর্ণতর: এটি ঠিক একটি সার্টিফিকেটের উত্তর দেয় এবং thisUpdate, producedAt এবং সাধারণত nextUpdate-ও বহন করে। এই পার্থক্যই বাকি সবকিছু নিয়ন্ত্রণ করে। ক্যাশ করা CRL নিঃশব্দে পুরোনো হয়ে যায়, কারণ ফাইলটি এখনও পার্স হয় এবং এর স্বাক্ষর এখনও যাচাই হয়, অন্যদিকে মেয়াদোত্তীর্ণ OCSP উত্তর তার টাইমস্ট্যাম্প পড়ার সঙ্গে সঙ্গেই স্পষ্টভাবে মূল্যহীন।

তাই ক্যাশিংই প্রথমে স্থির করার বিষয়: কোন উপাদান কপিটি ধরে রাখে, আর সেই কপি কোন সীমা মানে। গেটওয়েতে সীমা হওয়া উচিত nextUpdate বিয়োগ একটি নিরাপত্তা মার্জিন, কখনও নয় কোনো HTTP ক্যাশ হেডার যে-কোনো প্রস্তাব দেয়। openssl crl -in issuer.crl -noout -lastupdate -nextupdate দুটি তারিখই ছাপে, এবং তালিকার nextUpdate যদি আগেই অতীতে থাকে তবে তাকে কেবল পুরোনো নয়, অনুপস্থিত হিসেবে ধরতে হবে।

ধাপ 2: সার্টিফিকেট ক্লায়েন্টকে কোথায় নির্দেশ করে

লিফ সার্টিফিকেট সাধারণত দুটি সংকেত বহন করে: একটি CRL ডিস্ট্রিবিউশন পয়েন্ট এক্সটেনশন এবং OCSP-এর জন্য একটি অথরিটি ইনফরমেশন অ্যাকসেস এন্ট্রি। openssl x509 -in client.pem -noout -ext crlDistributionPoints প্রথমটি ছাপে, আর দ্বিতীয়টি openssl x509 -in client.pem -noout -text-এর AIA অংশের নিচে থাকে। যেকোনো এক্সটেনশন একটি ইশারা, কোনো বাধ্যবাধকতা নয়। যে ক্লায়েন্ট কখনও রিভোকেশন চেকিং প্রয়োগ করে না, সে এমন একটি সার্টিফিকেটের সঙ্গে সম্পূর্ণ ভালোভাবে সংযোগ করবে যার এক্সটেনশনগুলো এক বছরের মৃত একটি রেসপন্ডারের নাম দেয়।

ডিস্ট্রিবিউশন পয়েন্টগুলো প্রায়ই এমন একটি অভ্যন্তরীণ হোস্টের নাম দেয় যা কেবল একটি নেটওয়ার্ক সেগমেন্টের ভেতরে রিজলভ হয়, আর কিছু পুরোনো ক্লায়েন্ট ldap URL একেবারেই প্রত্যাখ্যান করে। টানেলটি যে হোস্টে শেষ হয় সেখান থেকে পৌঁছানোর ক্ষমতা পরীক্ষা করুন, নিজের ল্যাপটপ থেকে নয়, কারণ কেবল সেই দৃষ্টিকোণটির ব্যর্থতাই আসলে গুরুত্বপূর্ণ।

ধাপ 3: বিভ্রাটের আগেই fail-closed না fail-open বেছে নিন

অপৌঁছানো রেসপন্ডার বা মেয়াদোত্তীর্ণ তালিকা একটি সিদ্ধান্ত চাপিয়ে দেয়: সংযোগ প্রত্যাখ্যান করুন, অথবা গ্রহণ করে ফাঁকটি রেকর্ড করুন। OpenSSL-এর verify সাবকমান্ড কঠোর পছন্দটিকে স্পষ্ট করে, কারণ -crl_check যোগ করলে অনুপলব্ধ CRL হয়ে যায় unable to get certificate CRL এবং একটি ব্যর্থ যাচাই। বেশিরভাগ স্ট্যাকে সফট-ফেইল আসলে কোনো ফ্ল্যাগই নয়, এটি চেকের অনুপস্থিতি, আর ঠিক এজন্যই এটি দুর্ঘটনাক্রমে জাহাজে ওঠে।

একটি ক্লায়েন্টের সত্যিই কোন আচরণ আছে তা দেখতে রেসপন্ডারটি সরিয়ে আবার সংযোগ করুন। টানেল যদি তবুও ওঠে, তবে বাদ পড়া চেকটি যে লগ লাইনে লিপিবদ্ধ হয়েছে সেটি খুঁজুন, তারপর ভাবুন কোনো ঘটনার সময় কেউ সেই লাইনটি পড়বে কি না। একই ভেন্ডর প্রোটোকলভেদে ভিন্ন হতে পারে—একই মেশিনে একটি IKEv2 ক্লায়েন্ট ও একটি OpenVPN ক্লায়েন্ট সম্পর্কহীন কনফিগারেশন নব পড়ে।

ধাপ 4: ট্রাফিক যেখানে গৃহীত হয় সেখানেই চেক চলে তা প্রমাণ করুন

যে প্রসেসটি সংযোগ শেষ করে বা অনুমোদন দেয় সেটি খুঁজুন, তারপর তাকে জিজ্ঞাসা করুন সেই কনফিগারেশন লাইনটি যা রিভোকেশন চেকিং সক্রিয় করে। যে গেটওয়ে চেইন যাচাই করে কিন্তু কখনও রিভোকেশন সম্পর্কে জিজ্ঞাসা করে না, সে আপনার ডকুমেন্টেশনের নীতির চেয়ে ভিন্ন নীতি প্রয়োগ করছে, আর সার্টিফিকেট চেইনের কোনো স্ক্রিনশটই তার বিপরীত প্রমাণ করে না। OpenVPN অপশনটির বানান crl-verify লেখে; strongSwan CRL ও OCSP লুকআপ CA কনফিগারেশনের অধীনে রাখে, যেখানে crl_uris বা ocsp_uris সেট করা হয়। যদি কোনোটির দিকেই দেখাতে না পারেন, ধরে নিন চেকটি অনুপস্থিত।

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

ধাপ 5: ইচ্ছাকৃতভাবে একটি সার্টিফিকেট রিভোক করুন

একটি পরীক্ষামূলক সার্টিফিকেট নিন, উৎপাদন যে চ্যানেল ব্যবহার করে সেই একই চ্যানেলে এটি রিভোক করুন, এবং রেসপন্ডারকে সরাসরি জিজ্ঞাসা করুন। openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text রিভোকেশনের সময়সহ Cert Status: revoked রিপোর্ট করা উচিত, আর good উত্তর মানে আপনার রিভোকেশন আপনার ক্লায়েন্টরা যে রেসপন্ডারকে জিজ্ঞাসা করে সেখানে পৌঁছায়নি। তারপর তালিকা পথে একই সিদ্ধান্ত দেখতে openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem চালান। এক্সিট কোডের বদলে কারণের স্ট্রিংটি পড়ুন, কারণ রিভোকেশন প্রত্যাখ্যান ও চেইন ত্রুটি দুটোই ব্যর্থতায় শেষ হয়।

যে ধাপটি সত্যিই গুরুত্বপূর্ণ তা শেষেরটি: পুরোনো প্রোফাইল নিয়ে প্রকৃত প্রয়োগের জায়গায় আবার সংযোগ করুন এবং প্রত্যাখ্যানটি রিভোকেশন থেকেই আসছে তা নিশ্চিত করুন। তারপর একটি নতুন, বৈধ সার্টিফিকেট দিয়ে আবার সংযোগ করুন প্রমাণ করতে যে আপনি কেবল লিসেনারটি ভাঙেননি। ক্লায়েন্টে প্রোফাইল মুছে ফেলা সার্ভারের সিদ্ধান্ত সম্পর্কে কিছুই প্রমাণ করে না, আর যে মেশিন কখনও টানেল শেষ করে না সেখানে সফল openssl verify চালানিও নয়। RFC 6960 নির্ধারণ করে একটি সম্মত OCSP উত্তরে কী থাকে, যার মধ্যে এই পরীক্ষা যে স্ট্যাটাস মানগুলো পড়ে সেগুলোও আছে।