PKI ও সার্টিফিকেট — X.509, CA ট্রাস্ট চেইন
এই পাঠে যা শিখবেন
- PKI সমস্যাটা আসলে কী সমাধান করে — এবং কেন শুধু একটি পাবলিক কী পাঠানো যথেষ্ট নয়
- Certificate Authority (CA) ও X.509 সার্টিফিকেটের ভূমিকা
- Root CA → Intermediate CA → Leaf সার্টিফিকেট ট্রাস্ট চেইন কীভাবে যাচাই হয়
- এক্সপায়ার্ড, সেলফ-সাইনড বা অজানা CA-এর সার্টিফিকেটে ব্রাউজার কেন ওয়ার্নিং দেখায়
১ · সমস্যাটা কী — পাবলিক কী কার, তা কীভাবে জানবেন?
L35-এ আমরা দেখেছি অ্যাসিমেট্রিক এনক্রিপশনAsymmetric Encryptionপাবলিক ও প্রাইভেট — দুটি ভিন্ন কী ব্যবহার করে এনক্রিপশন। L35-এ বিস্তারিত কভার হয়েছে। কীভাবে key-distribution সমস্যা সমাধান করে: আপনি পাবলিক কী খোলাখুলি শেয়ার করতে পারেন। কিন্তু একটি নতুন সমস্যা তৈরি হয় — আপনি যে পাবলিক কী পেলেন, সেটা কি সত্যিই আপনার ব্যাংকের ওয়েবসাইটের, নাকি একজন আক্রমণকারী মাঝখানে বসে নিজের পাবলিক কী পাঠিয়ে দিয়েছে (একটি Man-in-the-MiddleMITMদুই পক্ষের মাঝে বসে যোগাযোগ গোপনে পড়া বা পরিবর্তন করা। L09-এ বিস্তারিত। পরিস্থিতি)? শুধু একটি পাবলিক কী দেখে সেটা যাচাই করার কোনো উপায় নেই — আপনার একটি বিশ্বস্ত তৃতীয় পক্ষের প্রয়োজন যে নিশ্চিত করবে "এই পাবলিক কী-টি সত্যিই এই ডোমেইনের।"
এই ঠিক সমস্যাটাই সমাধান করে PKIPublic Key Infrastructureপাবলিক কী, ডিজিটাল সার্টিফিকেট, Certificate Authority ও ট্রাস্ট চেইন — একসাথে মিলে একটি পরিচয়-যাচাই ব্যবস্থা তৈরি করে। — মানুষ, ডিভাইস ও সার্ভিসের পরিচয়কে পাবলিক কী-এর সাথে নির্ভরযোগ্যভাবে বেঁধে দেওয়ার একটি সম্পূর্ণ ব্যবস্থা।
২ · Certificate Authority (CA) ও X.509 সার্টিফিকেট
একটি Certificate Authority (CA)Certificate Authorityএকটি বিশ্বস্ত প্রতিষ্ঠান যারা একটি পরিচয়ের দাবি যাচাই করে এবং একটি ডিজিটাল সার্টিফিকেটে নিজের প্রাইভেট কী দিয়ে স্বাক্ষর করে। এমন একটি বিশ্বস্ত প্রতিষ্ঠান যাদের কাজ হলো — একটি ওয়েবসাইট বা সংস্থার পরিচয় যাচাই করে, তাদের পাবলিক কী-কে সেই পরিচয়ের সাথে বেঁধে একটি X.509 সার্টিফিকেটX.509ডিজিটাল সার্টিফিকেটের একটি স্ট্যান্ডার্ড ফরম্যাট — এতে থাকে ডোমেইন নাম, পাবলিক কী, মেয়াদ, এবং জারিকারী CA-এর ডিজিটাল স্বাক্ষর। তৈরি করে, এবং তাতে নিজের প্রাইভেট কী দিয়ে ডিজিটালি স্বাক্ষর করে (ডিজিটাল সিগনেচার — L36 দ্রষ্টব্য)। যে কেউ CA-এর পাবলিক কী দিয়ে এই স্বাক্ষর যাচাই করতে পারে, নিশ্চিত করতে পারে যে সার্টিফিকেটটি সত্যিই সেই CA দিয়ে জারি হয়েছে এবং পরে পরিবর্তিত হয়নি।
ডোমেইন নাম, পাবলিক কী, মেয়াদ (শুরু ও শেষ তারিখ), জারিকারী CA-এর নাম, এবং CA-এর ডিজিটাল স্বাক্ষর।
সবচেয়ে উপরের বিশ্বস্ত সত্তা। এদের সার্টিফিকেট ব্রাউজার ও অপারেটিং সিস্টেমে আগে থেকেই ইনস্টল করা থাকে।
Root CA সরাসরি প্রতিটি ওয়েবসাইটের সার্টিফিকেট সাইন করে না (নিরাপত্তার জন্য) — বরং একটি Intermediate CA-কে অনুমোদন দেয়, যে বাস্তবে সাইনিং করে।
৩ · ট্রাস্ট চেইন — Root থেকে Leaf পর্যন্ত
যখন আপনার ব্রাউজার একটি ওয়েবসাইটে সংযুক্ত হয়, সার্ভার তার নিজের ("Leaf") সার্টিফিকেট পাঠায়। ব্রাউজার সরাসরি সেটা বিশ্বাস করে না — বরং উপরের দিকে হাঁটে: Leaf সার্টিফিকেট কে সাইন করেছে? সেই Intermediate CA-কে কে সাইন করেছে? এভাবে চলতে চলতে যদি ব্রাউজার একটি এমন Root CA-তে পৌঁছায় যা তার নিজের বিশ্বস্ত-রুট তালিকায় আগে থেকেই আছে, তাহলে পুরো চেইন বিশ্বস্ত বলে গণ্য হয়। যদি চেইন কোথাও ভেঙে যায় — কোনো অজানা জারিকারীতে দাঁড়িয়ে যায়, বা একটি সার্টিফিকেট নিজেই নিজেকে সাইন করেছে (self-signed) অথচ Root তালিকায় নেই — তাহলে ব্রাউজার সেটা অবিশ্বস্ত ধরে নেয় এবং ব্যবহারকারীকে সতর্ক করে।
সার্টিফিকেটের একটি মেয়াদ থাকে — মেয়াদ পার হয়ে গেলে ব্রাউজার আর নিশ্চিত থাকতে পারে না যে সংশ্লিষ্ট প্রাইভেট কী-টি এখনো নিরাপদ (compromise হয়নি)। একইভাবে, একটি self-signed সার্টিফিকেট (যেখানে কোনো সার্টিফিকেট নিজেই নিজের জারিকারী) কোনো স্বাধীন তৃতীয় পক্ষের যাচাই বহন করে না — তাই ব্রাউজার একে ডিফল্টভাবে অবিশ্বস্ত ধরে (ডেভেলপমেন্ট/টেস্ট পরিবেশে ইচ্ছাকৃতভাবে ব্যবহার করা ছাড়া)। দুটো ক্ষেত্রেই ব্রাউজারের ওয়ার্নিং উপেক্ষা করা মানে আপনি নিশ্চিত হতে পারছেন না যে আপনি সত্যিই সঠিক পক্ষের সাথে কথা বলছেন।
৪ · কোড: একটি ট্রাস্ট চেইন সিমুলেশন
নিচের কোডটি একটি সরল, ইন-মেমরি সার্টিফিকেট চেইন সিমুলেট করে — প্রতিটি সার্টিফিকেট কার দ্বারা সাইন হয়েছে তা একটি
dictionary-তে রাখা আছে। verify_chain() ফাংশনটি ঠিক ব্রাউজারের যুক্তি অনুসরণ করে: উপরের দিকে হাঁটতে
থাকে, যতক্ষণ না একটি বিশ্বস্ত রুটে পৌঁছায় বা একটি ডেড-এন্ডে আটকে যায়।
chain = {
"abcltech.com": "Intermediate CA - SecureNet",
"Intermediate CA - SecureNet": "Root CA - GlobalTrust",
"Root CA - GlobalTrust": "Root CA - GlobalTrust", # রুট নিজেই নিজের জারিকারী
"evil-lookalike.com": "evil-lookalike.com", # সেলফ-সাইনড, কোনো CA নেই
}
trusted_roots = {"Root CA - GlobalTrust"}
def verify_chain(cert_name, chain, trusted_roots, max_hops=10):
current = cert_name
path = [current]
for _ in range(max_hops):
if current in trusted_roots:
return True, path
issuer = chain.get(current)
if issuer is None or issuer == current:
return False, path # ডেড-এন্ড বা সেলফ-সাইনড, বিশ্বস্ত রুটে পৌঁছায়নি
current = issuer
path.append(current)
return False, path
ok1, path1 = verify_chain("abcltech.com", chain, trusted_roots)
ok2, path2 = verify_chain("evil-lookalike.com", chain, trusted_roots)
print("abcltech.com এর চেইন: ", " -> ".join(path1))
print("যাচাই ফলাফল: ", "বিশ্বস্ত" if ok1 else "অবিশ্বস্ত")
print()
print("evil-lookalike.com এর চেইন:", " -> ".join(path2))
print("যাচাই ফলাফল: ", "বিশ্বস্ত" if ok2 else "অবিশ্বস্ত")
evil-lookalike.com নিজেই নিজের জারিকারী হওয়ায় (self-signed), কোনো বিশ্বস্ত Root-এ
পৌঁছানোর কোনো পথ নেই, তাই verify_chain সঠিকভাবে এটাকে অবিশ্বস্ত চিহ্নিত করে। এটাই ঠিক
সেই যুক্তি যা আপনার ব্রাউজার প্রতিটি HTTPS সংযোগে নীরবে চালায়।
৫ · আক্রমণকারী ও রক্ষক — উভয় দৃষ্টিকোণ
একজন আক্রমণকারী একটি ভুয়া/অবৈধ সার্টিফিকেট ব্যবহার করে একটি সাইট নকল করার চেষ্টা করতে পারে (উদাহরণ:
paypa1.com-এর জন্য একটি self-signed বা অবৈধভাবে প্রাপ্ত সার্টিফিকেট) — কিন্তু যেহেতু কোনো বৈধ CA
সেটিকে সাইন করেনি, ব্রাউজার ওয়ার্নিং দেখাবে। রক্ষক হিসেবে, প্রতিষ্ঠানগুলো নিশ্চিত করে যে তাদের সার্টিফিকেট মেয়াদ
শেষ হওয়ার আগেই রিনিউ হয় (মেয়াদ শেষ হওয়া মানেই ব্যবহারকারীর সামনে একটি অপ্রয়োজনীয় সতর্কবার্তা, যা ব্যবহারকারীদের
"সব ওয়ার্নিং উপেক্ষা করার" অভ্যাস তৈরি করে দিতে পারে — নিজেই একটি নিরাপত্তা ঝুঁকি)। এথিক্যাল হ্যাকিং টেস্টিং-এ,
সার্টিফিকেট ভ্যালিডেশন ভুলভাবে বাইপাস করা হয়েছে কি না (যেমন একটি অ্যাপ যা সব সার্টিফিকেট ওয়ার্নিং উপেক্ষা করে) তা
যাচাই করা একটি সাধারণ ও গুরুত্বপূর্ণ পরীক্ষার আইটেম — কিন্তু শুধুমাত্র লিখিত অনুমতিসহ, নিজের বা অনুমোদিত
পরিবেশে।
PKI একটি একক প্রযুক্তি নয় — এটি একটি বিশ্বাসের ব্যবস্থা। একটি পাবলিক কী কার্যকর তখনই যখন কেউ প্রমাণ করতে পারে সেটা সত্যিই যার দাবি করা হচ্ছে তার-ই — এবং এই কাজটাই CA, X.509 সার্টিফিকেট ও ট্রাস্ট চেইন মিলে করে। পরবর্তী পাঠে (L38) আমরা দেখব এই সার্টিফিকেট যাচাই ঠিক কোথায় TLS হ্যান্ডশেকের মধ্যে ঘটে।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ Root CA কেন সরাসরি প্রতিটি ওয়েবসাইটের সার্টিফিকেট সাইন করে না — কেন মাঝখানে একটি Intermediate CA থাকে?
Root CA-এর প্রাইভেট কী পুরো ইন্টারনেটের বিশ্বাসের ভিত্তি — যদি সেটি কোনোভাবে compromise হয়, লক্ষ লক্ষ সার্টিফিকেট প্রশ্নবিদ্ধ হয়ে যায়। তাই Root-কে অফলাইনে, চরম নিরাপত্তায় রাখা হয় এবং শুধু কালেভদ্রে ব্যবহার করা হয় (মূলত Intermediate CA-দের অনুমোদন দিতে)। দৈনন্দিন সাইনিং কাজ Intermediate CA করে — যদি একটি Intermediate CA compromise হয়, শুধু সেটিকে বাতিল (revoke) করলেই হয়, পুরো Root বাতিল করতে হয় না। এটি ঝুঁকি বিভাজনের একটি ক্লাসিক নিরাপত্তা কৌশল।
প্র ০২ একটি সার্টিফিকেট মেয়াদোত্তীর্ণ হয়ে গেলে ডেটা এনক্রিপশন কি হঠাৎ দুর্বল হয়ে যায়? তাহলে ব্রাউজার কেন ওয়ার্নিং দেখায়?
না, এনক্রিপশন অ্যালগরিদম নিজে হঠাৎ দুর্বল হয় না। সমস্যাটা পরিচয় যাচাই নিয়ে — মেয়াদ শেষ হওয়া সার্টিফিকেট মানে CA আর নিশ্চয়তা দিচ্ছে না যে সংশ্লিষ্ট প্রাইভেট কী-টি এখনো নিরাপদে আছে বা এই ডোমেইনের মালিকানা এখনো একই আছে। ব্রাউজার তাই সতর্ক করে কারণ পরিচয়ের নিশ্চয়তা (authentication) হারিয়ে গেছে — যদিও গাণিতিক এনক্রিপশন এখনো "কাজ করবে," আপনি নিশ্চিত থাকতে পারছেন না যে আপনি সঠিক পক্ষের সাথেই এনক্রিপ্টেড যোগাযোগ করছেন।
প্র ০৩ একটি অভ্যন্তরীণ কোম্পানি টুলের জন্য নিজস্ব self-signed সার্টিফিকেট ব্যবহার করা কি সবসময় খারাপ?
না — অভ্যন্তরীণ, নিয়ন্ত্রিত পরিবেশে (যেমন ডেভেলপমেন্ট/টেস্টিং সার্ভার, বা একটি প্রতিষ্ঠানের নিজস্ব প্রাইভেট CA যা সব কর্মীর ডিভাইসে ম্যানুয়ালি বিশ্বস্ত হিসেবে ইনস্টল করা আছে) self-signed বা প্রাইভেট-CA সার্টিফিকেট সম্পূর্ণ যুক্তিসঙ্গত এবং নিরাপদ। সমস্যাটা তখনই হয় যখন এটি পাবলিক ইন্টারনেটে সাধারণ ব্যবহারকারীদের সামনে থাকে — তখন তাদের কোনো উপায় নেই যাচাই করার যে সার্টিফিকেটটি প্রকৃত মালিকের, কারণ কোনো স্বাধীন তৃতীয় পক্ষ যাচাই করেনি।
অনুশীলন
-
চিন্তা করুন: উপরের কোড সেলে
chaindictionary-তে একটি নতুন এন্ট্রি যোগ করুন —"fake-bank.com": "Intermediate CA - SecureNet"— কিন্তুtrusted_rootsথেকে"Root CA - GlobalTrust"সরিয়ে দিন। এখনverify_chain("fake-bank.com", ...)চালালে ফলাফল কী হবে বলে মনে করেন?ফলাফল অবিশ্বস্ত হবে — চেইনটি এখনো ঠিক আগের মতোই Root CA পর্যন্ত হাঁটবে, কিন্তু যেহেতু
trusted_rootsসেট থেকে সেই Root সরিয়ে দেওয়া হয়েছে, লুপ কখনোcurrent in trusted_rootsশর্তে True পাবে না — সব হপ শেষ হয়ে যাবে এবং ফাংশনFalseরিটার্ন করবে। এটি দেখায় যে চেইন নিজে ঠিক থাকলেও, রুট বিশ্বস্ত না হলে পুরো যাচাই ব্যর্থ হয়। -
পরীক্ষা করুন:
max_hops-এর মান1-এ নামিয়েverify_chain("abcltech.com", ...)চালান — এবার ফলাফল কী হয় এবং কেন?ফলাফল অবিশ্বস্ত হবে, যদিও চেইনটি বাস্তবে বৈধ। কারণ
max_hops=1মানে লুপ মাত্র একবার চলবে, আর একবারেই "abcltech.com" থেকে "Intermediate CA"-তে পৌঁছানো যাবে, কিন্তু Root CA-তে পৌঁছানোর জন্য আরও একটি হপ দরকার ছিল যা আর হয়নি। এটি বাস্তব-জীবনের একটি গুরুত্বপূর্ণ শিক্ষা: একটি চেইন ভ্যালিডেটরকে যথেষ্ট গভীরতা পর্যন্ত হাঁটতে দিতে হয়, নাহলে বৈধ চেইনও ভুলভাবে প্রত্যাখ্যাত হতে পারে।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৬০টি পাঠ পরবর্তী পাঠ: TLS হ্যান্ডশেক গভীরভাবে — এখানেই এই সার্টিফিকেট চেইন বাস্তবে কাজে লাগে।
- Discrete Mathematics কোর্স সহায়ক কোর্স RSA ও মডুলার এক্সপোনেনশিয়েশনের গণিত শিখতে দেখুন — অ্যাসিমেট্রিক ক্রিপ্টোগ্রাফির ভিত্তি।
- System Design & Software Architecture কোর্স সঙ্গী কোর্স এনক্রিপশন, অথেন্টিকেশন ও লগিং কীভাবে বড় সিস্টেমে প্রয়োগ হয় তা শিখতে দেখুন।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design ও Cybersecurity — সব এক জায়গায়।