VPN ক্লায়েন্ট কী তৈরি করা ও স্বাক্ষরের জন্য CSR জমা দেওয়ার উপায়

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

ধাপ 1: কী-টি যেখানে থাকবে সেখানেই তৈরি করুন

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

সফটওয়্যার প্রবাহটি এমন দেখায়, কী ও অনুরোধ একই সেশনে তৈরি হয়:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

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

ধাপ 2: পরিচয়টি অনুরোধে রাখুন, ইমেইলে নয়

অনুরোধ তৈরি হওয়ার আগেই ঠিক করুন VPN আসলে কী প্রমাণীকরণ করে, কারণ সেই উত্তরটি CSR-এর ভেতরেই থাকে। OpenVPN ঐতিহ্যগতভাবে ক্লায়েন্ট পরিচয়কে সার্টিফিকেটের সাধারণ নামের সঙ্গে বেঁধে রাখে, আর strongSwan-এর মতো টুল পরিচয় স্ট্রিংকে সাবজেক্ট বা সাবজেক্ট অল্টারনেটিভ নামের সঙ্গে মেলায়। যে ইমেইল বলে আমার নাম alice তা প্রমাণ নয়, আর যে অনুরোধের সাবজেক্ট একই কথা বলে তা সামান্য ভালো মাত্র।

আপনার যাচাইকারী একটি যাচাই করলে সাবজেক্ট অল্টারনেটিভ নাম যোগ করুন, কারণ আধুনিক মেলানো পুরোনো CN প্রায়ই উপেক্ষা করে:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

CN ছোট, স্থিতিশীল এবং ল্যাপটপ মডেলের বদলে অ্যাকাউন্টের সঙ্গে বাঁধা রাখুন। ব্যবহারকারীর ডিভাইসের সিরিয়াল নম্বর থাকা নাম হলো প্রথম হার্ডওয়্যার প্রতিস্থাপনের অপেক্ষায় থাকা একটি সাপোর্ট সমস্যা।

ধাপ 3: স্বাক্ষরের আগে অনুরোধটি যাচাই করুন

ইস্যুকারী দুটি ভিন্ন জিনিস যাচাই করে, আর তাদের গুলিয়ে ফেলা হলো চিরাচরিত ভুল। প্রথমত, অনুরোধটি ভেতরে সামঞ্জস্যপূর্ণ: স্বাক্ষরটি যে পাবলিক কী বহন করে তার বিরুদ্ধে যাচাই হয়। দ্বিতীয়ত, অনুরোধকারী অনুরোধটি যা চায় তার অধিকারী, আর এর উত্তর কোনো ক্রিপ্টোগ্রাফিক পরীক্ষা দিতে পারে না।

যান্ত্রিক অংশটি একটি কমান্ড, এবং এটি সাবজেক্টের সঙ্গে যাচাইয়ের ফলাফল ছাপা উচিত:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

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

ধাপ 4: অনুমোদন দিন, তারপর স্পষ্ট এক্সটেনশনসহ স্বাক্ষর করুন

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

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

একটি ইতিমধ্যে ব্যবহৃত হলে বিদ্যমান সিরিয়াল ফাইলের সঙ্গে -CAserial ব্যবহার করুন, আর CA কী অফলাইনে বা আপনার নীতি যে সুরক্ষিত স্টোরের নাম বলে সেখানেই রাখুন। সার্টিফিকেট সিরিয়াল নম্বর ইস্যুকারী প্রতি অনন্য হতে হবে; সিরিয়াল ফাইল শূন্য থেকে পুনরায় তৈরি করলে সংঘর্ষের ঝুঁকি থাকে যা প্রত্যাহারকে দ্ব্যর্থক করে।

কী ইস্যু হলো তা লিপিবদ্ধ করুন: সিরিয়াল, সাবজেক্ট, অনুরোধকৃত পরিচয়, অনুমোদনকারী ব্যক্তি এবং মেয়াদ। সেই রেকর্ডই পরে প্রত্যাহারের সিদ্ধান্ত নির্ভর করে, আর তালিকাভুক্তির চিহ্ন শুধু একটি মেইলবক্সে থাকলে শুধু সার্টিফিকেট থেকে তা পুনর্গঠন করা যায় না।

ধাপ 5: মিলে যাওয়া কী-এর পাশে এটি ইনস্টল করুন এবং জোড়াটি প্রমাণ করুন

ক্লায়েন্ট সার্টিফিকেট এবং ইস্যুকারী চেইন পায়, কখনোই কী নয়. সংযোগের আগে নিশ্চিত করুন যে সার্টিফিকেটটি ডিস্কে থাকা কী-এর সঙ্গে সত্যিই জোড়া লাগে, কারণ অমিল জোড়া অনেক পরে একটি বিভ্রান্তিকর হ্যান্ডশেক ব্যর্থতা তৈরি করে:

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

দুটি ডাইজেস্ট মিলতে হবে। তারপর সংযোগ করুন এবং নিশ্চিত করুন যে সার্ভার যে পরিচয় লগ করে তা আপনার অনুমোদিত পরিচয়, শুধু টানেল উঠেছে তা নয়। কী হারালে বা ডিভাইস বদলালে উত্তর হলো প্রত্যাহার এবং নতুন ডিভাইস থেকে নতুন অনুরোধ; প্রশাসককে অন্য জায়গা থেকে কী ফেরত পাঠাতে বলা মূলটি পুনরুদ্ধার করে না এবং অনুরোধকে নিরাপদ করা মডেলটি চুপচাপ ভেঙে দেয়।