HAProxy-এ SSL Certificate কীভাবে কনফিগার করবেন

HAProxy একটি TCP এবং HTTP লোড ব্যালেন্সার যা TLS টার্মিনেট করে, অর্থাৎ এটি এজে ট্র্যাফিক ডিক্রিপ্ট করে এবং প্লেইন HTTP আপনার ব্যাকএন্ড সার্ভারগুলোতে ফরওয়ার্ড করে। এটিই এই পথে থাকা একমাত্র মেশিন যার সার্টিফিকেট প্রয়োজন, এবং এটি নির্দিষ্ট একটি আকারে সেই সার্টিফিকেট চায়: একটি ফাইল, যাতে সার্টিফিকেট, কোনো ইন্টারমিডিয়েট এবং প্রাইভেট কী থাকে।

এই গাইডে সম্পূর্ণ প্রক্রিয়াটি আলোচনা করা হয়েছে: CSR জেনারেট করা, PEM ফাইল একত্র করা, ফ্রন্টএন্ড ও ব্যাকএন্ড লেখা, কনফিগারেশন যাচাই করা, এবং লাইভ কানেকশন হারানো ছাড়াই রিলোড করা। কমান্ডগুলো HAProxy 3.4-এর বিরুদ্ধে চালানো হয়েছে, যা বর্তমান লং-টার্ম সাপোর্টেড ব্রাঞ্চ, জুন 2026-এ প্রকাশিত এবং Q2 2031 পর্যন্ত মেইনটেইন করা হবে।

HAProxy কী প্রত্যাশা করে: একটি একক PEM ফাইল

অধিকাংশ সার্ভার সার্টিফিকেট, চেইন এবং কী তিনটি আলাদা সেটিং হিসেবে নেয়। HAProxy একটিমাত্র নেয়। এর কনফিগারেশন ম্যানুয়ালে crt কীওয়ার্ডকে বর্ণনা করা হয়েছে “একটি PEM ফাইল যাতে প্রয়োজনীয় সার্টিফিকেট এবং সংশ্লিষ্ট প্রাইভেট কী থাকে”, যা PEM ফাইলগুলো একসাথে যুক্ত করে তৈরি করা হয়, এবং যুক্ত করে যে “যদি আপনার CA-র একটি ইন্টারমিডিয়েট সার্টিফিকেট প্রয়োজন হয়, এটিও এই ফাইলে যুক্ত করা যেতে পারে”।

শুরু করার আগে দুটি আচরণ জেনে রাখা মূল্যবান, কারণ এগুলো পরে কাজ বাঁচায়:

• কী সার্টিফিকেটের ভেতরে থাকার পরিবর্তে পাশে থাকতে পারে। যদি ফাইলে কোনো প্রাইভেট কী না থাকে, HAProxy একই পাথে .key যুক্ত করে খুঁজে দেখে। তাই mydomain.pem এর সাথে mydomain.pem.key ঠিক তেমনই কাজ করে যেমন একটি সমন্বিত ফাইল করে।
• আপনি crt-কে একটি ডিরেক্টরির দিকে নির্দেশ করতে পারেন। HAProxy সেখানে থাকা প্রতিটি ফাইল লোড করে এবং SNI ব্যবহার করে প্রতিটি রিকোয়েস্টের জন্য সঠিক সার্টিফিকেট বেছে নেয়। এভাবেই আপনি একটি ফ্রন্টএন্ড থেকে একেকটি বাইন্ড লাইন না লিখে একাধিক সাইট পরিবেশন করেন।

CSR এবং প্রাইভেট কী জেনারেট করুন

একটি CSR হলো এনকোডেড রিকোয়েস্ট যা আপনি সার্টিফিকেট অথরিটি-র কাছে জমা দেন। HAProxy মেশিনে এটি জেনারেট করুন, বা এমন কোনো জায়গায় যেখানে আপনি প্রাইভেট কী নিরাপদে রাখতে পারবেন, কারণ কী কখনো আপনার পাশ থেকে বের হবে না।

openssl req -new -newkey rsa:2048 -nodes 
  -keyout mydomain.key -out mydomain.csr 
  -subj "/C=US/ST=California/L=San Jose/O=Your Company/CN=mydomain.com" 
  -addext "subjectAltName=DNS:mydomain.com,DNS:www.mydomain.com"

-addext লাইনটি বাস্তবে ঐচ্ছিক নয়। ব্রাউজারগুলো বছরের পর বছর আগেই কমন নেম-এর বিরুদ্ধে হোস্ট নাম মেলানো বন্ধ করে দিয়েছে এবং কেবল সাবজেক্ট অল্টারনেটিভ নেম পড়ে, তাই কেবল CN বহনকারী একটি CSR এমন একটি সার্টিফিকেট তৈরি করে যা প্রতিটি বর্তমান ব্রাউজারে ব্যর্থ হয়। সার্টিফিকেটে যেসব নাম কভার করতে হবে সেগুলো তালিকাভুক্ত করুন, যার মধ্যে খালি ডোমেইন এবং যদি দুটোই পরিবেশন করেন তাহলে www ফর্মও অন্তর্ভুক্ত করুন।

যদি আপনি প্রতিটি ফিল্ডের জন্য প্রম্পট চান, তাহলে -subj এবং -addext অপশনগুলো ফেলে দিন। যে কোনো উপায়েই আপনি দুটি ফাইল পাবেন: জমা দেওয়ার জন্য mydomain.csr, এবং রাখার জন্য mydomain.key। জমা দেওয়ার আগে নিশ্চিত করুন CSR-এ আপনি যা প্রত্যাশা করছেন তা আছে, আমাদের CSR ডিকোডার দিয়ে বা লোকালি:

openssl req -noout -text -verify -in mydomain.csr

নিশ্চিত করুন যে SAN এন্ট্রিগুলো তালিকাভুক্ত হয়েছে এবং সিগনেচার ভেরিফাই হচ্ছে। যদি আপনি কমান্ড লাইন একেবারেই ব্যবহার করতে না চান, আমাদের CSR জেনারেটর ব্রাউজারে একই জোড়া তৈরি করে। অন্তর্নিহিত কমান্ডগুলোর আরও পূর্বাভাস আমাদের OpenSSL কমান্ড গাইডে পাওয়া যাবে।

সার্টিফিকেট ইস্যু করান

CSR-টি CA-র কাছে জমা দিন, আপনি যা সুরক্ষিত করছেন তার সাথে মিলে যায় এমন সার্টিফিকেট টাইপ নির্বাচন করুন, এবং যাচাই সম্পন্ন করুন। একটি সিঙ্গল-ডোমেইন সার্টিফিকেট একটি হোস্ট নাম কভার করে, একটি ওয়াইল্ডকার্ড প্রতিটি প্রথম-স্তরের সাবডোমেইন কভার করে, এবং একটি মাল্টি-ডোমেইন (SAN) সার্টিফিকেট সম্পর্কহীন নামের একটি তালিকা কভার করে। লোড ব্যালেন্সারের পেছনে, মাল্টি-ডোমেইন হলো সাধারণ পছন্দ, কারণ একটি HAProxy ইনস্ট্যান্স সাধারণত একাধিক সাইটের সামনে থাকে।

CA আপনার সার্টিফিকেট এবং ইন্টারমিডিয়েট চেইন সমেত একটি আর্কাইভ ফেরত দেয়, সাধারণত একটি CA বান্ডেল ফাইল হিসেবে। উভয়ই ইতিমধ্যে PEM ফরম্যাটে আছে, যা আপনার প্রয়োজন। রিনিউয়ালের পরিকল্পনা এখনই করুন পরে না করে: কারণ 15 মার্চ 2026 থেকে একটি পাবলিকলি বিশ্বস্ত TLS সার্টিফিকেট বৈধ থাকতে পারবে বড়জোর 200 দিন পর্যন্ত, মার্চ 2027-এ 100 দিনে এবং মার্চ 2029-এ 47 দিনে নেমে আসবে, তাই ম্যানুয়াল প্রতিস্থাপন খুব শীঘ্রই ব্যবহারিক থাকবে না।

HAProxy যে PEM ফাইল পড়বে তা তৈরি করুন

সার্টিফিকেটের জন্য একটি ডিরেক্টরি তৈরি করুন এবং সেখানেই ফাইলটি একত্র করুন। শুরু থেকেই সবকিছু এক জায়গায় রাখুন; এটিকে হোম ডিরেক্টরি, /etc/haproxy এবং /etc/ssl-এ ভাগ করলে মানুষ একটি ফাইল সম্পাদনা করতে গিয়ে HAProxy আরেকটি পড়ে ফেলে এমন অবস্থায় পড়ে যায়।

sudo mkdir -p /etc/haproxy/certs
sudo chmod 700 /etc/haproxy/certs

সার্টিফিকেট, তারপর ইন্টারমিডিয়েটগুলো, তারপর প্রাইভেট কী একসাথে যুক্ত করুন। রিডাইরেক্টটি রুট হিসেবে চালাতে হবে, তাই sudo cat ... > /etc/haproxy/certs/... লেখার পরিবর্তে tee-তে পাইপ করুন, যা পারমিশন এরর দিয়ে ব্যর্থ হয় কারণ শেল sudo চালু হওয়ার আগেই আপনার নিজের ইউজার হিসেবে আউটপুট ফাইলটি খোলে:

cat mydomain.crt intermediate.crt mydomain.key 
  | sudo tee /etc/haproxy/certs/mydomain.pem > /dev/null

এই ফাইলে এখন আপনার প্রাইভেট কী প্লেইন টেক্সটে আছে, তাই আরও এগোনোর আগে এটি লক করুন:

sudo chown root:root /etc/haproxy/certs/mydomain.pem
sudo chmod 600 /etc/haproxy/certs/mydomain.pem

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

যদি আপনি CSR অন্য একটি মেশিনে তৈরি করে থাকেন, প্রথমে ফাইলগুলো কপি করুন এবং পরে ট্রানজিট ডিরেক্টরি থেকে কপিগুলো ডিলিট করুন:

scp mydomain.crt intermediate.crt mydomain.key sysadmin@haproxy-server:/home/sysadmin/

HAProxy কনফিগার করুন

সার্ভারেই একটি টার্মিনাল এডিটরে, যেমন nano বা vim দিয়ে /etc/haproxy/haproxy.cfg খুলুন। এটি ওয়ার্কস্টেশনে না করে সরাসরি সম্পাদনা করুন, যাতে আপনি কখনোই এমন একটি ফাইল রিলোড না করেন যা আপনি টেস্ট করা ফাইলের থেকে আলাদা।

ফ্রন্টএন্ড

একটি ফ্রন্টএন্ড প্লেইন HTTP এবং HTTPS দুটোই গ্রহণ করতে পারে। রিডাইরেক্টের জন্য পোর্ট 80 বাইন্ড করুন, সার্টিফিকেট দিয়ে পোর্ট 443 বাইন্ড করুন, এবং বাকি সবকিছু ব্যাকএন্ডে পাঠান:

frontend web_frontend
    mode http
    bind *:80
    bind *:443 ssl crt /etc/haproxy/certs/mydomain.pem alpn h2,http/1.1

    http-request redirect scheme https code 301 unless { ssl_fc }

    default_backend web_servers

alpn h2,http/1.1 HTTP/2 অফার করে এবং HTTP/1.1-এ ফলব্যাক করে। রিডাইরেক্ট কেবল তখনই ফায়ার করে যখন রিকোয়েস্ট TLS-এর ওপর আসেনি, যা ssl_fc পরীক্ষা করে, তাই পোর্ট 443-এর রিকোয়েস্টগুলো সরাসরি চলে যায়।

প্রতিটি TLS অপশন সেই একই বাইন্ড লাইনে রাখুন

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

কনফিগারেশন চেকও এটি ধরতে পারে না, এবং এর নিজের ডকুমেন্টেশন কারণ ব্যাখ্যা করে: -c “কেবল কনফিগারেশন ফাইলের একটি চেক সম্পাদন করে এবং বাইন্ড করার চেষ্টার আগে এক্সিট করে”। একটি ডুপ্লিকেট লিসেনার বাইন্ডিং-টাইম কন্ডিশন, তাই সিনট্যাক্স চেক এটি কখনো দেখতে পাবে না।

এর পরিবর্তে গ্লোবাল ডিফল্ট সেট করুন, যাতে ফাইলের প্রতিটি বাইন্ড লাইন এগুলো ইনহেরিট করে এবং ডুপ্লিকেট করার কিছু থাকে না:

global
    ssl-default-bind-options ssl-min-ver TLSv1.2 prefer-client-ciphers
    ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
    ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

এই ব্লকটি কোথাও কপি করার আগে জেনে রাখা মূল্যবান: ssl-min-ver ইতিমধ্যেই ডিফল্ট হিসেবে TLSv1.2, HAProxy-র নিজের ভাষায়। এটিকে TLSv1.2-এ সেট করলে কিছুই পরিবর্তন হয় না এবং কেবল উদ্দেশ্য দলিলবদ্ধ করে, যা ঠিক আছে, কিন্তু এটি প্রায়শই যেমন উপস্থাপন করা হয় তেমন সিকিউরিটি উন্নতি নয়। দুটি সাইফার সেটিং আসল কাজ করে, এবং এগুলো উদ্দেশ্যমূলকভাবে আলাদা: ssl-default-bind-ciphers TLS 1.2 এবং এর নিচের জন্য প্রযোজ্য, ssl-default-bind-ciphersuites TLS 1.3-এর জন্য প্রযোজ্য। কেবল প্রথমটি সেট করলে আপনার TLS 1.3 স্যুইটগুলো তাদের ডিফল্টে থেকে যায়।

ব্যাকএন্ড

প্রতিটি সার্ভারকে একটি আসল ঠিকানা দিন। এটি যেমন দেখতে সহজ তার চেয়ে অনেক বেশি গুরুত্বপূর্ণ:

backend web_servers
    mode http
    balance roundrobin
    option httpchk GET /
    server web1 10.0.0.11:80 check
    server web2 10.0.0.12:80 check

একটি সার্ভার লাইন যা server web1 :80 check হিসেবে লেখা হয়, ঠিকানা ছাড়াই, কোনো এরর তৈরি করে না। HAProxy এটি গ্রহণ করে এবং অনুপস্থিত ঠিকানাটিকে 0.0.0.0 হিসেবে রেজলভ করে, যাকে এর ম্যানুয়াল একটি বিশেষ মান হিসেবে বিবেচনা করে যার অর্থ কানেকশনটি ক্লায়েন্ট যে IP ঠিকানায় সংযুক্ত হয়েছিল সেই একই ঠিকানায় ফরওয়ার্ড করা হয়। সেই ঠিকানাটি হলো HAProxy নিজেই, তাই ব্যাকএন্ড নিঃশব্দে HAProxy-র নিজের পোর্ট 80-এর দিকে নির্দেশ করে, যা আপনার সবেমাত্র কনফিগার করা ফ্রন্টএন্ড। ট্র্যাফিক কোনো অ্যাপ্লিকেশনে পৌঁছানোর পরিবর্তে রিডাইরেক্টে ঘুরে আসে, এবং হেলথ চেকগুলো স্বাস্থ্যবান দেখায় কারণ কিছু আসলেই শুনছে। যদি একটি লোড ব্যালেন্সার প্রতিটি HTTPS রিকোয়েস্টের জবাব নিজেরই দিকে একটি রিডাইরেক্ট দিয়ে দেয়, তাহলে প্রথমে সার্ভার লাইনগুলো পরীক্ষা করুন।

যেহেতু HAProxy TLS টার্মিনেট করে, ব্যাকএন্ডগুলো পোর্ট 80-এ প্লেইন HTTP পায় এবং তাদের নিজের কোনো সার্টিফিকেট প্রয়োজন হয় না। যদি পলিসি অনুযায়ী সেই লেগেও এনক্রিপশন প্রয়োজন হয়, তাহলে সার্ভার লাইনগুলোতে ssl verify required এবং একটি CA ফাইল যুক্ত করুন এবং তাদেরকে পোর্ট 443-এর দিকে নির্দেশ করুন।

মূল স্কিমটি ব্যাকএন্ডে পাস করুন। যেহেতু ব্যাকএন্ড এখন প্লেইন HTTP পায়, একটি অ্যাপ্লিকেশন যা অ্যাবসোলিউট URL তৈরি করে, যেমন WordPress, Django এবং Rails সবই করে, সেগুলো http:// দিয়ে তৈরি করবে, যা মিক্সড কনটেন্ট বা অ্যাপ্লিকেশন নিজেই তৈরি করা একটি রিডাইরেক্ট লুপ হিসেবে সামনে আসে। ফ্রন্টএন্ডে একটি লাইন যুক্ত করুন:

http-request set-header X-Forwarded-Proto https if { ssl_fc }

এবং ব্যাকএন্ডে একটি, যা প্রকৃত ক্লায়েন্ট IP ঠিকানাও পাস করে:

option forwardfor

তারপর অধিকাংশ ফ্রেমওয়ার্ককে এই হেডারগুলো বিশ্বাস করার জন্য বলা প্রয়োজন হয়; এই অংশটি HAProxy-তে না, অ্যাপ্লিকেশনেই কনফিগার করা হয়।

প্রয়োগ করার আগে কনফিগারেশন চেক করুন

কখনো একটি যাচাই না করা ফাইলে লোড ব্যালেন্সার রিস্টার্ট করবেন না। প্রথমে ভ্যালিডেট করুন:

sudo haproxy -c -V -f /etc/haproxy/haproxy.cfg

-V দিয়ে সাফল্যে এটি Configuration file is valid প্রিন্ট করে এবং এক্সিট স্ট্যাটাস শূন্য ফেরত দেয়। এটি ছাড়া, সাফল্য নিঃশব্দ। ফাইলটি বৈধ হোক বা না হোক, যেকোনো ওয়ার্নিং রিপোর্ট করা হয়, তাই লাল টেক্সটের অনুপস্থিতিকে বিশ্বাস করার পরিবর্তে আউটপুট পড়ুন।

রিস্টার্টের পরিবর্তে রিলোড করুন

sudo systemctl reload haproxy

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

নিশ্চিত করুন সার্ভিসটি ফিরে এসেছে এবং দুটি পোর্টেই শুনছে:

sudo systemctl status haproxy
sudo ss -tlnp | grep haproxy

প্রতিটি পোর্টে ঠিক একটি লিসেনিং সকেট থাকাই এখানে আপনার চাওয়া। পোর্ট 443-এ দুটি মানে আপনার আগে বর্ণিত ডুপ্লিকেট বাইন্ড লাইন আছে।

সার্টিফিকেটটি পরিবেশন করা হচ্ছে যাচাই করুন

সার্ভার থেকেই HAProxy আসলে কী উপস্থাপন করে তা চেক করুন, চেইনসহ:

openssl s_client -connect mydomain.com:443 -servername mydomain.com < /dev/null

আউটপুটের উপরে থাকা Certificate chain সেকশনটি পড়ুন। আপনার সার্টিফিকেট depth 0-তে এবং ইন্টারমিডিয়েট depth 1-তে থাকা উচিত। যদি depth 1 অনুপস্থিত থাকে, তাহলে ইন্টারমিডিয়েট কখনো PEM ফাইলে পৌঁছায়নি, এবং সাইটটি কিছু ব্রাউজারে কাজ করবে অন্যগুলোতে ব্যর্থ হবে। এটি বিচার করার সময় Verify return code লাইন উপেক্ষা করুন: এটি কেবল চেইনের ফলাফল রিপোর্ট করে, এবং এটি এমন পরিস্থিতিতে সফল হিসেবে পড়া যেতে পারে যেগুলোর সাথে আপনি যা পরীক্ষা করছেন তার কোনো সম্পর্ক নেই।

তারপর বাইরে থেকে নিশ্চিত করুন, যেখানে ফলাফল প্রকৃত দর্শকরা যা পায় তা প্রতিফলিত করে। আমাদের SSL Checker সার্টিফিকেট, চেইন এবং মেয়াদ শেষ হওয়ার তারিখ রিপোর্ট করে।

রিনিউয়াল এবং অটোমেশন

PEM ফাইল প্রতিস্থাপন করাই হলো সম্পূর্ণ রিনিউয়াল প্রক্রিয়া: নতুন সার্টিফিকেট এবং একই বা নতুন কী থেকে এটি পুনর্নির্মাণ করুন, তারপর রিলোড করুন। HAProxy কনফিগারেশনে মেয়াদ শেষ হওয়ার তারিখের কোনো রেফারেন্স নেই, তাই ফাইল পাথ একই থাকলে কোনো কনফিগ সম্পাদনার প্রয়োজন হয় না।

সার্টিফিকেটের লাইফটাইম সংক্ষিপ্ত হওয়ায়, অটোমেশন এখনই সেট আপ করা মূল্যবান। HAProxy সংস্করণ 3.2-এ একটি বিল্ট-ইন ACME ক্লায়েন্ট পেয়েছে, যা একটি acme সেকশনের মাধ্যমে কনফিগার করা হয়। এই মুহূর্তে এটিকে প্রোডাকশন ইনফ্রাস্ট্রাকচারের পরিবর্তে একটি প্রিভিউ হিসেবে বিবেচনা করুন: এটি 3.4-এও এখনও এক্সপেরিমেন্টাল হিসেবে চিহ্নিত এবং গ্লোবাল সেকশনে expose-experimental-directives প্রয়োজন, এটি কেবল http-01, dns-01 এবং dns-persist-01 চ্যালেঞ্জ টাইপ সাপোর্ট করে, এবং এটি যে সার্টিফিকেট তৈরি করে সেগুলো ডিস্কে পৌঁছাতে স্ট্যাটস সকেট থেকে ডাম্প করতে হয়। dns-persist-01 টাইপ, যা 3.4-এ যুক্ত হয়েছে, একটি স্ট্যাটিক TXT রেকর্ড ব্যবহার করে যা একবার সেট হয় এবং রিনিউয়ালের মধ্যে কখনো পরিবর্তিত হয় না, তাই প্রতিটি রিনিউয়ালে DNS প্রোভাইডার API-তে রাইট অ্যাক্সেসের প্রয়োজন হয় না। প্রতিষ্ঠিত বিকল্পটি হলো একটি এক্সটার্নাল ACME ক্লায়েন্ট চালানো এবং তার ডিপ্লয় স্টেপ PEM ফাইল পুনর্নির্মাণ করে এবং HAProxy রিলোড করে, যা আমাদের Apache এবং NGINX-এর জন্য ACME গাইড-এ বর্ণিত একই প্যাটার্ন।

সচরাচর জিজ্ঞাসিত প্রশ্নাবলী

যদি সার্টিফিকেট ইনস্টল থাকা সত্ত্বেও ব্রাউজারগুলো তবুও অভিযোগ করে, আমাদের সাধারণ SSL এরর গাইডগুলো সাধারণ কারণগুলো কভার করে, বেশিরভাগ সময়ই একটি অসম্পূর্ণ চেইন বা এমন একটি নাম যা সার্টিফিকেট তালিকাভুক্ত করে না।