বাতিল করা VPN সার্টিফিকেট কি এখনও সংযোগ করে? CRL প্রয়োগ যাচাই করুন
বাতিল করা সার্টিফিকেট এখনও সংযোগ করে যখন CRL কখনও যাচাইকারীর কাছে পৌঁছায় না। এই ক্রমে ইস্যুকারী, লোড করা ক্রমিক নম্বর, পুনরায় লোডের আচরণ এবং সক্রিয় সেশন যাচাই করুন।
আপনি সার্টিফিকেটটি বাতিল করেছেন, নতুন তালিকা তৈরি করেছেন, আর পুরোনো প্রোফাইল এখনও একটি টানেল তোলে। বাতিলকরণ নিজে ভাঙা নয়: CRL হলো একটি স্বাক্ষরিত ঘোষণা যে একটি ক্রমিক নম্বর আর বৈধ নয়, এবং এটি প্রবেশাধিকার তখনই বদলায় যখন TLS শেষ করা উপাদানটি সেটি সঠিক ইস্যুকারীর জন্য লোড করে, গ্রহণের সিদ্ধান্ত নেওয়ার আগে। বেশিরভাগ এমন ঘটনা সেখানেই, তাই বাতিলকরণ ও প্রত্যাখ্যান দুটি আলাদা তথ্য।
নিচের পাঁচটি যাচাই ক্রমে করুন এবং প্রথমটি ব্যর্থ হলে থামুন, কারণ প্রতিটি পরবর্তী যাচাই আগেরগুলোকে সত্য ধরে নেয়।
কোন উপাদান গ্রহণের সিদ্ধান্ত নেয় তা যাচাই করুন
যে প্রক্রিয়া ক্লায়েন্ট সার্টিফিকেট যাচাই করে তার নাম বলুন, কারণ কেবল সেই প্রক্রিয়াই একটি তালিকা প্রয়োগ করতে পারে। OpenVPN সার্ভারে এটি ডেমন নিজেই, crl-verify দিয়ে কনফিগার করা। ocserv-এ এটি ocserv.conf-এর ভেতরে crl লাইন। strongSwan-এ ইনপুট হলো লোড করা CRL এবং strictcrlpolicy একসঙ্গে। VPN-এর সামনে TLS শেষ করা প্রক্সি বা ডিভাইসও আসল যাচাইকারী হতে পারে, এবং তা হলে তার পেছনের ডেমন ক্লায়েন্ট সার্টিফিকেট কখনও দেখে না।
WireGuard অন্য শ্রেণিতে পড়ে। এর কোনো সার্টিফিকেট নেই এবং বাতিল তালিকা নেই; পিয়ার কনফিগারেশনে তার পাবলিক কী দিয়ে গৃহীত হয়, তাই প্রবেশাধিকার শেষ করার অর্থ ওই কী সরানো। আপনি যদি শুধু WireGuard-ভিত্তিক স্থাপনায় CRL খুঁজছেন, তবে সেই পদ্ধতি সেখানে নেই।
ক্লায়েন্ট পক্ষের ফাঁদ থেকেও সাবধান থাকুন। যে ক্লায়েন্ট সার্ভারের সার্টিফিকেট পছন্দ না হওয়ায় সংযোগ করতে অস্বীকার করে, সে সার্ভারের চেইন প্রয়োগ করছে, নিজের শংসাপত্র বাতিল করছে না। ব্যবহারকারীর সার্টিফিকেট কেবল সেখানেই বাতিল হয় যেখানে সেই ব্যবহারকারীর সার্টিফিকেট যাচাই হয়, আর সেটি প্রায় সবসময় সার্ভার পক্ষ।
তালিকাটি কোন ইস্যুকারীর জন্য স্বাক্ষরিত তা যাচাই করুন
CRL একটি ইস্যুকারী CA-তে সীমাবদ্ধ। মূল ও মধ্যবর্তী CA থাকলে পাতার সার্টিফিকেট মধ্যবর্তী থেকে আসে, তাই গুরুত্বপূর্ণ তালিকা মধ্যবর্তীর CRL; মূলের তালিকা সেই পাতাগুলো সম্পর্কে কিছু বলে না। ভুল ফাইলের দিকে নির্দেশ করা যাচাইকারী তা আনন্দে পার্স করে, কোনো মিলে যাওয়া এন্ট্রি পায় না এবং সবকিছু গ্রহণ করে।
ডেমন স্পর্শ করার আগে জোড়াটি নিশ্চিত করুন। সার্টিফিকেটের ইস্যুকারী তালিকার subject-এর সঙ্গে মিলতে হবে:
openssl x509 -in client.crt -noout -issuer -serial
openssl crl -in intermediate.crl -noout -issuer -lastupdate -nextupdateযখন দুটোই একই CA থেকে আসে, সার্টিফিকেটের জন্য ছাপা ক্রমিক নম্বরটিই সেই মান যা তালিকায় থাকতে হবে। যদি তারা না মেলে, তাহলে আপনার কাছে ভুল CRL বা তার ভুল অনুলিপি রয়েছে।
বৈধতা একই যাচাইয়ের অন্তর্গত। অতীতে থাকা nextUpdate তালিকাটিকে পুরোনো করে দেয়, এবং বদ্ধভাবে ব্যর্থ হওয়া যাচাইকারী তখন কেবল বাতিলটিকেই নয়, প্রতিটি ক্লায়েন্টকে প্রত্যাখ্যান করবে।
ক্রমিক নম্বরটি ডেমন যে অনুলিপি লোড করেছে তাতে আছে কিনা যাচাই করুন
বাতিলকরণ CA ডেটাবেসে একটি এন্ট্রি লেখে, আর পুনরুৎপাদন নতুন ফাইল লেখে। দুটির কোনোটিই চালু থাকা সেই ডেমনে পৌঁছায় না যা শুরুর সময় পুরোনো অনুলিপি লোড করেছিল। তালিকাটি ডাম্প করুন এবং ক্রমিক নম্বর খুঁজুন:
openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crlতারপর যাচাই করুন আপনার বাস্তবায়ন ফাইলটি কীভাবে নেয়। OpenVPN crl-verify-কে দেওয়া পথ শুরুর সময় একবার পড়ে, তাই নতুন তালিকার জন্য পুনরায় চালু বা পুনরায় চালুর সংকেত দরকার; একই অপশন কোনো ডিরেক্টরির দিকে হলে প্রতিটি সংযোগে আবার পড়া হয়, এবং তাই ডিরেক্টরি মোড রয়েছে। strongSwan-কে তার শংসাপত্র পুনরায় লোড করতে হয়, যেমন swanctl --load-creds দিয়ে। ফাইলটি ডিস্কে সঠিক হওয়া এবং যাচাইকারী তা ব্যবহার করা দুটি আলাদা তথ্য।
অনুপস্থিত বা মেয়াদোত্তীর্ণ তালিকার নীতি যাচাই করুন
এটি সেই সিদ্ধান্ত যা অনেক স্থাপন কখনও স্পষ্টভাবে নেয় না, এবং এটি ঠিক করে বাতিলকরণ আপনাকে রক্ষা করে নাকি সবাইকে বাইরে তালাবদ্ধ করে। Fail-closed মানে ব্যবহারযোগ্য বাতিল তথ্য ছাড়া প্রত্যাখ্যান ঘটে; fail-open মানে যাচাইকারী তা ছাড়াই এগিয়ে যায়। strongSwan পছন্দটি strictcrlpolicy হিসেবে দেখায়। OpenVPN crl-verify সহ এমন ফাইলে শুরু হতে অস্বীকার করে যা সে পড়তে বা পার্স করতে পারে না, এবং মেয়াদোত্তীর্ণ তালিকা নীরব গ্রহণের বদলে মেয়াদোত্তীর্ণ CRL সম্পর্কে TLS যাচাই ত্রুটি হিসেবে দেখা দেয়।
| State of the revocation data | Fail-closed result | Fail-open result |
|---|---|---|
| List missing or unreadable | Verification fails, so expect an outage | Every client connects, including the revoked one |
List past nextUpdate | Validation errors until a fresh list is deployed | Old status is trusted indefinitely |
| Revoked serial present in the loaded list | Handshake rejected for that certificate | Handshake rejected for that certificate |
আপনি যে দিকই বেছে নিন, স্বয়ংক্রিয়করণ পছন্দের চেয়ে বেশি গুরুত্বপূর্ণ: nextUpdate-এর আগে CRL পুনরুৎপাদন করে এমন কাজ, এবং স্থাপিত অনুলিপি পুরোনো হলে সতর্কতা, দুটি নীতিকেই ঘটনা হয়ে ওঠা থেকে বিরত রাখে। OCSP দিয়ে অনলাইন যাচাই তাজগী উত্তরদাতার কাছে সরায়, তবে একই নিয়ম প্রযোজ্য, কারণ উত্তর যাচাই করতে কনফিগার না করা যাচাইকারী কিছুই বদলায় না।
সক্রিয় সেশন যাচাই করুন, তারপর কী-এর অনুলিপি
বাতিলকরণের মূল্যায়ন সার্টিফিকেট যাচাইয়ের সময় হয়, যা সংযোগের সময় এবং পুনরায় দরকষাকষির সময় ঘটে। প্রতিষ্ঠিত সেশন পুনরায় দরকষাকষি না করা পর্যন্ত চলে, এবং OpenVPN-এর ডিফল্ট reneg-sec 3600 সহ ঘণ্টায় একবার। যদি ব্যক্তিকে এখনই নেটওয়ার্কের বাইরে যেতে হয়, তালিকা প্রকাশের সঙ্গে সঙ্গে সেশনও শেষ করুন, তারপর নিশ্চিত করুন যে পুনঃসংযোগ প্রত্যাখ্যাত হয়।
শংসাপত্রকে তার অনুলিপি থেকে আলাদা করুন। একটি ল্যাপটপে প্রোফাইল মুছলে একই ব্যক্তিগত কী-এর অন্য অনুলিপি প্রমাণিত হওয়া থেকে বিরত হয় না; বাতিলকরণই প্রতিটি অনুলিপিকে অকেজো করে, আর তা কেবল আগের যাচাইগুলো সঠিক হলেই। প্রতিস্থাপন ডিভাইসকে নিজের সার্টিফিকেট দিন যাতে একটি অন্যটি না ছুঁয়েই বাতিল করা যায়।
এটিকে সম্পূর্ণ বলার আগে: যাচাইকারী উপাদান চিহ্নিত হয়েছে, তালিকার ইস্যুকারী পাতার ইস্যুকারীর সঙ্গে মেলে, বাতিল করা ক্রমিক নম্বরটি ডেমন সত্যিই যে অনুলিপি লোড করেছে তাতে আছে, অনুপস্থিত বা মেয়াদোত্তীর্ণ তালিকার নীতি ইচ্ছাকৃত ও পর্যবেক্ষিত, এবং সক্রিয় সেশন অপেক্ষার বদলে সমাপ্ত হয়েছে। এসবের পেছনের ফরম্যাটগুলো RFC 5280-এ নির্দিষ্ট।