AWS Certificate Manager

এই লেসন শেষে তুমি পারবে

• AWS Certificate Manager (ACM) কী করে, বুঝিয়ে বলতে: HTTPS-এর জন্য TLS certificate বানানো, জমা রাখা, renew করা আর জায়গামতো বসানো; public certificate বিনা পয়সায়, আর private key কখনো AWS-এর বাইরে যায় না।
• কোন কোন service ACM certificate ব্যবহার করতে পারে (ELB, CloudFront, API Gateway, App Runner, Amplify, Nitro Enclaves আর আরও কয়েকটা) বলতে, আর সাধারণ ACM certificate কেন EC2 instance-এ install করা যায় না, ব্যাখ্যা করতে।
• DNS বা email validation দিয়ে public certificate চাইতে, আর “মানুষের হাত ছাড়া renewal”-এর উত্তর কেন DNS validation, বুঝিয়ে বলতে।
• Managed renewal কীভাবে চলে (১৯৮ দিনের certificate, মেয়াদ ফুরোনোর ৪৫ দিন আগে renew) আর কোথায় আটকে যায়, বলতে।
• বাইরের certificate ACM-এ import করতে, আর ACM-এর EventBridge event আর AWS Config-এর acm-certificate-expiration-check rule দিয়ে তার মেয়াদের ওপর নজর রাখতে।
• HTTP → HTTPS redirect আর SNI-সহ ALB-এর HTTPS listener-এ certificate লাগাতে, আর কোন load balancer SNI সমর্থন করে বলতে।
• Certificate-এর ঠিক Region বাছতে: CloudFront আর edge-optimized API Gateway domain-এর জন্য us-east-1, Regional API আর load balancer-এর জন্য resource-এর নিজের Region।

#ACM কেন: certificate-এর ঝামেলা ছাড়া HTTPS

লেসন ২১.১-এ encryption in flight দেখেছ: TLS (পরীক্ষার অনেক প্রশ্নে এখনো SSL বলা হয়) client আর server-এর মাঝের traffic encrypt করে, আর server নিজের পরিচয় প্রমাণ করে একটা certificate দিয়ে। লেসন ৬.৪-এ দেখেছ certificate-এর ভেতরে কী থাকে (domain name, public key, মেয়াদের তারিখ, একটা CA-র সই) আর load balancer সেটা কীভাবে ব্যবহার করে। এই লেসন সেই service নিয়ে, যেটা তোমাকে certificate এনে দেয় আর সেগুলো বাঁচিয়ে রাখে।

#সমস্যাটা কী

রাজশাহীর একটা university AWS-এ তাদের admission portal, ফলাফলের site আর একটা mobile API চালায়। প্রতিটাতে HTTPS লাগবে, প্রতিটার জন্য certificate লাগবে, আর certificate-এর মেয়াদ ফুরোয়। পুরোনো নিয়ম ছিল: server-এ একটা key আর CSR বানাও, certificate কেনো, একটা email-এর অপেক্ষা করো, certificate, key আর chain প্রতিটা server-এ কপি করো, web server restart দাও, আর মেয়াদের তারিখটা ক্যালেন্ডারে লিখে রাখো। তারপর এক বছর পরে দেখা যায় যে কাজটা করেছিল সে চাকরি ছেড়ে চলে গেছে, কেউ renew করেনি, আর ফল প্রকাশের দিন প্রতিটা ছাত্রছাত্রী নিজের নম্বরের বদলে পুরো পাতা জুড়ে browser-এর সতর্কবার্তা দেখছে।

মেয়াদ পেরোনো certificate outage-এর সবচেয়ে সাধারণ কারণগুলোর একটা, ব্যাংক, telco আর বড় বড় tech company সবার বেলাতেই। আর certificate-এর আয়ু ক্রমশ কমছে, ফলে renew করতে হচ্ছে আরও ঘনঘন (নিচে পাশের কথা দেখো)।

#ACM জিনিসটা কী

AWS Certificate Manager (ACM) একটা managed service, যেটা দিয়ে AWS service-গুলোর জন্য TLS certificate বানানো, সামলানো আর বসানো যায়:

• Public certificate বিনা পয়সায়। ACM-এর public certificate দেয় Amazon-এর নিজের public certificate authority (Amazon Trust Services), আর সব বড় browser একে বিশ্বাস করে। Integrated service-এ ব্যবহার করলে এর জন্য কোনো টাকা লাগে না।
• নিজে নিজে renewal। ACM নিজের দেওয়া certificate নিজেই renew করে, আর নতুনটা একই ARN-এ সেই সব service-এ পৌঁছে দেয় যারা এটা ব্যবহার করছে।
• Private key AWS-এর ভেতরেই থাকে। Key বানায় আর পাহারা দেয় ACM; তুমি কখনো download করো না (exportable certificate একটা টাকার ব্যতিক্রম, নিচে আছে)।
• Public আর private দুই ধরনের certificate। Internet-এর site-এর জন্য public; ভেতরের service-এর জন্য private, যেগুলোতে সই করে তোমার নিজের AWS Private CA (এই লেসনের শেষের দিকে পাশের কথা)।
• Regional। একটা certificate একটা Region-এর, আর শুধু সেই Region-এর resource-ই ব্যবহার করতে পারে। ব্যতিক্রম CloudFront: সে certificate নেয় us-east-1 থেকে।
• এক জায়গায় সব দেখা আর audit। সব certificate-এর একটা তালিকা, তাদের অবস্থা, মেয়াদ আর কোন কোন resource ব্যবহার করছে; আর প্রতিটা API call CloudTrail-এ লেখা থাকে (লেসন ১৯.৬)।

ACM-এর প্রতিটা public certificate DV (domain validated): এটা শুধু প্রমাণ করে domain name-গুলো তোমার নিয়ন্ত্রণে, প্রতিষ্ঠান সম্পর্কে কিছু না। একটা certificate-এ কয়েকটা নাম থাকতে পারে (default-এ ১০টা পর্যন্ত, বাড়িয়ে ১০০ করা যায়), যার মধ্যে *.example.com-এর মতো wildcard-ও চলে। Wildcard ঠিক এক ধাপ ঢাকে (admission.example.com হ্যাঁ, a.b.example.com না), আর apex example.com-কে ঢাকে না; দুটোই লাগলে example.com আর *.example.com দুটোই চাও।

#ACM certificate কোথায় কোথায় ব্যবহার করা যায়

ACM certificate লাগানো হয় integrated service-এ, যারা তোমার হয়ে TLS handshake শেষ করে:

পরীক্ষা যে তিনটা নিয়ে মাথা ঘামায়, slide-এ সেগুলোই আছে: Elastic Load Balancer (CLB, ALB, NLB), CloudFront distribution আর API Gateway-এর API।

তালিকায় যেটা নেই: সাধারণ একটা EC2 instance। সাধারণ ACM certificate-এর private key export করা যায় না, তাই instance-এর Nginx, Apache বা IIS-এ এটা বসানো যায় না। চলতি design হলো instance-গুলোর সামনে একটা ALB (বা CloudFront)-এ TLS শেষ করা। Instance-এর নিজেরই যদি certificate লাগে (target পর্যন্ত পুরো পথ encrypt রাখতে), সেটা আসে অন্য কোথাও থেকে: ALB-এর পেছনে self-signed certificate-ই যথেষ্ট, কারণ ALB target-এর certificate যাচাই করে না (লেসন ৬.৪)।

#Public certificate চাওয়া

1. Domain name-এর তালিকা দাও

   admission.example.com-এর মতো পুরো একটা domain name দাও, *.example.com-এর মতো wildcard দাও, বা এক certificate-এ কয়েকটা নাম দাও (apex example.com আর *.example.com, এই জোড়াটাই বেশি চলে)। Key algorithm বাছো: RSA 2048 (default, সবার সাথে চলে) বা ECDSA P-256 / P-384 (ছোট আর দ্রুত, নতুন client-গুলো সমর্থন করে)।

2. Validation method বাছো

   DNS validation (পরামর্শ এটাই) বা email validation। Certificate-এর প্রতিটা নাম যে তোমার নিয়ন্ত্রণে, সেটা প্রমাণ করতে হবে।

3. Validation-এর অপেক্ষা

   ACM প্রমাণ খুঁজে না পাওয়া পর্যন্ত অবস্থা থাকে Pending validation। Route 53-এ DNS থাকলে সাধারণত কয়েক মিনিট লাগে (slide বলে কয়েক ঘণ্টাও লাগতে পারে)। ৭২ ঘণ্টার মধ্যে প্রমাণ না পেলে request-এর সময় পেরিয়ে যায়, আবার চাইতে হয়।

4. Issued, আর renewal-এর তালিকায়

   অবস্থা হয় Issued। এখন certificate integrated service-এ লাগানো যায়, আর এটা managed renewal-এর তালিকায় উঠে যায়।

#DNS validation আর email validation

CNAME দেখতে এরকম:

_3639ac514e785e898d2646601fa951d5.admission.example.com.  CNAME  _98d2646601fa951d5a1b2c3d4e5f6a7b.xlfgrmvvlj.acm-validations.aws.

তোমার domain-এর নিচে record বানাতে পারে শুধু সে-ই, যে zone edit করতে পারে; তাই record-টা থাকা মানেই নিয়ন্ত্রণের প্রমাণ। প্রতিটা renewal-এ একই record আবার কাজে লাগে, এজন্যই নিয়ম: certificate যতদিন ব্যবহার হচ্ছে, validation CNAME কখনো মুছবে না। CNAME record নিজে আছে লেসন ৮.১-এ। Zone-এ যদি CAA record থাকে (কোন কোন CA এই domain-এর certificate দিতে পারবে), তাহলে সেখানে amazon.com, amazontrust.com, awstrust.com বা amazonaws.com-এর অনুমতি থাকতে হবে, নইলে ACM issue বা renew কোনোটাই করতে পারবে না।

Email validation-এ ACM domain-এর পাঁচটা নির্দিষ্ট ঠিকানায় লেখে: admin@, administrator@, hostmaster@, postmaster@ আর webmaster@। প্রতিটা email-এর link-এর মেয়াদ ৭২ ঘণ্টা। চালু থাকা কোনো certificate email থেকে DNS validation-এ বদলানো যায় না; নতুন একটা চাইতে হয়।

#Managed renewal

ACM-এর public certificate এখন দেওয়া হয় ১৯৮ দিনের মেয়াদে। মেয়াদ ফুরোনোর ৪৫ দিন আগে ACM renew করার চেষ্টা করে। DNS-validated certificate হলে দুটো জিনিস দেখে:

১. Certificate-টা কোনো AWS service ব্যবহার করছে (load balancer, distribution, API-তে লাগানো), বা export করা হয়েছে।

২. প্রতিটা validation CNAME এখনো public DNS-এ আছে আর resolve হয়।

দুটোই ঠিক থাকলে ACM একই ARN-এ নতুন certificate দেয় আর যারা ব্যবহার করছে সবগুলোতে বসিয়ে দেয়। Listener বা distribution-এ কিছু বদলায় না, কাউকে login-ও করতে হয় না।

ACM validate করতে না পারলে মেয়াদ ফুরোনোর ৩০, ১৫, ৭, ৩ আর ১ দিন আগে AWS Health আর EventBridge event পাঠায় (“Renewal Action Required” event-এ কারণটাও থাকে, যেমন PENDING_DOMAIN_VALIDATION বা CAA_ERROR)। যে certificate কেউ ব্যবহার করছে না আর export-ও হয়নি, সেটা renew-ই হয় না: অব্যবহৃত certificate-এর মেয়াদ এমনিই ফুরিয়ে যায়।

Email-validated certificate-এর বেলায় ACM মেয়াদ ফুরোনোর ৪৫ দিন আগে ওই পাঁচ ঠিকানায় email পাঠায়, আর কেউ click করলেই তবে renew করে।

#বাইরের certificate import করা

অন্য জায়গা থেকে আনা certificate-ও ACM-এ রাখা যায়। Import করার কারণ:

• কোনো partner বা নিয়ন্ত্রক সংস্থা নির্দিষ্ট একটা commercial CA-র certificate চায়, বা OV বা EV certificate চায় (ACM শুধু DV দেয়)।
• GoDaddy বা Sectigo-র মতো CA-র সাথে আগে থেকেই কয়েক বছরের চুক্তি কেনা আছে, বা নিজের tool দিয়ে Let’s Encrypt ব্যবহার করো।
• একই certificate AWS-এ আর AWS-এর বাইরের server-এ, দুই জায়গাতেই লাগবে।

PEM format-এ তিনটা জিনিস import করো: certificate, তার private key (encrypt না করা, RSA বা ECDSA) আর certificate chain। ACM দেখে নেয় তিনটা একসাথে মেলে কি না, কিন্তু domain validation করে না: সেটা ছিল CA-র কাজ। Import করতে টাকা লাগে না, আর import করা certificate ঠিক ACM-এর নিজের দেওয়া certificate-এর মতোই ব্যবহার হয়।

ঝামেলা হলো ACM নিয়ে পরীক্ষার সবচেয়ে প্রিয় তথ্যটা: import করা certificate ACM কখনো renew করে না। ACM এটা দেয়নি, আর ওই CA-র সাথে তার কোনো সম্পর্কও নেই। মেয়াদ ফুরোনোর আগে CA থেকে নতুন certificate এনে একই ARN-এ re-import করতে হবে; ওই ARN যেসব load balancer বা distribution ব্যবহার করে, তারা নিজে থেকেই নতুনটা পেয়ে যায়।

#মেয়াদ ফুরোনোর আগেই জানা

দুটো ব্যবস্থা, দুটোই slide-এ আছে:

• EventBridge-এ ACM-এর মেয়াদের event। Import করা (আর private) certificate-এর মেয়াদ ফুরোনোর ৪৫ দিন আগে থেকে ACM প্রতিদিন একটা “ACM Certificate Approaching Expiration” event পাঠায়। কত দিন আগে থেকে, সেটা একটা account setting (aws acm put-account-configuration, ১ থেকে ৪৫-এর মধ্যে)। একটা EventBridge rule event-টা পাঠায় SNS-এ (team-কে email বা chat), একটা Lambda function-এ (ticket খোলা, বা CA থেকে নতুন certificate এনে re-import করা), বা SQS-এ। ACM-এর নিজের দেওয়া public certificate-এর বেলায় প্রতিদিনের event শুরু হয় ৩০ দিন আগে, কারণ ওগুলো ACM নিজেই renew করে।
• AWS Config-এর managed rule acm-certificate-expiration-check। Config নির্দিষ্ট সময় পরপর আর কিছু বদলালে প্রতিটা ACM certificate যাচাই করে, আর তোমার ঠিক করা কয়েক দিনের মধ্যে (default ১৪ দিন) মেয়াদ ফুরোলে সেটাকে NON_COMPLIANT দেখায়। Config সব account আর Region মিলিয়ে একটা compliance dashboard দেয়, আর compliance বদলানোও একটা event, যেটা EventBridge পৌঁছে দেয়। Config শেখানো হয়েছে লেসন ১৯.৭-এ, EventBridge লেসন ১৯.৫-এ।

“ACM Certificate Expired” event শুধু ACM-এর দেওয়া certificate-এর জন্য, import করাগুলোর জন্য না; তাই import করা certificate চলে গেছে কি না জানতে ওই event-এর ভরসায় বসে থেকো না।

#Application Load Balancer-এ ACM

ACM certificate সবচেয়ে বেশি বসে ALB-এর HTTPS listener-এ:

• Port 443-এর listener ব্যবহার করে একটা ACM certificate (ALB-এর নিজের Region থেকে) আর একটা security policy, যেটা ঠিক করে কোন TLS version আর cipher চলবে। TLS ALB-তেই শেষ হয়: সে decrypt করে, listener rule খাটায়, তারপর target-এ HTTP দিয়ে পাঠায়, বা তোমার নিয়মে প্রতিটা ধাপে encryption লাগলে HTTPS দিয়ে আবার encrypt করে (termination আর re-encryption-এর তফাত লেসন ৬.৪-এ)।
• Port 80-এর listener-এ একটাই rule: HTTPS-এ redirect (HTTP 301)। Slide-এর “HTTP → HTTPS redirect rule” এটাই, আর এতে নিশ্চিত হয় কোনো page কখনো encryption ছাড়া যায় না।
• Auto Scaling group-এর instance-গুলোর কোনো public certificate লাগে না, TLS-এর কাজও করতে হয় না; CPU বাঁচে, আর certificate সামলানোর জায়গা থাকে একটাই।

#SNI: অনেক site, অনেক certificate, এক ALB

একটা ALB admission.example.com আর results.example.com দুটোই চালাতে পারে, প্রতিটা নিজের certificate নিয়ে। Listener-এ থাকে একটা default certificate আর একটা certificate list (default-এ আরও ২৫টা পর্যন্ত)। Browser তার প্রথম TLS message-এ (ClientHello) SNI field-এ hostname লিখে দেয়, আর ALB মিলে যাওয়া certificate দিয়ে উত্তর দেয়। Client SNI না পাঠালে বা কোনো certificate না মিললে ALB default certificate ব্যবহার করে, যার মানে সাধারণত ওই client-এর জন্য নাম না মেলার error। Decrypt হওয়ার পর একটা host-header rule ঠিক করে কোন target group-এ যাবে। পুরো কৌশল আর handshake শেখানো হয়েছে লেসন ৬.৪-এ; এখানে আমরা দেখছি certificate-এর দিক থেকে।

#API Gateway-এর endpoint type

API Gateway-এর একটা API থাকে একটা Region-এ। Client সেখানে কীভাবে পৌঁছাবে, সেটা ঠিক করে তার endpoint type (বিস্তারিত লেসন ১৫.৬-এ):

Edge-optimized হলেও API চলে এক Region-এই, আর edge-এ response cache-ও হয় না; শুধু network-এর পথটা ছোট হয়। Interface endpoint আছে লেসন ২২.২-এ।

#API Gateway-এর custom domain-এ ACM

একটা API-র default ঠিকানা দেখতে a1b2c3d4e5.execute-api.ap-south-1.amazonaws.com-এর মতো। সুন্দর একটা api.example.com চাইলে API Gateway-এ একটা custom domain name বানাও, সেটা API আর stage-এর সাথে জোড়ো, আর একটা ACM certificate দাও। Certificate কোন Region-এ থাকবে, সেটা নির্ভর করে TLS handshake কে শেষ করছে তার ওপর:

• Edge-optimized custom domain → API যে Region-এই থাকুক, certificate থাকতেই হবে us-east-1 (N. Virginia)-এ, কারণ domain-টা চলে একটা CloudFront distribution দিয়ে, আর CloudFront certificate পড়ে শুধু us-east-1 থেকে।
• Regional custom domain → certificate থাকতে হবে API-র একই Region-এ (slide-এর ভাষায় “API Stage-এর একই region”)।
• তারপর Route 53-এ নামটাকে custom domain-এর target-এর দিকে দেখাও, CNAME দিয়ে বা (আরও ভালো) alias A/AAAA record দিয়ে (alias বনাম CNAME: লেসন ৮.২)।

একই নিয়ম, সবকিছুর জন্য একবারে:

“Regional” কথাটার আরেকটা ফল: একই domain দুই Region-এ চালালে দুটো certificate লাগে, প্রতি Region-এ একটা, প্রতিটা আলাদাভাবে renew হয়। ACM এক Region থেকে অন্য Region-এ certificate কপি করে না। CloudFront-এর নিজের certificate-এর নিয়ম আছে লেসন ১১.১-এ।

যেকোনো জোড়ায় নিয়মটা খাটিয়ে দেখো: TLS কোথায় শেষ হয় আর কোন Region, বাছো, আর দেখো certificate কোথায় থাকতে হবে।

#Private certificate: AWS Private CA

Public certificate internet-এর নামের জন্য। ভেতরের নামের জন্য (orders.internal.example, service mesh, microservice-গুলোর মধ্যে mutual TLS, IoT device, VPN client) company-গুলো নিজেদের একটা private certificate authority চালায়, যার certificate শুধু তাদের নিজেদের machine-ই বিশ্বাস করে।

AWS Private CA (আগের নাম ACM Private CA) হলো সেই CA, managed service হিসেবে: root আর subordinate CA বানাও, তাদের key থাকে hardware security module-এ, আর private certificate দাও ACM দিয়ে বা সরাসরি। ACM দিয়ে চাওয়া private certificate integrated service-এ লাগানো যায় আর নিজে নিজে renew হয়; নিজের server-এর জন্য private certificate export-ও করা যায়। এটা বিনা পয়সায় না: general-purpose mode-এ প্রতিটা CA-র জন্য মাসে প্রায় ৪০০ USD (short-lived certificate mode-এ ৫০ USD, যেখানে certificate সর্বোচ্চ ৭ দিনের), সাথে প্রতিটা certificate-এর দাম। Browser private certificate বিশ্বাস করে না, তাই public website-এর উত্তর এটা কখনো না। পরীক্ষায়: “নিজের CA দিয়ে ভেতরের TLS, AWS সামলাবে” → AWS Private CA।

#কোথায় গোলমাল হয়

• Console-এ certificate “পাওয়া যাচ্ছে না”। ভুল Region-এ আছে: CloudFront আর edge-optimized API-র জন্য us-east-1, বাকি সবার জন্য resource-এর নিজের Region।
• Pending validation-এ আটকে, তারপর Validation timed out। CNAME যোগ হয়েছে ভুল zone-এ (private hosted zone-এ, বা এমন zone-এ যেটায় domain delegate করা নেই), বানানে ভুল আছে, বা DNS provider নিজে থেকে domain দুবার জুড়ে দিয়েছে (_x.example.com.example.com)। অথবা কোনো CAA record Amazon-কে অনুমতি দেয় না। ৭২ ঘণ্টা পরে request-এর সময় পেরিয়ে যায়।
• কয়েক মাস পরে renewal আটকে যায়। Validation CNAME মুছে গেছে, domain record ছাড়াই অন্য DNS provider-এ চলে গেছে, certificate ব্যবহার হচ্ছে না (তাই ACM renew করে না), বা email-validated renewal-এর mail কেউ পড়েনি। “Renewal Action Required” event-এর দিকে নজর রাখো।
• Import করা certificate-এর মেয়াদ ফুরিয়ে যায়। ACM import করা certificate কখনো renew করে না; মেয়াদের event কেউ কোথাও পাঠায়নি। EventBridge বা Config rule ব্যবহার করো, বা ACM-এর নিজের দেওয়া certificate-এ চলে যাও।
• নাম না মেলার error। Certificate নামটা ঢাকে না (wildcard apex বা দ্বিতীয় ধাপ ঢাকে না), client SNI পাঠায় না আর default certificate পায়, বা CLB মাত্র একটা certificate রাখতে পারে।
• “ACM certificate instance-এ install করো।” সাধারণ certificate দিয়ে সম্ভব না। TLS শেষ করো ALB বা CloudFront-এ; শেষ ধাপেও encryption লাগলে target-এ self-signed বা private certificate ব্যবহার করো।
• Certificate মোছা যাচ্ছে না। এটা এখনো ব্যবহার হচ্ছে। Load balancer, distribution বা custom domain-এর সাথে জোড়া certificate ACM মুছতে দেয় না; আগে জোড়াটা খোলো।
• Certificate অনেক বেশি। প্রতিটা account-এর প্রতি Region-এ ACM certificate-এর একটা quota আছে (default ২,৫০০), আর বছরে কতগুলো request করা যাবে তারও সীমা আছে; প্রতিটা environment-এর জন্য একটা করে certificate বানানো CloudFormation stack এই সীমায় ধাক্কা খেতে পারে।

#System design-এ ACM

• চেনা web front door। Route 53 alias → CloudFront (us-east-1-এ ACM certificate) → ALB (তার নিজের Region-এ নিজের ACM certificate) → instance বা container। দুটো certificate, দুটোই বিনা পয়সায়, দুটোই ACM renew করে।
• এক entry point-এ অনেক tenant। প্রতিটা customer-এর জন্য আলাদা domain-ওয়ালা একটা SaaS প্রতিটা customer-এর জন্য একটা load balancer না বানিয়ে ALB (load balancer-প্রতি default-এ আরও ২৫টা certificate) বা CloudFront-এ SNI ব্যবহার করে।
• Multi-Region active-active। প্রতিটা Region-এর ALB বা Regional API-র একই নামের জন্য নিজের certificate থাকে, প্রতিটা একই CNAME দিয়ে DNS-validated, আর সামনে Route 53-এর latency বা failover routing।
• Infrastructure as code। DNS validation আর hosted zone ID-সহ CloudFormation-এর AWS::CertificateManager::Certificate একই stack-এ certificate আর তার validation record দুটোই বানায়, তাই নতুন environment কোনো হাতের কাজ ছাড়াই HTTPS পায়।
• Governance। একটা security team Config rule (Organization-এ aggregate করা, লেসন ২০.১) আর EventBridge rule দিয়ে সব account-এর মেয়াদের ওপর নজর রাখে; কে certificate চাইতে, import করতে বা মুছতে পারবে, IAM policy দিয়ে বেঁধে দেওয়া যায়।
• প্রতিটা ধাপে encryption। CloudFront → ALB-এ ACM certificate, ALB → target-এ AWS Private CA-র private certificate, বা application-কে নিজের key রাখতেই হলে TLS passthrough-সহ NLB।

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

এই command-গুলো AWS CLI v2-এর। Public certificate বিনা পয়সায়; Route 53 hosted zone-এর জন্য মাসে ০.৫০ USD লাগে। example.com-এর জায়গায় তোমার নিয়ন্ত্রণে থাকা একটা domain বসাও।

# 1. Request a public certificate with DNS validation, for the apex and a wildcard
aws acm request-certificate --region ap-southeast-1 \
  --domain-name example.com --subject-alternative-names '*.example.com' \
  --validation-method DNS --key-algorithm RSA_2048
# { "CertificateArn": "arn:aws:acm:ap-southeast-1:111122223333:certificate/1234abcd-12ab-34cd-56ef-1234567890ab" }

ARN=arn:aws:acm:ap-southeast-1:111122223333:certificate/1234abcd-12ab-34cd-56ef-1234567890ab

# 2. Read the CNAME that proves control (one record covers example.com and *.example.com)
aws acm describe-certificate --region ap-southeast-1 --certificate-arn $ARN \
  --query 'Certificate.DomainValidationOptions[0].ResourceRecord'
# { "Name": "_3639ac514e785e898d2646601fa951d5.example.com.",
#   "Type": "CNAME",
#   "Value": "_98d2646601fa951d5a1b2c3d4e5f6a7b.xlfgrmvvlj.acm-validations.aws." }

# 3. Create it in Route 53, then wait until ACM has validated and issued the certificate
aws route53 change-resource-record-sets --hosted-zone-id Z0123456789EXAMPLE --change-batch '{
  "Changes": [{ "Action": "UPSERT", "ResourceRecordSet": {
    "Name": "_3639ac514e785e898d2646601fa951d5.example.com.", "Type": "CNAME", "TTL": 300,
    "ResourceRecords": [{ "Value": "_98d2646601fa951d5a1b2c3d4e5f6a7b.xlfgrmvvlj.acm-validations.aws." }] } }] }'
aws acm wait certificate-validated --region ap-southeast-1 --certificate-arn $ARN
aws acm describe-certificate --region ap-southeast-1 --certificate-arn $ARN \
  --query 'Certificate.[Status,NotAfter,RenewalEligibility,InUseBy]'
# [ "ISSUED", "2027-05-17T23:59:59+00:00", "INELIGIBLE", [] ]
#   (INELIGIBLE until it is attached to something: unused certificates are not renewed)

# 4. HTTPS listener on an ALB with that certificate, and a port 80 listener that redirects
aws elbv2 create-listener --load-balancer-arn $ALB_ARN --protocol HTTPS --port 443 \
  --certificates CertificateArn=$ARN --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
  --default-actions Type=forward,TargetGroupArn=$TG_ARN
aws elbv2 create-listener --load-balancer-arn $ALB_ARN --protocol HTTP --port 80 \
  --default-actions 'Type=redirect,RedirectConfig={Protocol=HTTPS,Port=443,StatusCode=HTTP_301}'

# 5. A second site on the same listener: add its certificate to the SNI list
aws elbv2 add-listener-certificates --listener-arn $LISTENER_ARN \
  --certificates CertificateArn=$RESULTS_CERT_ARN

# 6. See which certificate the ALB presents for each name (and without SNI)
openssl s_client -connect results.example.com:443 -servername results.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -enddate
# subject=CN = results.example.com
# notAfter=May 17 23:59:59 2027 GMT
openssl s_client -connect results.example.com:443 -noservername </dev/null 2>/dev/null \
  | openssl x509 -noout -subject
# subject=CN = admission.example.com     <- the default certificate

# 7. Import a third-party certificate, and re-import its renewal into the same ARN later
aws acm import-certificate --region ap-southeast-1 \
  --certificate fileb://pay_example_com.crt --private-key fileb://pay_example_com.key \
  --certificate-chain fileb://ca-chain.pem
aws acm import-certificate --region ap-southeast-1 --certificate-arn $IMPORTED_ARN \
  --certificate fileb://pay_example_com_2027.crt --private-key fileb://pay_example_com_2027.key \
  --certificate-chain fileb://ca-chain.pem

# 8. Start the daily expiry events 30 days before expiry instead of 45, and route them to SNS
aws acm put-account-configuration --region ap-southeast-1 \
  --expiry-events DaysBeforeExpiry=30 --idempotency-token cfg2026
aws events put-rule --region ap-southeast-1 --name acm-expiry \
  --event-pattern '{"source":["aws.acm"],"detail-type":["ACM Certificate Approaching Expiration"]}'
aws events put-targets --region ap-southeast-1 --rule acm-expiry \
  --targets Id=1,Arn=arn:aws:sns:ap-southeast-1:111122223333:it-alerts

# 9. The AWS Config managed rule, flagging certificates that expire within 30 days
aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "acm-certificate-expiration-check",
  "Source": { "Owner": "AWS", "SourceIdentifier": "ACM_CERTIFICATE_EXPIRATION_CHECK" },
  "InputParameters": "{\"daysToExpiration\":\"30\"}",
  "Scope": { "ComplianceResourceTypes": ["AWS::ACM::Certificate"] } }'

# 10. Custom domains for API Gateway: edge-optimized needs a us-east-1 certificate, Regional a local one
aws apigateway create-domain-name --domain-name api.example.com \
  --endpoint-configuration types=EDGE \
  --certificate-arn arn:aws:acm:us-east-1:111122223333:certificate/abcd1234-ab12-cd34-ef56-abcdef123456
aws apigateway create-domain-name --region ap-south-1 --domain-name api-in.example.com \
  --endpoint-configuration types=REGIONAL \
  --regional-certificate-arn arn:aws:acm:ap-south-1:111122223333:certificate/1a2b3c4d-1234-5678-9abc-1a2b3c4d5e6f
# Edge-optimized returns a "distributionDomainName" (d111111abcdef8.cloudfront.net),
# Regional a "regionalDomainName" (d-abc123xyz0.execute-api.ap-south-1.amazonaws.com):
# point a Route 53 alias record at it.

Console-এও চেষ্টা করো: ACM-এ certificate খুলে Renewal status, In use আর Associated resources দেখো; তারপর ব্যবহার হচ্ছে এমন একটা certificate মোছার চেষ্টা করে error-টা পড়ো।

#সারসংক্ষেপ

মূল কথাগুলো

• ACM HTTPS-এর জন্য TLS certificate বানায়, সামলায় আর বসায়। Public certificate বিনা পয়সায়, দেয় Amazon-এর CA, শুধু DV, আর নিজে নিজে renew হয়; private key AWS-এর ভেতরেই থাকে।
• Integrated service: ALB, NLB, CLB, CloudFront, API Gateway (পরীক্ষার তালিকা), সাথে App Runner, Amplify, Beanstalk, Cognito, Nitro Enclaves আর আরও কয়েকটা। সাধারণ EC2 instance না: সামনে ALB বা CloudFront বসাও। Exportable certificate (টাকা লাগে, ২০২৫) আর ACME (২০২৬) পাশের কথা।
• Validation: DNS (একটা CNAME, Route 53-এ এক click, নিজে নিজে renewal, best practice) বনাম email (পাঁচটা admin ঠিকানা, issue আর প্রতিটা renewal-এ একজন মানুষের click)। “মানুষের হাত ছাড়া renewal” → DNS validation।
• Renewal: ১৯৮ দিনের certificate, মেয়াদ ফুরোনোর ৪৫ দিন আগে renew, যদি certificate ব্যবহার হয় আর CNAME এখনো থাকে; একই ARN, নিজে নিজে আবার বসে। আটকে গেলে ৩০, ১৫, ৭, ৩ আর ১ দিন আগে event।
• Import করা certificate ACM কখনো renew করে না। মেয়াদ ফুরোনোর আগে re-import করো। নজর রাখো ৪৫ দিন আগে থেকে প্রতিদিনের EventBridge event (বদলানো যায়) আর Config rule acm-certificate-expiration-check দিয়ে।
• ALB: ALB-এর Region-এর ACM certificate-সহ HTTPS listener, port 80 → 443 redirect, TLS শেষ হয় ALB-তে। এক listener-এ অনেক domain আর certificate-এর জন্য SNI: ALB, NLB, CloudFront, API Gateway হ্যাঁ; CLB না।
• API Gateway endpoint: edge-optimized (global client, সামনে CloudFront), Regional (একই Region, বা নিজের CloudFront), private (VPC interface endpoint + resource policy)।
• Certificate-এর Region-এর নিয়ম: CloudFront আর edge-optimized custom domain-এর জন্য us-east-1; Regional API আর load balancer-এর জন্য একই Region। Certificate Regional, এক Region থেকে অন্য Region-এ কপি হয় না।
• ভেতরের private certificate-এর জন্য AWS Private CA (প্রতিটা CA-র জন্য মাসিক টাকা)।

নিজেকে যাচাই করো: AWS Certificate Manager৩১টি প্রশ্ন