NGINX-এ কীভাবে একটি SSL সার্টিফিকেট ইনস্টল করবেন

এই গাইডে দেখানো হয়েছে NGINX-এ কীভাবে একটি SSL/TLS সার্টিফিকেট ইনস্টল করবেন। এতে সেই অংশটি বিশদভাবে আলোচনা করা হয়েছে যা বেশিরভাগ মানুষকে বিভ্রান্ত করে: NGINX-এর প্রয়োজনীয় সঠিক সার্টিফিকেট চেইন (“fullchain”) তৈরি করা, সঠিক ডিরেক্টিভগুলোকে সঠিক ফাইলের দিকে নির্দেশ করা, রিলোড করার আগে কনফিগারেশন পরীক্ষা করা এবং একটি পরিষ্কার HTTP থেকে HTTPS রিডাইরেক্ট যুক্ত করা, যাতে প্রতিটি ভিজিটর আপনার সাইটের সুরক্ষিত সংস্করণে পৌঁছায়।

NGINX-এর জন্য একটি CSR কোড তৈরি করুন

আপনি যদি ইতিমধ্যে আপনার CSR তৈরি করে থাকেন এবং ইস্যু করা সার্টিফিকেট ফাইলগুলো হাতে থাকে, তাহলে সরাসরি NGINX-এ একটি SSL সার্টিফিকেট ইনস্টল করুন অংশে চলে যান।

একটি সার্টিফিকেট অথরিটি আপনার সার্টিফিকেট ইস্যু করার আগে, আপনাকে একটি CSR (Certificate Signing Request) জমা দিতে হবে: এটি একটি ছোট টেক্সট ব্লক যাতে আপনার ডোমেইনের বিবরণ এবং একটি পাবলিক কী থাকে, যা সার্ভারে সংরক্ষিত একটি প্রাইভেট কীর সঙ্গে যুক্ত থাকে। আপনার কাছে দুটি অপশন আছে:

• আমাদের CSR জেনারেটর দিয়ে স্বয়ংক্রিয়ভাবে CSR তৈরি করুন। এই টুলটি CSR এবং সংশ্লিষ্ট প্রাইভেট কী উভয়ই প্রদান করে, যা আপনি পরে সার্ভারে আপলোড করবেন।
• সার্ভারে নিজেই OpenSSL দিয়ে CSR তৈরি করুন, এর জন্য আমাদের NGINX-এ কীভাবে CSR তৈরি করবেন টিউটোরিয়ালটি অনুসরণ করুন। প্রাইভেট কী সার্ভারেই থেকে যায়।

তৈরি হওয়া .csr ফাইলটি কোনো টেক্সট এডিটরে খুলুন; ভেতরের টেক্সট ব্লক (—–BEGIN CERTIFICATE REQUEST—– এবং —–END CERTIFICATE REQUEST—– লাইন সহ) হলো সেটাই যা আপনি চেকআউটের সময় SSL অ্যাপ্লিকেশন ফর্মে পেস্ট করবেন। জমা দেওয়ার আগে CSR-এর বিষয়বস্তু নিশ্চিত করতে চাইলে, এটি আমাদের CSR ডিকোডারে পেস্ট করুন।

NGINX-এ একটি SSL সার্টিফিকেট ইনস্টল করুন

CA সার্টিফিকেট ইস্যু করার পর, সাধারণত আপনি পাবেন:

• আপনার প্রাইমারি (সার্ভার) সার্টিফিকেট, সাধারণত আপনার ডোমেইনের নামে নামকরণ করা একটি .crt ফাইল।
• ইন্টারমিডিয়েট (এবং কখনো কখনো রুট) সার্টিফিকেটগুলো, যা আলাদা .crt ফাইল হিসেবে অথবা একটি .ca-bundle ফাইলে একত্রিত থাকতে পারে।
• আপনার CSR-এর সঙ্গে তৈরি হওয়া প্রাইভেট কী (একটি .key ফাইল)।

NGINX-এর জন্য সার্ভার সার্টিফিকেট এবং ইন্টারমিডিয়েট চেইনকে একটি ফাইলে (“fullchain”) একত্রিত করে ssl_certificate দ্বারা নির্দেশ করা প্রয়োজন; প্রাইভেট কী আলাদাভাবে ssl_certificate_key দিয়ে নির্দেশ করা হয়। চেইন এড়িয়ে যাওয়া সবচেয়ে সাধারণ ইনস্টলেশন ভুল: সার্টিফিকেট ডেস্কটপ ব্রাউজারে ঠিক দেখাতে পারে, কিন্তু Android-এ, API ক্লায়েন্টে এবং আমাদের SSL Checker-এর মতো টুলে ব্যর্থ হয়।

পদক্ষেপ ১: সার্টিফিকেটগুলো একটি ফাইলে একত্রিত করুন

একত্রিত ফাইলে সার্টিফিকেটের ক্রমটি গুরুত্বপূর্ণ। প্রথমে আপনার সার্ভার সার্টিফিকেট, তারপর লিফ-ইস্যুইং CA থেকে উপরের দিকে প্রতিটি ইন্টারমিডিয়েট, এবং সবশেষে রুট (বা এটি বাদ দেওয়া যেতে পারে, কারণ ব্রাউজারগুলো ইতিমধ্যেই তাদের বিল্ট-ইন স্টোর থেকে রুটগুলোকে বিশ্বাস করে):

• ডোমেইন নামের জন্য আপনার প্রাইমারি সার্টিফিকেট।
• ইন্টারমিডিয়েট সার্টিফিকেট(গুলো)।
• রুট সার্টিফিকেট (ঐচ্ছিক)।

আপনি টেক্সট এডিটরে হাতে ফুলচেইন ফাইল তৈরি করতে পারেন (প্রতিটি PEM ব্লক ক্রমানুসারে পেস্ট করে), অথবা একটি একক cat কমান্ড দিয়ে। আপনি যদি আলাদা ইন্টারমিডিয়েট এবং রুট ফাইল পেয়ে থাকেন, তাহলে চালান:

cat your_domain.crt intermediate.crt root.crt > ssl-bundle.crt

যদি ইন্টারমিডিয়েট এবং রুট ইতিমধ্যে একটি .ca-bundle ফাইলে থাকে, তাহলে চালান:

cat example_com.crt example_com.ca-bundle > ssl-bundle.crt

ফাইলের নামগুলো আপনার নিজের ফাইলের নাম দিয়ে প্রতিস্থাপন করুন। একত্রিত ফাইলটি (এবং প্রাইভেট কী, যদি এটি সেখানে না থাকে) আপনার সার্ভারের SSL ডিরেক্টরিতে নিয়ে যান, উদাহরণস্বরূপ /etc/ssl/ বা /etc/nginx/ssl/। কী ফাইলটি কেবল root দ্বারা পাঠযোগ্য রাখুন:

sudo chmod 600 /etc/ssl/your_domain.key
sudo chown root:root /etc/ssl/your_domain.key

পদক্ষেপ ২: NGINX কনফিগারেশন ফাইল সম্পাদনা করুন

আপনার সাইটের জন্য NGINX কনফিগারেশন ফাইল খুলুন। Debian এবং Ubuntu-তে এটি /etc/nginx/sites-available/ এ থাকে (এবং sites-enabled/-এ একটি সিমলিংক থাকে); RHEL, CentOS, AlmaLinux এবং Rocky Linux-এ এটি /etc/nginx/conf.d/ এ থাকে। পোর্ট 443-এ লিসেন করা সার্ভার ব্লকটি যুক্ত বা সম্পাদনা করুন যাতে এটি ফুলচেইন ফাইল এবং প্রাইভেট কীর দিকে নির্দেশ করে:

server {
    listen 443 ssl;
    http2 on;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/ssl-bundle.crt;
    ssl_certificate_key /etc/ssl/your_domain.key;

    # Modern TLS only
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_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_session_timeout 1d;
    ssl_session_cache shared:NginxSSL:10m;
    ssl_session_tickets off;

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

উপরের ডিরেক্টিভগুলো সম্পর্কে কিছু নোট:

• listen 443 ssl; পোর্ট 443-এ TLS সক্রিয় করে। পুরনো ssl on; ডিরেক্টিভ NGINX 1.25-এ বাদ দেওয়া হয়েছে এবং আধুনিক কনফিগারেশনে এটি থাকা উচিত নয়।
• http2 on; HTTP/2-কে একটি স্বতন্ত্র ডিরেক্টিভ হিসেবে সক্রিয় করে (NGINX 1.25.1 এবং তার পরের সংস্করণে)। পুরনো কনফিগারেশনে listen 443 ssl http2; ব্যবহার করা হতো, যা এখনও কাজ করে কিন্তু এটি ডেপ্রিকেটেড।
• ssl_protocols TLSv1.2 TLSv1.3; পুরনো TLS 1.0 এবং 1.1 নিষ্ক্রিয় করে। NGINX 1.27.3 থেকে, এটি ডিরেক্টিভ বাদ দিলেও ডিফল্ট হয়ে যায়, কিন্তু এটি স্পষ্টভাবে সেট করা অডিট-বান্ধব একটি ভালো পছন্দ।
• সাইফার তালিকাটি Mozilla-এর “intermediate” প্রোফাইলের সঙ্গে মিলে যায় এবং প্রায় সব আধুনিক ক্লায়েন্টে কাজ করে। আপনার যদি কেবল TLS 1.3 ক্লায়েন্ট প্রয়োজন হয়, তাহলে ssl_ciphers সম্পূর্ণভাবে বাদ দিতে পারেন।

পদক্ষেপ ৩: HTTP থেকে HTTPS-এ রিডাইরেক্ট করুন

পোর্ট 80-এ একটি আলাদা সার্ভার ব্লক যুক্ত করুন যা প্রতিটি রিকোয়েস্টকে স্থায়ীভাবে HTTPS-এ রিডাইরেক্ট করে, যাতে সাধারণ HTTP-এর মাধ্যমে আসা ভিজিটররা সুরক্ষিত URL-এ পৌঁছায়:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

return 301 ব্যবহার করা রেগেক্স-ভিত্তিক rewrite নিয়মের তুলনায় দ্রুততর ও নিরাপদ, এবং এটি NGINX নিজেই সুপারিশ করে এমন পদ্ধতি।

পদক্ষেপ ৪: কনফিগারেশন পরীক্ষা করুন এবং NGINX রিলোড করুন

রিলোড করার আগে সবসময় কনফিগারেশন যাচাই করুন, যাতে কোনো টাইপো সার্ভিসটিকে অফলাইনে নিয়ে যেতে না পারে:

sudo nginx -t

আপনার দেখা উচিত syntax is ok এবং test is successful। যদি এটি কোনো ত্রুটি রিপোর্ট করে, তাহলে বার্তায় ফাইল এবং লাইন নম্বর উল্লেখ থাকবে; এটি ঠিক করুন এবং আবার পরীক্ষা চালান। পরীক্ষা সফল হলে, NGINX রিলোড করুন যাতে এটি বিদ্যমান সংযোগ বন্ধ না করে নতুন কনফিগারেশন গ্রহণ করে:

sudo systemctl reload nginx

systemd নেই এমন সিস্টেমে, NGINX-এর নিজস্ব রিলোড সিগন্যাল ব্যবহার করুন:

sudo nginx -s reload

restart-এর চেয়ে reload-কে প্রাধান্য দিন: একটি রিলোড সক্রিয় সংযোগ বন্ধ না করেই কনফিগারেশন পুনরায় পড়ে, যেখানে একটি রিস্টার্ট সেগুলো বন্ধ করে দেয়।

পদক্ষেপ ৫ (ঐচ্ছিক): OCSP স্টেপলিং সক্রিয় করুন

OCSP স্টেপলিং NGINX-কে সার্টিফিকেটের সঙ্গে একটি তাজা, স্বাক্ষরিত রিভোকেশন স্ট্যাটাস সরবরাহ করার সুযোগ দেয়, যাতে ক্লায়েন্টদের প্রতিটি হ্যান্ডশেকে CA-এর সঙ্গে যোগাযোগ করতে না হয়। আপনার HTTPS সার্ভার ব্লকের মধ্যে নিচের অংশটি যুক্ত করুন:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/ssl-bundle.crt;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

আবার sudo systemctl reload nginx দিয়ে NGINX রিলোড করুন। স্টেপলিং একটি ছোট কিন্তু মূল্যবান হার্ডেনিং পদক্ষেপ, এবং বেশিরভাগ আধুনিক সার্টিফিকেট এটি প্রথম থেকেই সমর্থন করে।

ইনস্টলেশন যাচাই করুন

একটি ব্রাউজারে https:// দিয়ে আপনার সাইট খুলুন এবং পরীক্ষা করুন যে প্যাডলকটি বন্ধ আছে এবং সার্টিফিকেটটি আপনার ডোমেইনের সঙ্গে মিলে যায়। তারপর আমাদের SSL Checker দিয়ে একটি গভীর স্ক্যান চালান, যা সার্টিফিকেট, চেইন এবং আপনার সার্ভার যে প্রোটোকল ও সাইফার অফার করছে সে সম্পর্কে তাৎক্ষণিক রিপোর্ট দেয়। সেখানে একটি সবুজ রেজাল্ট মানে হলো, প্রতিটি প্রধান প্ল্যাটফর্মে ক্লায়েন্টরা সার্টিফিকেটটিকে বিশ্বাস করবে, মোবাইল ও API ক্লায়েন্ট সহ।

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