Engineer-এর জন্য Cryptography: Key, Certificate ও CA

এই Lesson শেষে তুমি পারবে

• Cryptography-র চারটা লক্ষ্য (Confidentiality, Integrity, Authenticity, Non-repudiation) বলতে, আর প্রতিটার জন্য ঠিক হাতিয়ার বাছতে: Encryption, Hash, HMAC নাকি Signature।
• Symmetric Encryption (AES-GCM, ChaCha20-Poly1305, AEAD, Nonce) বোঝাতে, আর কেন এর Key ভাগ করার একটা উপায় লাগে তা বলতে।
• Public-key Cryptography (RSA, Elliptic Curve) বোঝাতে: Public Key দিয়ে Encrypt, Private Key দিয়ে Sign, আর এটা কেন ধীর।
• রং মেশানোর ছবি দিয়ে Diffie–Hellman Key Exchange বোঝাতে, এর সাথে কেন Authentication লাগে, আর Forward Secrecy কী রক্ষা করে তা বলতে।
• Hash আর HMAC ঠিকভাবে ব্যবহার করতে: Download যাচাই, Webhook যাচাই, HS256 বনাম RS256 Token।
• HTTPS আসলে এই টুকরোগুলো কীভাবে জোড়া দেয় (Hybrid Cryptography, TLS 1.3 অনুযায়ী সংশোধিত) তা বোঝাতে।
• একটা X.509 Certificate পড়তে, Leaf থেকে Root পর্যন্ত Chain of Trust ধরে হাঁটতে, আর মেয়াদ শেষ, হারানো Intermediate, অচেনা Root, ভুল নাম ধরনের সমস্যা ধরতে।
• Revocation (CRL, OCSP, Stapling, আর Let’s Encrypt কেন OCSP ছাড়ল), Certificate Transparency, ACME দিয়ে স্বয়ংক্রিয়তা, ৪৭ দিনের Certificate-এর দিকে যাত্রা, Private CA, Key Management আর Post-quantum Key Exchange বোঝাতে।

#এই Lesson কোথায় বসে

Browser-এ যতবার https:// দেখো, Cryptography একসাথে তিনটা কাজ করছে: Data লুকাচ্ছে, প্রমাণ করছে পথে কিছু বদলায়নি, আর প্রমাণ করছে ওপাশে আসলে কে। Lesson ১.৯-এ আমরা TLS-কে বাইরে থেকে দেখেছি: তার তিনটা নিশ্চয়তা, রং মেশানোর কৌশল, TLS 1.3 Handshake আর Certificate-এর প্রথম ঝলক। Lesson ১.৩-এ Cookie আর JWT Sign হয়েছিল HMAC দিয়ে, আর Lesson ১.১২-এ Zero Trust-এর জন্য Mutual TLS দেখেছি। এই Lesson সেই যন্ত্রপাতির বাক্সটা খোলে: মূল উপাদানগুলো (Key, Cipher, Hash, MAC, Signature) আর তার ওপর দাঁড়ানো বিশ্বাসের ব্যবস্থা (Certificate, CA, Chain, Revocation, Automation)।

পরের Lesson ২.৮ এই টুকরোগুলো Message ধরে ধরে জোড়া দেবে: TLS 1.2 বনাম TLS 1.3 Handshake আর Mutual TLS। Password জমা রাখা (ধীর, Salt দেওয়া Hashing) আর বড় পরিসরে Key সামলানো আছে Chapter ৩৪-এ।

শুরুতে দুটো শব্দ। Encryption একটা Key দিয়ে পড়া যায় এমন Data (Plaintext)-কে পড়া যায় না এমন Data (Ciphertext)-এ বদলায়; Decryption সেটা আবার ফিরিয়ে আনে। তুমি যখন কোনো নিরাপদ Website-এ Password টাইপ করো, সেটা তোমার Laptop থেকে বের হয় Ciphertext হয়ে। বইয়ে Encryption-কে OSI-র Presentation Layer-এ বসানো হয়, কিন্তু বাস্তব Internet-এ এটা করে TLS, যেটা বসে Application আর TCP-র মাঝখানে (Lesson ১.৫ বুঝিয়েছে কেন ওই Layer-এর তকমা শুধু বইয়ের হিসাব)।

#Cryptography কী কাজে লাগে: চারটা লক্ষ্য

নিরাপত্তার আরেকটা পুরনো লক্ষ্য Availability; Cryptography এটা দেয় না, উল্টো ক্ষতিও করতে পারে (মেয়াদ শেষ হওয়া Certificate মানেই বিভ্রাট)। বাকি সবকিছুর কাঠামো দুটো নিয়মে:

• Kerckhoffs-এর নীতি: Algorithm সবার জানা, গোপন শুধু Key। AES, RSA, SHA-256 প্রকাশিত, হাজারো মানুষ এগুলো খুঁটিয়ে দেখেছে; যে System গোপন Algorithm-এর ওপর ভরসা করে, সে আসলে ভাগ্যের ওপর ভরসা করছে।
• নিজের Cryptography নিজে বানিয়ো না। চলন্ত Data-র জন্য TLS, আর বাকি সবকিছুর জন্য ভালোভাবে যাচাই হওয়া Library (তোমার Platform-এর TLS, libsodium, Go-র crypto, Google-এর Tink) ব্যবহার করো। বাস্তবে বেশিরভাগ ভাঙন উপাদানে না, উপাদানগুলো জোড়া দেওয়ার ভুলে।

#Symmetric Encryption: একটাই ভাগ করা Key

Symmetric Encryption-এ একই গোপন Key দিয়ে তালা দেওয়া আর খোলা হয়:

Plaintext ──(Key K)──▶ Ciphertext ──(একই Key K)──▶ Plaintext

• দ্রুত আর সস্তা। আধুনিক CPU-তে AES-এর জন্য আলাদা Instruction আছে (x86-এ AES-NI, বেশিরভাগ ফোনের Chip-এও একই রকম), তাই একটা Core সেকেন্ডে কয়েক Gigabyte Encrypt করে। এজন্যই সব বড় Data (Web Page, Video, Database File, Backup) Symmetric ভাবে Encrypt হয়।
• Key-এর আকার: ১২৮ বা ২৫৬ bit। ২¹²⁸টা Key সব চেষ্টা করা কোনোদিন বানানো যাবে এমন কোনো Computer-এরও সাধ্যের বাইরে; ভবিষ্যতের Quantum Computer-এর বিরুদ্ধেও ২৫৬-bit Key নিশ্চিন্ত।
• দুর্বলতা: দুই পাশেরই একই Key লাগে, অথচ যে Network রক্ষা করতে চাইছ, সেটা দিয়েই Key পাঠানো যায় না। এটাই Key Distribution সমস্যা, আর এটা বড় হলে খারাপ হয়: n জন সবাই সবার সাথে গোপনে কথা বললে n(n−1)/2টা Key লাগে, ১,০০০ জনের জন্য প্রায় পাঁচ লাখ।

#যেসব Algorithm-এর দেখা পাবে

#AEAD: যে Encryption কারসাজিও ধরে

সাধারণ Encryption শুধু Data লুকায়। পুরনো Mode-এ আক্রমণকারী বার্তা পড়তে না পারলেও Ciphertext-এর Bit উল্টে Plaintext-এর সেই Bit-গুলোই উল্টে দিতে পারে, Key ছাড়াই “৫০০”-কে “৯০০” বানিয়ে। AEAD (Authenticated Encryption with Associated Data) এটা সারায়: AES-GCM আর ChaCha20-Poly1305 Ciphertext-এর সাথে একটা ১৬ Byte-এর Tag দেয়, যেটা হিসাব হয় Key আর Ciphertext-এর প্রতিটা Bit থেকে। একটা Bit বদলালেই পুরো Decryption ব্যর্থ। “Associated Data” হলো বাড়তি তথ্য (যেমন একটা Record Header), যেটা গোপন না কিন্তু Tag-এর আওতায়। TLS 1.3 শুধু AEAD Cipher চালাতে দেয়।

AEAD-এর প্রতিটা বার্তায় একটা Nonce (একবারই ব্যবহার হয় এমন নম্বর) লাগে, সাধারণত ৯৬ bit-এর। একই Key-এর সাথে Nonce আবার ব্যবহার করা GCM-এর জন্য সর্বনাশ: আক্রমণকারী দুটো Ciphertext মিলিয়ে Encryption কেটে ফেলতে পারে, Tag-ও জাল করতে পারে। Counter বা এলোমেলো Nonce নাও, ২³²টা বার্তার অনেক আগেই Key বদলাও, আর এমন Library বেছে নাও যেটা Nonce নিজেই সামলায় (TLS Record নম্বর থেকে Nonce বানায়)।

#Asymmetric (Public-key) Cryptography

Asymmetric Cryptography-তে একসাথে বানানো একটা Key Pair থাকে: একটা Public Key, যেটা যে কারো কাছে থাকতে পারে, আর একটা Private Key, যেটা মালিকের কাছ থেকে কখনো সরে না। দুটো গণিত দিয়ে যুক্ত, কিন্তু Public Key থেকে Private Key হিসাব করা যায় না। জোড়াটা দুই উল্টো দিকে কাজ করে:

Encryption:  Plaintext ──(Bob-এর PUBLIC Key)──▶ Ciphertext ──(Bob-এর PRIVATE Key)──▶ Plaintext
Signature:   Message   ──(Bob-এর PRIVATE Key)──▶ Signature ──(Bob-এর PUBLIC Key)──▶ বৈধ / অবৈধ

• Encryption: যে কেউ Bob-এর Public Key দিয়ে তার জন্য একটা বার্তায় তালা দিতে পারে; খুলতে পারে শুধু Bob। আগে থেকে কোনো গোপন কথা ভাগ করতে হয়নি।
• Signature: Private Key দিয়ে Sign করতে পারে শুধু Bob; Public Key দিয়ে যে কেউ Verify করতে পারে। Authenticity আর Non-repudiation আসে এখান থেকেই।

#কেন ধীর, আর তাতে কেন সমস্যা নেই

নোটে আছে Public-key কাজ Symmetric-এর চেয়ে প্রায় ১,০০০ গুণ ধীর। মাত্রার হিসাবে ঠিক; আসল অনুপাত কাজভেদে আলাদা। আধুনিক একটা Core-এ RSA-2048-এর একটা Signature-এ প্রায় এক Millisecond লাগে, Elliptic Curve-এর একটা কাজে কয়েক দশ Microsecond, অথচ AES-GCM এক Megabyte সারে এক Millisecond-এর অনেক কমে। গতির চেয়েও বড় দুটো সীমা আছে: RSA-2048 একবারে বড়জোর প্রায় ১৯০ Byte Encrypt করতে পারে, আর Ciphertext Key-এর সমান লম্বা। তাই Public-key Cryptography কখনো বড় Data-র জন্য ব্যবহার হয় না। এর কাজ একটা ছোট Symmetric Key-তে একমত হওয়া বা সেটা পৌঁছে দেওয়া, আর Sign করা। এই জোড়াটাই Hybrid Cryptography, নিচে আছে।

#Key Exchange: Diffie–Hellman আর Forward Secrecy

প্রাপকের Public Key দিয়ে একটা নতুন Key Encrypt করে পাঠানো চলে, কিন্তু ভাগ করা Key পাওয়ার আরও ভালো উপায় আছে: দুই পাশ Key-টা কখনো না পাঠিয়ে নিজেরাই হিসাব করে বের করুক। এটাই Diffie–Hellman Key Exchange (১৯৭৬), আর এর Ephemeral Elliptic-curve রূপ ECDHE দিয়েই TLS 1.3 Connection তাদের Key-তে একমত হয়।

খেলনা সংখ্যা দিয়ে দেখি (Public Prime p = 23, Base g = 5):

1. Browser গোপন a = 6 বেছে পাঠায় A = 5⁶ mod 23 = 8।
2. Server গোপন b = 15 বেছে পাঠায় B = 5¹⁵ mod 23 = 19।
3. Browser হিসাব করে 19⁶ mod 23 = 2; Server হিসাব করে 8¹⁵ mod 23 = 2। একই Secret।
4. আড়িপাতা লোক দেখেছে 23, 5, 8 আর 19। এগুলো থেকে a বা b ফেরত পাওয়া হলো Discrete Logarithm সমস্যা: p = 23 হলে সহজ, X25519-এর ২৫৫-bit সংখ্যায় আশাহীন।

Lesson ১.৯ এটা বলেছিল রং মেশানো দিয়ে: সবার জানা একটা মূল রং, দুজনের একটা করে গোপন রং, মিশ্রণ অদলবদল, তারপর আবার নিজের গোপন রং যোগ, আর দুই পাশে একই শেষ রং, অথচ দর্শক মিশ্রণ “আলাদা” করতে পারে না। ভাগ করা Secret-টা তারপর একটা Key-derivation Function-এ যায়, যেটা একে টেনে প্রতিটা দিকের জন্য আসল AES Key বানায়।

Diffie–Hellman হলো Key Agreement, Encryption না: এটা দিয়ে কিছুই Encrypt হয় না। আর একা এর একটা ফাঁক আছে: এটা শুধু যারা শোনে তাদের থেকে বাঁচায়, যে বার্তা বদলাতে পারে তার থেকে না। সক্রিয় আক্রমণকারী দুই পাশের সাথে আলাদা দুটো Exchange চালিয়ে মাঝখানে বসে যেতে পারে। TLS ফাঁকটা বন্ধ করে Server-কে দিয়ে Handshake Sign করিয়ে, তার Key Share সহ, Certificate-এর Private Key দিয়ে। তাই কাজের ভাগ পরিষ্কার: ECDHE দেয় Secret, Signature আর Certificate দেয় পরিচয়।

#Forward Secrecy

পুরনো TLS 1.2-এর “RSA Key Exchange”-এ Browser Session Secret বেছে নিয়ে Server-এর দীর্ঘমেয়াদি Public Key দিয়ে Encrypt করত। যে Traffic রেকর্ড করে রেখেছে আর পরে ওই Private Key পেয়েছে (ফাঁস হওয়া Backup, ২০১৪-র Heartbleed-এর মতো Bug, আদালতের আদেশ), সে রেকর্ড করা প্রতিটা Session খুলে ফেলতে পারত।

Ephemeral Diffie–Hellman-এ (ECDHE-এর E) প্রতিটা Connection নতুন এলোমেলো Secret নেয়, Handshake শেষে সেগুলো মুছে ফেলা হয়। Certificate-এর Key শুধু Sign করে। পরে সেটা চুরি করলে আক্রমণকারী তখন থেকে Server সাজতে পারে (Certificate বাতিল বা মেয়াদ শেষ না হওয়া পর্যন্ত), কিন্তু অতীত খুলতে পারে না। এই বৈশিষ্ট্যের নাম Forward Secrecy। TLS 1.3 (২০১৮) RSA Key Exchange পুরোপুরি বাদ দিয়েছে, তাই প্রতিটা পূর্ণ TLS 1.3 Handshake-এ এটা আছে।

#Hashing: আঙুলের ছাপ, Encryption না

SHA-256-এর মতো Cryptographic Hash Function যেকোনো Input-কে নির্দিষ্ট মাপের একটা Digest-এ বদলায় (৩২ Byte, Hex-এ ৬৪ অক্ষর):

SHA-256("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

ভালো Hash হলো:

• নির্দিষ্ট (Deterministic): একই Input, একই Output, সবখানে।
• নির্দিষ্ট মাপ আর দ্রুত: ৪ GB-র File আর একটা শব্দ, দুটোই দেয় ৩২ Byte, সেকেন্ডে এক Gigabyte-এর বেশি গতিতে।
• Avalanche: Input-এর একটা Bit বদলালে Output-এর প্রায় অর্ধেক Bit বদলে যায়।
• একমুখী (Preimage Resistant): একটা Hash দেখে তার Input খুঁজে বের করা যায় না।
• Collision Resistant: একই Hash-ওয়ালা দুটো আলাদা Input কেউ খুঁজে পায় না।

System-এ এর ব্যবহার সবখানে: Download যাচাই, Content Addressing (Git, sha256:… ধরনের Container Image Digest), Deduplication, Cache Key আর ETag, Merkle Tree (Certificate Transparency, Blockchain), আর প্রতিটা Signature-এর প্রথম ধাপ (পুরো File না, তুমি Sign করো তার Hash)।

নিরাপত্তার জন্য MD5 আর SHA-1 ভাঙা: MD5-এর Collision কয়েক সেকেন্ডের কাজ, আর ২০১৭ সালে গবেষকেরা একই SHA-1-ওয়ালা দুটো আলাদা PDF প্রকাশ করেন। ২০১২ সালে Flame Malware MD5 Collision দিয়ে একটা Code-signing Certificate জাল করেছিল। SHA-256, SHA-384 বা SHA-3 ব্যবহার করো।

দুটো সীমা মনে রাখো:

1. Hash-এ কোনো Key নেই, তাই এটা Encryption না, আর Data কে বানিয়েছে সে সম্পর্কে এটা কিছুই প্রমাণ করে না। যে আক্রমণকারী File বদলায়, সে Hash-ও আবার হিসাব করে নিতে পারে। Hash তখনই Integrity রক্ষা করে, যখন Hash-টা নিজে এমন পথে আসে যেটা আক্রমণকারী ছুঁতে পারে না।
2. Password-এর জন্য বিশেষ Hashing লাগে। দ্রুত Hash থাকলে আক্রমণকারী GPU দিয়ে সেকেন্ডে শত কোটি অনুমান যাচাই করতে পারে। Password রাখা হয় ইচ্ছা করে ধীর, Salt দেওয়া Function দিয়ে (Argon2id, scrypt, bcrypt); সেটা Chapter ৩৪-এ।

#Message Authentication Code আর HMAC

ভাগ করা Secret দিয়ে Integrity আর উৎস দুটোই প্রমাণ করতে চাইলে Key-টা Hash-এর মধ্যে মিশিয়ে দাও। ফল হলো একটা Message Authentication Code, ছোট একটা Tag, যেটা শুধু Key-ধারীরাই হিসাব করতে পারে। আদর্শ গঠনটা হলো HMAC (Hash-based Message Authentication Code), যেমন HMAC-SHA256: এটা Key আর বার্তাকে দুই স্তরে Hash করে। নিজে কখনো SHA-256(Secret + বার্তা) বানিয়ো না: SHA-256-এ Length Extension সম্ভব, মানে যে এমন একটা Hash জানে, সে Secret না জেনেই আরও লম্বা বার্তার বৈধ মান বানাতে পারে। HMAC-এ এই সমস্যা নেই।

#Webhook: রোজকার HMAC

Payment Provider বা GitHub যখন তোমার Webhook Endpoint ডাকে, তুমি কীভাবে জানবে Request-টা আসল? তারা দুজনের জানা একটা Secret দিয়ে এটা Sign করে:

• GitHub পাঠায় X-Hub-Signature-256: sha256=<hex HMAC of the body>।
• Stripe পাঠায় Stripe-Signature: t=<timestamp>,v1=<hmac of "timestamp.body">।

ঠিকভাবে যাচাই করতে পাঁচটা নিয়ম:

1. HMAC হিসাব করো যে Raw Byte এসেছে তার ওপর, কোনো JSON Parse-এর আগে; আবার String বানানো JSON-এর Byte আলাদা।
2. তুলনা করো Constant-time Function দিয়ে (hmac.compare_digest, crypto.timingSafeEqual), যাতে উত্তরের সময় দেখে বোঝা না যায় কয়টা অক্ষর মিলেছে।
3. Sign করা Data-র ভেতরে একটা Timestamp রাখো, আর কয়েক মিনিটের বেশি পুরনো সবকিছু বাতিল করো; এতে ধরে রাখা Request আবার পাঠানো (Replay) থামে।
4. Event ID জমিয়ে রাখো আর প্রতিটা Event একবারই চালাও: Provider আবার পাঠায়, আর HMAC উৎস প্রমাণ করে, নতুনত্ব না।
5. Secret রাখো Secret Manager-এ, আর বদলানোর সময় দুটো Secret একসাথে মেনে নাও।

#HMAC বনাম Signature, আর JWT-এর Algorithm

Lesson ১.৩-এর JWT-এর পছন্দটা ঠিক এটাই। HS256-এ Token যাচাই করে এমন প্রতিটা Service-এর কাছে Secret থাকে, তাই এদের যেকোনো একটা (বা যেকোনো একটা থেকে ফাঁস) সবার জন্য Token বানাতে পারে। RS256 বা ES256-এ Private Key থাকে শুধু Identity Service-এর কাছে, সে Public Key প্রকাশ করে (প্রায়ই JWKS Document হিসেবে); দখল হয়ে যাওয়া একটা API Service Token যাচাই করতে পারে, জাল করতে পারে না। যাচাইয়ের সময় প্রত্যাশিত Algorithm সবসময় বেঁধে দাও: যেসব Library Token-এর নিজের alg Header বিশ্বাস করত, তারা একসময় none মেনে নিয়েছিল, বা RSA Public Key-কে HMAC Secret হিসেবে ধরে নিয়েছিল।

#Digital Signature

Sign করতে প্রেরক বার্তার Hash নেয়, তারপর Private Key দিয়ে সেই Hash-এর ওপর Signing Algorithm চালায়। Verify করতে যে কেউ Public Key, বার্তা আর Signature নিয়ে Verification Algorithm চালায়, ফল আসে “বৈধ” বা “অবৈধ”। বৈধ Signature প্রমাণ করে বার্তাটা ওই Private Key-এর মালিক Sign করেছে, আর তারপর থেকে এটা বদলায়নি।

Internet-এর কোথায় কোথায় Signature কাঁধ দিয়ে আছে: Certificate (একটা CA Server-এর Key আর নাম Sign করে), TLS Handshake (CertificateVerify প্রমাণ করে Key-টা কাছে আছে), Operating System আর App Update, Package Manager, Code Signing, Sign করা Git Commit, DNSSEC, আর RS256 বা ES256-ওয়ালা JWT।

বাস্তবে Signature যেভাবে ব্যর্থ হয়:

• খারাপ এলোমেলোতা। ECDSA-র প্রতিটা Signature-এ একটা নতুন গোপন এলোমেলো সংখ্যা লাগে। ২০১০ সালে একটা Game Console নির্মাতা একই সংখ্যা বারবার ব্যবহার করেছিল, আর শখের হ্যাকাররা দুটো Signature থেকেই তাদের Master Signing Key বের করে ফেলে। Ed25519 আর নির্দিষ্ট (Deterministic) ECDSA এই ফাঁদ সরিয়ে দেয়।
• চুরি যাওয়া Key। Signature প্রমাণ করে কোন Key Sign করেছে, কোন মানুষ না। Non-repudiation ঠিক ততটাই শক্ত, যতটা Key-এর সুরক্ষা; এজন্যই Signing Key থাকে HSM-এ।
• দুর্বল Hash। Signature ঢাকে Hash-কে; Hash-এ Collision থাকলে (MD5, SHA-1) Signature দুটো যমজ File-কেই ঢেকে দেয়।

#Hybrid Encryption: HTTPS আসলে সবকিছু কীভাবে ব্যবহার করে

HTTPS-এর নিরাপত্তা আর গতি দুটোই লাগে, তাই এটা Asymmetric আর Symmetric Cryptography মেশায়। নোটে দুটো ধাপের কথা আছে, মোটা দাগে সেটা ঠিক:

1. ধাপ ১, পরিচয় আর Key Exchange। Connection-এর শুরুতে Public-key Cryptography Server-এর পরিচয় প্রমাণ করে আর একটা নতুন Symmetric Session Key তৈরি করে।
2. ধাপ ২, বড় Data। Session Key তৈরি হয়ে গেলে আসল HTML, JSON আর Image যায় দ্রুত Symmetric AEAD দিয়ে Encrypt হয়ে (AES-GCM বা ChaCha20-Poly1305)।

সংশোধনটা হলো ধাপ ১ কীভাবে কাজ করে তাতে। জনপ্রিয় একটা ব্যাখ্যা বলে Browser Server-এর Public Key দিয়ে Session Key Encrypt করে পাঠায়। ওটা ছিল TLS 1.2-এর RSA Key Exchange, যাতে Forward Secrecy ছিল না, আর TLS 1.3 সেটা বাদ দিয়েছে। আজ:

TLS 1.3-এ Certificate-এর Key দিয়ে কখনো কিছু Encrypt হয় না; এটা শুধু Sign করে। “প্রাপকের Public Key দিয়ে একটা এলোমেলো Key Encrypt করো” বর্ণনাটা অন্য জায়গায় এখনো ঠিক: Encrypt করা Email আর File-এর Tool (PGP, age), আর Encrypted Client Hello যে Hybrid Public-key Encryption মানদণ্ড ব্যবহার করে। Lesson ২.৮ দুটো TLS Handshake-ই Message ধরে ধরে দেখাবে।

#Certificate: Public Key-কে একটা নামের সাথে বাঁধা

Public-key Cryptography সমস্যাটাকে “গোপন কথা ভাগ করা” থেকে সরিয়ে এনেছে “একটা Public Key বিশ্বাস করা”-তে: খালি Key বলে না সেটা কার। Certificate এটা সারায়। এটা একটা ডিজিটাল পাসপোর্ট: একটা দলিল, যাতে লেখা “এই Public Key www.example.com-এর, A তারিখ থেকে B তারিখ পর্যন্ত”, আর সেটা Sign করেছে এমন একটা Certificate Authority (CA), যাকে Browser আগে থেকেই বিশ্বাস করে। Web Certificate মানে X.509 মানদণ্ড (Version 3)। মানুষ এখনো বলে “SSL Certificate”; SSL নিজে দশ বছর আগেই মৃত, আর একই Certificate TLS ব্যবহার করে।

কাজের কথা:

• নাম মেলানো হয় শুধু Subject Alternative Name তালিকা দিয়ে; Chrome ২০১৭ সালে Common Name দেখা বন্ধ করেছে। Wildcard *.example.com ঠিক এক স্তর ঢাকে: www.example.com হ্যাঁ, example.com আর a.b.example.com না।
• File: PEM হলো -----BEGIN CERTIFICATE----- লাইনের মাঝে Base64 লেখা; DER হলো একই Data Binary-তে। Web Server-এর লাগে fullchain.pem (Leaf + Intermediate) আর Private Key File, যেটা শুধু Server পড়তে পারবে।
• Certificate প্রকাশ্য। এতে কোনো গোপন কিছু নেই; Private Key আলাদা একটা File, যেটা কখনো Server (বা তার HSM) ছাড়ে না।
• Certificate প্রমাণ করে নামটা কার নিয়ন্ত্রণে, সততা না: Phishing Site-ও বিনা পয়সায় Certificate পায়। তালা চিহ্ন মানে “তোমার Connection গোপনে এই নামের সাথে”, এর বেশি কিছু না।

#Chain of Trust

Browser লাখ লাখ Website Certificate সরাসরি বিশ্বাস করে না। সে বিশ্বাস করে একটা Trust Store-এ রাখা ছোট একটা Root CA তালিকা, আর বিশ্বাস নেমে আসে একটা Chain ধরে:

Root CA (নিজেই নিজেকে Sign করা, Trust Store-এ, Private Key Offline)
   │ Sign করে
   ▼
Intermediate CA (Online, প্রতি সেকেন্ডে Certificate দেয়)
   │ Sign করে
   ▼
Leaf Certificate: www.example.com (Server পাঠায়)

যাচাই করতে Client Leaf থেকে তার বিশ্বস্ত একটা Root পর্যন্ত একটা পথ বানায় আর প্রতিটা কড়া যাচাই করে:

1. প্রতিটা Certificate-এর Signature ওপরেরটার Public Key দিয়ে মেলে।
2. প্রতিটা আজ মেয়াদের ভেতরে, Intermediate সহ।
3. Leaf-এর ওপরের প্রতিটা Certificate-এ CA:TRUE আছে, মানে Sign করার অনুমতি আছে।
4. Leaf-এর নাম Client যে Host-এ Connect করেছে তার সাথে মেলে, আর এর ব্যবহার Server Authentication।
5. পথের কিছুই বাতিল (Revoked) না, আর (Chrome ও Safari-তে) Leaf-এ বৈধ Certificate Transparency প্রমাণ আছে।
6. পথের মাথায় আছে Trust Store-এর একটা Root।

তারপর TLS Handshake শেষ যাচাইটা যোগ করে: CertificateVerify প্রমাণ করে Leaf-এর Private Key Server-এর কাছেই আছে।

নোটের ছবির সংশোধন। নোটে DigiCert-কে Root আর Let’s Encrypt-কে তার নিচের Intermediate “SSL Provider” আঁকা হয়েছে। এরা দুটো স্বাধীন CA। অলাভজনক ISRG-এর চালানো Let’s Encrypt-এর নিজের Root আছে (RSA-র জন্য ISRG Root X1, Elliptic Curve-এর জন্য ISRG Root X2), আর R11 বা E6-এর মতো ছোট নামের Intermediate। ২০২১-এর সেপ্টেম্বর পর্যন্ত অন্য একটা CA-র পুরনো Root একে Cross-sign করত, যাতে যেসব পুরনো Device তখনো ISRG Root X1 চিনত না, তারাও বিশ্বাস করে। DigiCert-এর নিজের আলাদা Root আছে।

#Trust Store

Root আসে একাধিক জায়গা থেকে:

• Operating System: Windows, macOS আর iOS, Android, প্রত্যেকের নিজস্ব Root Program।
• Browser: Chrome ২০২২ থেকে নিজের Chrome Root Store ব্যবহার করে, আর Firefox ব্যবহার করে Mozilla-র Root Store (অনেক Linux Distribution-ও এটাকেই ca-certificates হিসেবে দেয়)।
• Runtime: Java-র নিজের cacerts; Python প্রায়ই certifi Bundle নেয়; Node.js Mozilla-র তালিকা সাথে নিয়ে আসে।

নিয়ম ভাঙা CA-কে Root Program বাদ দিতে পারে, আর দেয়ও: ২০১১ সালে হ্যাক হয়ে ভুয়া Google Certificate দেওয়া একটা ডাচ CA বাদ পড়ে দেউলিয়া হয়ে যায়; ২০১৮ সালে Symantec-এর CA ব্যবসার ওপর বিশ্বাস তুলে নেওয়া হয়; ২০২৪-এর শেষে Chrome আর Mozilla Entrust-এর নতুন Certificate বিশ্বাস করা বন্ধ করে। System Design-এর জন্য এর মানে: CA Bundle ছাড়া একটা হালকা Container Image-এ বাইরের প্রতিটা HTTPS Call ব্যর্থ হয় “unable to get local issuer certificate” দিয়ে, আর তোমার Client যে Root বিশ্বাস করে সেটা তোমার অজান্তেই বদলে যেতে পারে।

#Intermediate কেন আছে

• Root Key রক্ষা। একটা Root কোটি কোটি Device ১৫–২৫ বছর বিশ্বাস করে, আর একে বদলাতে বছরের পর বছর Software Update লাগে। তাই এর Private Key থাকে Offline, একটা ভল্টের HSM-এ, শুধু রেকর্ড করা আনুষ্ঠানিক বৈঠকে কয়েকটা Intermediate Sign করতে বের হয়।
• ক্ষতি সীমিত রাখা। কোনো Intermediate হ্যাক হলে বা নিয়ম ভাঙলে সেটা বাতিল করে বদলানো যায়, প্রতিটা Device-এর Root না ছুঁয়েই।
• কাজ আলাদা রাখা। RSA আর Elliptic Curve-এর জন্য, বা আলাদা Product-এর জন্য আলাদা Intermediate, ছোট মেয়াদের, ঘুরিয়ে বদলানো যায়।

Server-কে পাঠাতে হবে তার Leaf আর সব Intermediate, Client-এর কাছে আগে থেকে থাকবে এই ভরসায় না। Desktop Browser প্রায়ই হারানো Intermediate ঢেকে দেয় (আগে দেখা Intermediate Cache করে রাখে, বা Certificate-এর URL থেকে নামিয়ে আনে), তাই Chrome-এ Site ঠিক দেখায়, অথচ curl, Java, Go, Android App আর Partner Server ব্যর্থ হয়। “Browser-এ চলে, Code থেকে চলে না” মানেই হারানো Intermediate।

এগুলোর কোনোটাই যাচাই বন্ধ করে (verify=False, -k, InsecureSkipVerify) “ঠিক” কোরো না। তাতে সব আক্রমণকারীও ঢুকে পড়ে। ঠিক করো Chain, নাম, ঘড়ি বা Trust Store।

#কে Certificate দিতে পারে: CA, যাচাইয়ের স্তর আর নিয়মকানুন

Certificate Authority হলো একটা বিশ্বস্ত তৃতীয় পক্ষ, যে একটা অনুরোধ যাচাই করে Sign করা Certificate দেয়। নোটের উদাহরণগুলো হালনাগাদ করে: Let’s Encrypt (বিনা পয়সায়, সবচেয়ে বড়, অনেক ব্যবধানে), DigiCert, Sectigo (আগের নাম Comodo CA, ২০১৮ সালে নাম বদলায়), Google Trust Services। Cloudflare সাধারণ অর্থে Public CA না: তার Edge-এর Certificate আসে Let’s Encrypt আর Google Trust Services-এর মতো Partner CA থেকে, আর তার “Origin CA” Certificate শুধু Cloudflare-এর নিজের Proxy বিশ্বাস করে, Browser না।

User পার্থক্য বুঝত না, আর Phisher-রাও OV, EV কিনত, তাই Browser এগুলোকে আলাদা গুরুত্ব দেওয়া বন্ধ করেছে; ২০২৩ সালে Chrome তালা চিহ্নের বদলে একটা নিরপেক্ষ “Tune” চিহ্নও বসিয়েছে। বেশিরভাগ Site-এর জন্য স্বয়ংক্রিয় DV-ই সঠিক উত্তর।

নিয়ম ঠিক করে CA/Browser Forum (CA আর Browser নির্মাতারা মিলে) তাদের Baseline Requirements-এ, আর সেটা কার্যকর করে Root Program-গুলো। Engineer-দের কাজে লাগে এমন কয়েকটা:

• DNS-এর CAA Record তালিকা দেয় কোন কোন CA তোমার Domain-এর Certificate দিতে পারবে (example.com. CAA 0 issue "letsencrypt.org")। ২০১৭ থেকে CA-দের এটা দেখতেই হয়।
• Multi-perspective Validation: ২০২৫ থেকে CA-দের Domain-এর নিয়ন্ত্রণ যাচাই করতে হয় কয়েকটা আলাদা Network জায়গা থেকে, যাতে এক জায়গার BGP বা DNS Hijack দিয়ে তাদের ঠকানো না যায়।
• ভেতরের নাম না: ২০১৫ থেকে Public CA ভেতরের নাম (db.internal, server01) বা Private IP Address-এর Certificate দেয় না।
• বাতিলের সময়সীমা: Key ফাঁস হলে ২৪ ঘণ্টা, বেশিরভাগ অন্য সমস্যায় ৫ দিন। ২০২৪ সালে একটা যাচাইয়ের Bug-এর কারণে একটা CA-কে ২৪ ঘণ্টার মধ্যে প্রায় ৮৩,০০০ Certificate বাতিল করতে হয়েছিল; যাদের Automation ছিল, তারা শুধু আবার Certificate নিয়ে নিয়েছিল।

#Certificate Transparency

কোনো CA তোমার Domain-এর Certificate অন্য কাউকে দিয়ে দিলে তুমি জানবে কীভাবে? Certificate Transparency (CT) প্রতিটা Public Certificate প্রকাশ্য করে দেয়। CA প্রতিটা Certificate কয়েকটা স্বাধীন, শুধু-যোগ-করা-যায় এমন CT Log-এ জমা দেয় (Merkle Tree, তাই ইতিহাস আবার লেখা যায় না), আর Log-গুলোর Sign করা Timestamp Certificate-এর ভেতরে বসায়। Chrome (২০১৮ থেকে) আর Safari এগুলো ছাড়া Public Certificate নেয় না।

• নিজের Domain নজরে রাখো: crt.sh বা Cert Spotter-এর মতো Service, বা তোমার Cloud Provider, তোমার নামে যেকোনো Certificate দেখা দিলেই জানায়। এভাবে বহুবার ভুলভাবে দেওয়া Certificate ধরা পড়েছে।
• পার্শ্বপ্রতিক্রিয়া: Public Certificate-এ যে Hostname রাখো, সেটা চিরকালের জন্য প্রকাশিত। Certificate-এ staging-payments-v2.example.com থাকা মানে যে কেউ সেটা দেখতে পায়। যে নাম তালিকায় দেখাতে চাও না, তার জন্য Wildcard বা Private CA নাও।

#Revocation: মেয়াদের আগেই Certificate বাতিল

কখনো কখনো মেয়াদের আগেই একটা Certificate-কে মরতে হয়: তার Private Key ফাঁস হয়েছে, CA ভুল করে দিয়েছে, বা Domain-এর মালিক বদলেছে। CA তখন এটা Revoke করে। কঠিন অংশ হলো প্রতিটা Client-কে খবরটা জানানো।

Online যাচাইয়ের মূল দুর্বলতা Soft-fail: যে আক্রমণকারী Key চুরি করেছে, সে সাধারণত OCSP Request-ও আটকে দিতে পারে, তাই ঠিক যখন দরকার তখনই যাচাই ব্যর্থ। এজন্য Industry OCSP থেকে সরে এসেছে। CA/Browser Forum OCSP-কে ঐচ্ছিক আর CRL-কে বাধ্যতামূলক করেছে (২০২৩), আর Let’s Encrypt ২০২৫ সালে OCSP বন্ধ করেছে: জানুয়ারিতে Must-Staple অনুরোধ নেওয়া বন্ধ, মে-তে নতুন Certificate থেকে OCSP URL বাদ, আগস্টে Responder বন্ধ। Revocation এখন চলে CRL দিয়ে, Browser নির্মাতারা সেগুলো জোগাড় করে Browser-এ পৌঁছে দেয়, আর পেছনে থাকে ক্রমশ ছোট হতে থাকা মেয়াদ।

#স্বয়ংক্রিয়ভাবে Certificate পাওয়া: ACME আর Let’s Encrypt

২০১৫-র আগে Certificate কেনা হতো, Email-এ আসত, বছরে একবার হাতে বসানো হতো, আর মেয়াদ শেষ হওয়া পর্যন্ত সবাই ভুলে থাকত। Let’s Encrypt (২০১৫-র ডিসেম্বর থেকে সবার জন্য খোলা) DV Certificate বিনা পয়সায় আর স্বয়ংক্রিয় করে দেয়, নিজের বানানো একটা Protocol দিয়ে, যেটা IETF মানক করেছে ACME নামে (Automatic Certificate Management Environment, RFC 8555, ২০১৯)।

একটা ACME Client কীভাবে Certificate পায়:

1. CA-র ACME Server-এ একটা Account খোলে (একটা Account Key Pair দিয়ে পরিচিত)।
2. এক বা একাধিক নামের জন্য একটা Order দেয়।
3. প্রতিটা নামের জন্য একটা Challenge পার করে নিয়ন্ত্রণ প্রমাণ করে।
4. নিজের কাছে বানানো Public Key সহ একটা CSR পাঠায়; Private Key কখনো তোমার Server ছাড়ে না।
5. Certificate আর Chain নামিয়ে বসায়, Server Reload করে। মেয়াদ শেষের অনেক আগেই আবার করে।

Client: certbot, Caddy (ভেতরেই আছে, Lesson ১.১৩ যেমন দেখিয়েছে), Kubernetes-এ cert-manager, Traefik, acme.sh, আর Cloud-এর Managed Certificate (AWS Certificate Manager, Google-managed Certificate, Cloudflare), যেগুলো তোমার হয়ে Renew করে। Let’s Encrypt-এর Rate Limit আছে (যেমন প্রতি Registered Domain-এ সপ্তাহে ৫০টা Certificate), তাই পরীক্ষা করো তার Staging Environment-এ। আর ২০২৫-এর মাঝামাঝি থেকে এরা মেয়াদের সতর্কবার্তা Email আর পাঠায় না: Monitoring এখন তোমার দায়িত্ব।

#Certificate-এর মেয়াদ কমছে

CA/Browser Forum ২০২৫-এর এপ্রিলে এই সূচিতে ভোট দিয়েছে। ছোট মেয়াদ চুরি যাওয়া Key-এর ক্ষতি আর Client-এ না পৌঁছানো Revocation-এর ক্ষতি সীমিত করে, আর Automation বাধ্যতামূলক করে। Let’s Encrypt এখনই ডিফল্টভাবে ৯০ দিনের Certificate দেয়, চাইলে ছয় দিনেরও দেয়, আর ২০২৮-এর মধ্যে ৪৫ দিনে নামার ঘোষণা দিয়েছে।

তোমার System-এর জন্য এর মানে:

• হাতে Renew করার দিন শেষ। ৪৭ দিনে প্রতিটা Certificate বছরে প্রায় আটবার Renew হবে। প্রতিটা Certificate-এর একজন স্বয়ংক্রিয় মালিক লাগবে।
• যা আসলে দেখানো হচ্ছে সেটা নজরে রাখো, তুমি যা বসিয়েছ ভাবছ সেটা না: প্রতিটা Endpoint-এর বাকি দিন বাইরে থেকে যাচাই, মেয়াদের প্রায় এক-তৃতীয়াংশ বাকি থাকতেই Alert (৯০ দিনের Certificate-এ ৩০ দিন), সাথে Renewal Error-এর Alert।
• একটা তালিকা রাখো: Load Balancer, CDN, Partner-মুখী Endpoint, ভেতরের Service আর IoT Device, সবার কাছেই Certificate আছে।
• Renewal-এর পথটা পরীক্ষা করো: Port 80 বন্ধ করে দেওয়া Firewall বদল, মেয়াদ ফুরানো DNS API Token আর Rate Limit, এরাই সাধারণত খুনি।

#ভেতরের Service-এর জন্য Private CA

প্রতিষ্ঠানের ভেতরে প্রায়ই এমন Certificate লাগে, যেটা Public CA দেবে না বা দেওয়া উচিত না:

• ভেতরের নাম (orders.svc.cluster.local, db.internal), যার Certificate Public CA দিতে পারে না।
• Service-এর মধ্যে Mutual TLS, যেখানে প্রতিটা Service-এর একটা Client Certificate লাগে; Public CA-রা Client Authentication থেকে সরে আসছে (Chrome-এর Root Program শুধু-Server Hierarchy চায়, আর Let’s Encrypt ২০২৬ সালে তাদের Certificate থেকে Client Authentication সরিয়ে দিয়েছে)।
• খুব ছোট মেয়াদ (কয়েক ঘণ্টা) আর বিপুল সংখ্যা, প্রতিটা Service-এর নাম CT Log-এ প্রকাশ না করে।

উত্তর হলো একটা Private CA: তোমার নিজের Root, যাকে শুধু তোমার নিজের মেশিনগুলো বিশ্বাস করে। প্রচলিত ব্যবস্থা: একটা Service Mesh (Istio, Linkerd), যেটা প্রতিটা Workload-কে প্রায় ২৪ ঘণ্টার Certificate দেয় আর নিজে নিজে বদলায়; Kubernetes-এ CA Issuer সহ cert-manager; HashiCorp Vault-এর PKI Engine; AWS Private CA; smallstep-এর step-ca।

দাম যা দিতে হয়: তোমার Root প্রতিটা Client-এ পৌঁছাতে হবে (OS Trust Store, Container Image, Java cacerts), Root Key Offline রাখতে হবে, Certificate দেওয়াটাকে একটা জরুরি Service হিসেবে চালাতে হবে, আর বছর আগে থেকে Root বদলের পরিকল্পনা করতে হবে। Lesson ১.১২-এর প্রতিষ্ঠানের TLS Interception Proxy-ও আসলে একটা Private CA, কর্মীদের Device-এ বসানো। Mutual TLS নিজে Lesson ২.৮-এ।

#বাস্তবে Key সামলানো

আসল সম্পদ Private Key; Certificate, Signature আর Encrypt করা Data ঠিক ততটাই নিরাপদ, যতটা তার পেছনের Key।

• যেখানে ব্যবহার হবে সেখানেই Key বানাও (Server-এ, বা HSM-এর ভেতরে), আর কখনো Email, Chat বা Ticket দিয়ে Private Key সরিয়ো না। CSR শুধু Public Key বহন করে।
• কখনো Key বা Secret Git-এ Commit কোরো না। Secret Manager, কড়া File Permission (chmod 600), আর CI-তে Secret Scanning ব্যবহার করো।
• HSM আর Cloud KMS Key রাখে কারসাজি-প্রতিরোধী Hardware-এর ভেতরে (FIPS 140-3 সনদ পাওয়া): তোমার Code Device-কে Sign বা Decrypt করতে বলে, Key কখনো বের হয় না। Cloud KMS Service (AWS KMS, Google Cloud KMS, Azure Key Vault) যোগ করে Envelope Encryption: Data Encrypt হয় একটা Data Key দিয়ে, আর সেই Data Key Encrypt হয় KMS-এর ভেতরের একটা Master Key দিয়ে। Chapter ৩৪ এটা গভীরে দেখাবে।
• নিয়মিত Key বদলাও (Rotate), আর সন্দেহ হলেই সাথে সাথে। নতুন Key দিয়ে Sign শুরুর আগেই নতুন Public Key প্রকাশ করো (JWT Header-এর kid দেখে যাচাইকারী ঠিক Key বাছে), আর পুরনোগুলো রেখে দাও যতদিন না তা দিয়ে Sign করা সবকিছুর মেয়াদ শেষ হয়।
• Operating System-এর নিরাপদ Random Generator ব্যবহার করো (/dev/urandom, Python-এ secrets, Node.js-এ crypto.randomBytes)। ২০০৮ সালে ধরা পড়ে, Debian-এর একটা Patch দুই বছর ধরে OpenSSL-কে প্রতি ধরনের Key-এ মাত্র প্রায় ৩২,০০০টা সম্ভাব্য Key-তে আটকে রেখেছিল; ওইসব System-এ বানানো প্রতিটা Key বদলাতে হয়েছিল।
• Crypto Agility: Algorithm আর Key-এর মাপ Configuration-এ রাখো, Library হালনাগাদ রাখো, যাতে একটা Algorithm ভাঙলে (গতকাল SHA-1, আগামীকাল RSA) সেটা শুধু একটা Config বদল হয়, পুরো নতুন করে লেখা না।

#Post-quantum Cryptography, সংক্ষেপে

যথেষ্ট বড় একটা Quantum Computer Shor-এর Algorithm চালিয়ে RSA আর Elliptic Curve ভেঙে দেবে: Key Exchange আর Signature দুটোই। Symmetric Cipher আর Hash শুধু দুর্বল হয় (Grover-এর Algorithm মোটামুটি এদের শক্তি অর্ধেক করে), তাই AES-256 আর SHA-256 ঠিকই থাকে। আজ এমন যন্ত্র কেউ বানাতে পারে না, কিন্তু এখন রেকর্ড করা Encrypt করা Traffic পরে খোলা যেতে পারে (“এখন জমাও, পরে খোলো”), তাই Key Exchange-কেই আগে সরতে হয়েছে।

• ২০২৪-এর আগস্টে NIST প্রথম Post-quantum মানদণ্ড প্রকাশ করে: Key স্থাপনের জন্য ML-KEM (FIPS 203) আর Signature-এর জন্য ML-DSA (FIPS 204), সাথে Hash-ভিত্তিক একটা বিকল্প Signature (FIPS 205)।
• Hybrid Key Exchange X25519MLKEM768 পুরনো X25519-এর সাথে ML-KEM-768 মেশায়, তাই দুটোর যেকোনো একটা টিকে থাকলেই নিরাপদ। এটা Chrome আর Edge-এ (২০২৪ থেকে), Firefox, Apple-এর Platform-এ (২০২৫ থেকে), Cloudflare, Go আর OpenSSL 3.5-এ ডিফল্টভাবে চালু। Browser Traffic-এর বড় একটা অংশ এখনই এভাবে সুরক্ষিত। দাম হলো একটু বড় ClientHello (প্রায় ১.২ KB বেশি), যেটা কিছু পুরনো Middlebox ভেঙে দিয়েছিল, কারণ তারা ধরে নিয়েছিল এটা এক Packet-এ আঁটবে।
• Signature আর Certificate এখনো বদলায়নি: একটা ML-DSA Signature প্রায় ২.৪ KB, যেখানে Elliptic Curve-এ ৬৪ Byte, আর একটা Chain-এ কয়েকটা Signature আর CT প্রমাণ থাকে। Handshake ছোট রাখতে Browser নির্মাতা আর CA-রা নতুন ধরনের Certificate নিয়ে পরীক্ষা করছে। NIST-এর খসড়া সূচি ২০৩০ থেকে RSA আর Elliptic-curve Algorithm বাতিলের পথে নেয়, আর ২০৩৫-এর মধ্যে নিষিদ্ধ করে।

System Designer হিসেবে তোমার কাজ: TLS Library, Load Balancer আর CDN হালনাগাদ রাখো, Handshake খুঁটিয়ে দেখে এমন Middlebox এড়িয়ে চলো, দীর্ঘমেয়াদি Secret আর Signature কোথায় কোথায় আছে তার তালিকা করো (Firmware Signing, কয়েক দশক ধরে Encrypt করে রাখা Archive), আর Crypto Agility-কে গুরুত্ব দাও।

#System Design-এ Cryptography

• Edge-এ TLS Terminate করো, আর ভেতরে আবার Encrypt করো, যখন Network ভাগ করা বা নিয়ন্ত্রিত। যেখানে পারো Managed Certificate (Cloud Certificate Manager, Caddy, cert-manager) ব্যবহার করো।
• Certificate-এর মেয়াদকে নির্ভরযোগ্যতার ঝুঁকি হিসেবে দেখো: স্বয়ংক্রিয় Renewal, বাইরে থেকে মেয়াদের Monitoring, একটা তালিকা, আর একসাথে অনেক Certificate বদলের Runbook।
• পুরো Chain পাঠাও, প্রতিটা Hostname Subject Alternative Name তালিকায় রাখো, আর Container Image-এ CA Bundle রাখো।
• ঘড়ি মিলিয়ে রাখো (NTP): Certificate, JWT-এর মেয়াদ আর Webhook Timestamp সবই সময়ের ওপর নির্ভর।
• Webhook আর ভেতরের Call: Raw Byte-এর ওপর Timestamp সহ HMAC, Constant-time তুলনা, একবারই Process।
• অনেক Service যাচাই করে এমন Token: ভাগ করা HS256 Secret-এর বদলে প্রকাশিত Public Key সহ RS256 বা ES256 নাও।
• ভেতরের Service-এর পরিচয়: স্বল্পমেয়াদি Certificate সহ Private CA, সাধারণত Service Mesh দিয়ে।
• জমা থাকা Data AEAD আর KMS-এর Key দিয়ে Encrypt করো, কখনো Data-র সাথে একই Database-এ রাখা Key দিয়ে না।
• নিজের Domain-এর CT Log নজরে রাখো, আর CAA Record বসাও।
• বদলের জন্য তৈরি থাকো: ২০২৯-এর মধ্যে ৪৭ দিনের Certificate আর Post-quantum Algorithm, দুটোরই সূচি ঠিক হয়ে আছে; যেসব System-এ মানুষের হাত লাগে, সেগুলো ভাঙবে।

#নিজে করে দেখো

# Server আসলে কোন Certificate Chain পাঠায় দেখো ("-----BEGIN" ব্লক গুনে দেখো)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

# Leaf খুলে দেখো: Issuer, মেয়াদ, Subject Alternative Name, Key-এর ধরন, CT Timestamp
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -text

# শুধু মেয়াদ শেষের তারিখ (Monitoring Script-এর জন্য কাজের)
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -enddate

# Hash: একই Input, একই Digest; একটা অক্ষর বদলালেই সব বদলে যায়
echo -n hello | sha256sum
echo -n hellO | sha256sum

# ভাগ করা Secret দিয়ে একটা Webhook Body-র HMAC-SHA256
echo -n '1762070400.{"id":"evt_42","amount":500}' | openssl dgst -sha256 -hmac 'whsec_test_secret'

# Ed25519 Key Pair বানাও, একটা File Sign করো আর Verify করো
openssl genpkey -algorithm ed25519 -out priv.pem
openssl pkey -in priv.pem -pubout -out pub.pem
echo "release 1.2.3" > release.txt
openssl pkeyutl -sign -inkey priv.pem -rawin -in release.txt -out release.sig
openssl pkeyutl -verify -pubin -inkey pub.pem -rawin -in release.txt -sigfile release.sig

# শক্ত এলোমেলো ২৫৬-bit Key, Hex-এ
openssl rand -hex 32

# কোন CA এই Domain-এর Certificate দিতে পারবে?
dig +short CAA example.com

# কোনো Domain-এর জন্য কখনো Log হওয়া সব Certificate (Certificate Transparency)
curl -s 'https://crt.sh/?q=example.com&output=json' | head -c 600

# Let's Encrypt-এর Staging-এ নিরাপদে ACME অনুশীলন
sudo certbot certonly --staging --webroot -w /var/www/html -d example.com --dry-run

Chrome-এ Address Bar-এর বাঁ দিকের চিহ্নে Click করো → Connection is secure → Certificate is valid, তাহলে Chain, Subject Alternative Name তালিকা আর মেয়াদের তারিখ দেখবে। DevTools → Security-তে দেখা যায় Key Exchange Group (X25519MLKEM768 খুঁজো) আর Cipher (AES_128_GCM)।

#সারসংক্ষেপ

মূল কথাগুলো

• Cryptography দেয় Confidentiality (Encryption), Integrity (Hash, MAC, AEAD Tag), Authenticity (MAC বা Signature + Certificate) আর Non-repudiation (শুধু Signature)। Algorithm প্রকাশ্য; Key গোপন; নিজের Cryptography কখনো নিজে বানিয়ো না।
• Symmetric Encryption (AES-GCM, ChaCha20-Poly1305) দ্রুত, সব বড় Data রক্ষা করে। কারসাজি ধরতে AEAD নাও, Nonce কখনো আবার ব্যবহার কোরো না, আর Key Distribution সমস্যা মনে রাখো। DES, 3DES আর RC4 পুরনো দিনের।
• Asymmetric Cryptography (RSA, Elliptic Curve) একটা Key Pair ব্যবহার করে: Public Encrypt করে / Private Decrypt করে, Private Sign করে / Public Verify করে। এটা ধীর, আর RSA মাত্র কয়েকশো Byte Encrypt করতে পারে, তাই এর কাজ Key আর Signature, Data না।
• Diffie–Hellman / ECDHE দিয়ে দুই পাশ এমন একটা ভাগ করা Secret হিসাব করে, যা Network পার হয় না; Signature সক্রিয় Man-in-the-middle থামায়; Ephemeral Key দেয় Forward Secrecy, TLS 1.3-এ বাধ্যতামূলক।
• Hash (SHA-256) Key ছাড়া আঙুলের ছাপ, Encryption না; MD5 আর SHA-1 ভাঙা। HMAC একটা ভাগ করা Key যোগ করে: Webhook, Sign করা Cookie, HS256। Signature-এ যে কেউ যাচাই করে, Sign করে শুধু একজন: Certificate, Update, RS256/ES256।
• HTTPS Hybrid: Key-এর জন্য ECDHE (এখন ML-KEM সহ), পরিচয়ের জন্য Signature আর Certificate, Data-র জন্য AEAD। TLS 1.3-এ Server-এর Certificate Key দিয়ে Session Key Encrypt করা হয় না।
• Certificate (X.509) একটা Public Key-কে Subject Alternative Name তালিকার নামগুলোর সাথে, একটা মেয়াদের জন্য, CA-র Signature দিয়ে বাঁধে। Client Leaf → Intermediate → Root ধরে নিজের Trust Store পর্যন্ত হাঁটে; Root থাকে Offline, কাজ করে Intermediate, আর Server-কে পুরো Chain পাঠাতে হয়।
• Let’s Encrypt-এর নিজের Root (ISRG), DigiCert-এর না। DV-ই স্বাভাবিক; EV আর আলাদা কিছু দেখায় না। CAA, Multi-perspective Validation আর Certificate Transparency ভুলভাবে Certificate দেওয়া সীমিত আর প্রকাশ করে।
• OCSP দিয়ে Revocation Soft-fail করে আর গোপনীয়তা ফাঁস করে; Let’s Encrypt ২০২৫ সালে OCSP বন্ধ করেছে, Browser CRL-এর Data পৌঁছে দেয়, আর আসল সমাধান স্বল্পমেয়াদি Certificate।
• ACME Certificate দেওয়া স্বয়ংক্রিয় করে (HTTP-01, DNS-01, TLS-ALPN-01)। মেয়াদ: মার্চ ২০২৬ থেকে ২০০ দিন, ২০২৭-এ ১০০, ২০২৯-এ ৪৭। Automation করো, যা দেখানো হচ্ছে সেটা নজরে রাখো, একটা তালিকা রাখো।
• Private CA ভেতরের নাম আর mTLS সামলায়; Key থাকে HSM/KMS-এ, নিয়মিত বদলায়; Post-quantum Hybrid Key Exchange এখনই ডিফল্ট, Signature আসছে পরে।

নিজেকে যাচাই করো: Cryptography, Certificate আর CA৩২টি প্রশ্ন