OpenSSL ব্যবহার করে কীভাবে একটি Self-Signed সার্টিফিকেট তৈরি করবেন?

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

এই গাইডে আপনাকে দেখানো হবে Windows, Linux এবং macOS-এ OpenSSL দিয়ে কীভাবে সেলফ-সাইনড সার্টিফিকেট তৈরি করবেন। কমান্ডটি তিনটিতেই একই। এছাড়াও আপনি দেখবেন আপনার তৈরি করা সার্টিফিকেট আসলেই ব্যবহারযোগ্য কিনা তা কীভাবে যাচাই করবেন, এবং কীভাবে আপনার নিজের মেশিনকে সেটি বিশ্বাস করাবেন যাতে ব্রাউজারের সতর্কবার্তা দূর হয়ে যায়।

সেলফ-সাইনড সার্টিফিকেট কী

একটি সেলফ-সাইনড সার্টিফিকেট এমন একটি ডিজিটাল সার্টিফিকেট যা একটি বিশ্বাসযোগ্য সার্টিফিকেট অথরিটি (CA) দ্বারা না হয়ে নিজের প্রাইভেট কী দিয়ে সাইন করা হয়। ক্রিপ্টোগ্রাফিকভাবে এটি একটি সাধারণ X.509 সার্টিফিকেট: এটি ঠিক কেনা সার্টিফিকেটের মতোই ট্র্যাফিক এনক্রিপ্ট করে। এতে যা নেই তা হলো একটি ট্রাস্ট চেইন। আপনার নিজের মেশিনের বাইরে কারো এটিকে বিশ্বাস করার কোনো কারণ নেই, তাই আপনি অন্যভাবে না বললে ব্রাউজারগুলো সতর্কবার্তা দেখায়।

এই কারণে সেলফ-সাইনড সার্টিফিকেট নিচের ক্ষেত্রে উপযোগী:

• লোকাল ডেভেলপমেন্ট, যেখানে আপনার HTTPS প্রয়োজন যাতে কুকিজ, সার্ভিস ওয়ার্কার, বা পেমেন্ট SDK প্রোডাকশনের মতোই কাজ করে।
• অভ্যন্তরীণ সার্ভিস যেমন একটি ইন্ট্রানেট ড্যাশবোর্ড, একটি মনিটরিং প্যানেল, বা একটি প্রাইভেট নেটওয়ার্কে ডিভাইস ম্যানেজমেন্ট ইন্টারফেস।
• টেস্টিং এবং স্টেজিং, যেখানে আপনি একটি TLS কনফিগারেশন যাচাই করতে চান একটি সার্টিফিকেট খরচ না করেই।
• প্রক্সির পেছনে থাকা অরিজিন সার্ভার যা ব্যাক-এন্ড লেগে একটি অবিশ্বস্ত সার্টিফিকেট গ্রহণ করে, যেমন Cloudflare-এর Full মোডে।

বাস্তব ভিজিটর লোড করবে এমন কোনো জিনিসের জন্য এগুলো ভুল টুল। আমরা এই পার্থক্য বিস্তারিতভাবে নিচে “কখন এটি ব্যবহার করবেন না” বিভাগে আলোচনা করেছি।

শুরু করার আগে: আপনার OpenSSL যাচাই করুন

আপনার OpenSSL কমান্ড-লাইন টুল প্রয়োজন। আপনার কাছে কী আছে তা নিশ্চিত করুন:

openssl version

• Linux: বেশিরভাগ ডিস্ট্রিবিউশনে OpenSSL আগে থেকেই ইনস্টল করা থাকে। না থাকলে, আমাদের Ubuntu-তে OpenSSL কীভাবে ইনস্টল করবেন গাইডটি দেখুন।
• Windows: OpenSSL এতে অন্তর্ভুক্ত নয়। আমাদের Windows-এ OpenSSL কীভাবে ইনস্টল করবেন নির্দেশনা অনুসরণ করুন, তারপর Command Prompt বা PowerShell থেকে কমান্ডটি চালান।
• macOS: Apple বিল্ট-ইন openssl কমান্ড হিসেবে LibreSSL সরবরাহ করে, যা OpenSSL-এর একটি ফর্ক, তাই এটি OpenSSL ভার্সনের বদলে LibreSSL 3.3.6-এর মতো কিছু রিটার্ন করে।

এই গাইডের মূল কমান্ডটি LibreSSL 3.3.6 এবং বর্তমান OpenSSL দুটিতেই কাজ করে, তাই Mac ব্যবহারকারীরা বিল্ট-ইন টুল ব্যবহার করতে পারেন। আপনি যদি বরং প্রকৃত OpenSSL চান (নিচের কিছু ঐচ্ছিক কমান্ডে এটি প্রয়োজন), তাহলে Homebrew প্যাকেজ ম্যানেজার দিয়ে এটি ইনস্টল করুন এবং এর সম্পূর্ণ পাথ দিয়ে কল করুন:

brew install openssl@3
/opt/homebrew/opt/openssl@3/bin/openssl version

Intel Mac-এ পাথ হয় /usr/local/opt/openssl@3/bin/openssl। আউটপুট পড়ার আরও বিস্তারিত জানতে আমাদের আপনার OpenSSL ভার্সন কীভাবে চেক করবেন গাইডটি দেখুন।

OpenSSL দিয়ে সেলফ-সাইনড সার্টিফিকেট কীভাবে তৈরি করবেন

পদক্ষেপ ১: একটি টার্মিনাল খুলুন

Linux-এ, Ctrl + Alt + T চাপুন বা আপনার অ্যাপ্লিকেশন মেনুতে “Terminal” সার্চ করুন। macOS-এ, Applications খুলুন, তারপর Utilities, তারপর Terminal, বা Cmd + Space চাপুন এবং “Terminal” টাইপ করুন। Windows-এ, Win + R চাপুন, cmd টাইপ করুন, এবং Enter চাপুন।

পদক্ষেপ ২: যেখানে ফাইলগুলো রাখতে চান সেই ফোল্ডারে যান

OpenSSL তার আউটপুট আপনি এখন যে ডিরেক্টরিতে আছেন সেখানে লেখে, OpenSSL যেখানে ইনস্টল করা আছে সেখানে নয়। এই সার্টিফিকেটের জন্য একটি ফোল্ডার তৈরি করুন এবং সেখানে যান যাতে কী ও সার্টিফিকেট এমন জায়গায় থাকে যেখানে আপনি খুঁজে পাবেন:

mkdir my-cert
cd my-cert

Windows-এ, Command Prompt-এ একই দুটি কমান্ড ব্যবহার করুন। OpenSSL প্রোগ্রাম ফোল্ডারের ভেতর থেকে কমান্ডগুলো চালাবেন না: Windows-এ ওই ডিরেক্টরি প্রায়ই সাধারণ ব্যবহারকারীর জন্য লেখার অনুমতি থাকে না, এবং আপনার কী-গুলো বাইনারিগুলোর সাথে মিশিয়ে দিলে সেগুলো হারিয়ে যাওয়া সহজ হয়ে যায়।

পদক্ষেপ ৩: সার্টিফিকেট কমান্ডটি চালান

এই একটি কমান্ড প্রাইভেট কী এবং সেলফ-সাইনড সার্টিফিকেট একসাথে তৈরি করে। example.com এবং www.example.com-এর জায়গায় আপনার সার্ভিসে আসলে যে নামে পৌঁছানো হবে তা লিখুন:

openssl req -x509 -newkey rsa:2048 -keyout private.key -out certificate.crt -days 365 -nodes -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

এটি একটি লাইনে রাখুন। Command Prompt এবং Unix শেল বিভিন্ন লাইন-কন্টিনুয়েশন ক্যারেক্টার ব্যবহার করে, এবং একটি একক লাইন সব জায়গায় কাজ করে। একই কারণে সিঙ্গল কোটের বদলে ডাবল কোট ব্যবহার করুন: Command Prompt সিঙ্গল কোটকে কোটিং হিসেবে বিবেচনা করে না।

এখানে প্রতিটি অংশ যা করে:

• req -x509: একটি সার্টিফিকেট সাইনিং রিকোয়েস্টের বদলে একটি সম্পূর্ণ, সাইন করা সার্টিফিকেট তৈরি করে।
• -newkey rsa:2048: একই কমান্ডের অংশ হিসেবে একটি নতুন 2048-বিট RSA প্রাইভেট কী তৈরি করে। 2048 বিট হলো বর্তমান সর্বনিম্ন এবং একটি যুক্তিসঙ্গত ডিফল্ট। আপনার পলিসিতে বড় কী প্রয়োজন হলে rsa:4096 ব্যবহার করুন, যদিও এতে হ্যান্ডশেক ধীর হবে।
• -keyout private.key: প্রাইভেট কী-এর ফাইলনেম।
• -out certificate.crt: সার্টিফিকেটের ফাইলনেম।
• -days 365: সার্টিফিকেট কতদিন ভ্যালিড থাকবে। এটি পরিবর্তন করার আগে নিচের ভ্যালিডিটি অংশটি পড়ুন।
• -nodes: প্রাইভেট কী এনক্রিপ্ট না করে রাখে, যাতে কোনো মানুষ পাসফ্রেজ টাইপ না করেই আপনার ওয়েব সার্ভার চালু হতে পারে।
• -addext “subjectAltName=…”: যে হোস্টনেমগুলোর জন্য সার্টিফিকেটটি ভ্যালিড তার তালিকা। এটি না থাকলে, সার্টিফিকেটটি কোনো কিছুর সাথে মেলে না।
• -addext “basicConstraints=critical,CA:FALSE”: সার্টিফিকেটটিকে একটি সার্টিফিকেট অথরিটির বদলে একটি এন্ড-এন্টিটি (সার্ভার) সার্টিফিকেট হিসেবে চিহ্নিত করে।
• -addext “extendedKeyUsage=serverAuth”: বলে দেয় যে সার্টিফিকেটটি একটি TLS সার্ভার প্রমাণীকরণের জন্য। Apple প্ল্যাটফর্মগুলো এটিকে বাধ্যতামূলক বলে বিবেচনা করে।

তিনটি -addext অপশন কেন গুরুত্বপূর্ণ

এই তিনটি ফ্ল্যাগ হলো একটি কার্যকর সার্টিফিকেট এবং এমন একটি সার্টিফিকেটের মধ্যে পার্থক্য যাকে ক্লায়েন্টগুলো সরাসরি প্রত্যাখ্যান করে। এগুলো বোঝা গুরুত্বপূর্ণ, কারণ এগুলো ছাড়া তৈরি করা একটি সেলফ-সাইনড সার্টিফিকেট তিনটি ভিন্ন উপায়ে ব্যর্থ হয় যেগুলো ভুলভাবে নির্ণয় করা সহজ।

Subject Alternative Name-এই হোস্টনেম থাকে। ব্রাউজারগুলো বছর আগে Common Name ফিল্ড পড়া বন্ধ করে দিয়েছে এবং এখন শুধুমাত্র Subject Alternative Name (SAN) এক্সটেনশনের সাথে হোস্টনেম মেলায়। SAN না থাকা সার্টিফিকেট কোনো সাইটের সাথে মেলে না, Common Name যতই সঠিক দেখাক। আপনি যে সব নাম ব্যবহার করবেন তার তালিকা করুন, কমা দিয়ে আলাদা করে। একটি লোকাল সার্ভিসের জন্য আপনি একটি IP অ্যাড্রেসও অন্তর্ভুক্ত করতে পারেন:

-addext "subjectAltName=DNS:localhost,DNS:dev.example.com,IP:127.0.0.1"

CA:FALSE ছাড়া, OpenSSL আপনার জন্য একটি CA সার্টিফিকেট তৈরি করে। যখন req -x509-কে তার নিজস্ব ডিফল্টে ছেড়ে দেওয়া হয়, এটি basicConstraints-কে critical, CA:TRUE সেট করে, যা একটি সার্টিফিকেট অথরিটি বর্ণনা করে, একটি ওয়েব সার্ভার নয়। Chrome এবং Safari একটি সার্ভার সার্টিফিকেটে এটি গ্রহণ করে। Firefox করে না, এবং MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY দিয়ে থেমে যায়। আপনি এখনও Advanced ক্লিক করে একটি এক্সেপশন যুক্ত করতে পারেন, কিন্তু আপনি এমন একটি সার্টিফিকেটের সমস্যা ঘুরিয়ে চলবেন যা আপনি আগে থেকেই জানেন ভুলভাবে গঠিত, এবং অন্য ক্লায়েন্টগুলো ভিন্ন জায়গায় সীমা টানে। basicConstraints=critical,CA:FALSE পাস করলে শুরু থেকেই এই সমস্যা এড়ানো যায়।

macOS-এ সরবরাহকৃত LibreSSL বিল্ড এখানে আলাদাভাবে আচরণ করে: নিজস্ব ডিফল্টে ছেড়ে দিলে এটি কোনো এক্সটেনশন ছাড়া একটি X.509 ভার্সন ১ সার্টিফিকেট লেখে, তাই আপনার কোনো CA:TRUE সমস্যা হয় না কিন্তু কোনো Subject Alternative Name-ও থাকে না। এক্সটেনশনগুলো স্পষ্টভাবে সরবরাহ করলে দুটি টুলেই আপনি একই, সঠিক সার্টিফিকেট পাবেন।

serverAuth ছাড়া, Apple প্ল্যাটফর্মগুলো সার্টিফিকেট প্রত্যাখ্যান করে। Apple-এর প্রকাশিত বিশ্বাসযোগ্য সার্টিফিকেটের প্রয়োজনীয়তা বলে যে একটি TLS সার্ভার সার্টিফিকেটে id-kp-serverAuth OID ধারণ করা একটি ExtendedKeyUsage এক্সটেনশন থাকতে হবে। এটি ছাড়া একটি সার্টিফিকেট TLS পলিসির অধীনে macOS সার্টিফিকেট ভ্যালিডেশনে “Invalid Extended Key Usage for policy” বার্তা দিয়ে ব্যর্থ হয়, এমনকি যখন সার্টিফিকেটটি তার নিজেরই ট্রাস্ট অ্যাংকর হিসেবে সরবরাহ করা হয়। Firefox এবং Chrome এতে বেশি ক্ষমাশীল এবং একটি সার্ভার সার্টিফিকেটে অনুপস্থিত ExtendedKeyUsage-কে অনুমোদিত হিসেবে বিবেচনা করে, তাই এটি মিস করা সহজ যতক্ষণ না একটি Mac বা একটি iPhone সংযোগ করতে না পারার বিষয়টি হয়ে ওঠে। extendedKeyUsage=serverAuth যুক্ত করা অন্য প্ল্যাটফর্মগুলোতে কিছুই খরচ করে না এবং এটিই একটি পাবলিক CA যাই হোক ইস্যু করবে।

পদক্ষেপ ৪: সার্টিফিকেটের বিবরণ পূরণ করুন

OpenSSL Distinguished Name গঠনকারী ফিল্ডগুলো জিজ্ঞাসা করে। এদের কোনো একটি এড়িয়ে যেতে Enter চাপুন, কিন্তু অন্তত একটি পূরণ করুন, এবং সেটি Common Name করুন। macOS-এর LibreSSL বিল্ড, আপনি যদি প্রতিটি ফিল্ড খালি রাখেন, “error, no objects specified in config file” দিয়ে থেমে যায় এবং কিছু লেখে না। নিচের মানগুলো উদাহরণ, তাই আপনার নিজের ব্যবহার করুন:

• Country Name: আপনার দেশের দুই-অক্ষরের কোড, উদাহরণস্বরূপ US।
• State or Province Name: সম্পূর্ণভাবে লেখা, উদাহরণস্বরূপ California।
• Locality Name: আপনার শহর, উদাহরণস্বরূপ San Jose।
• Organization Name: আপনার কোম্পানি বা প্রজেক্টের নাম, উদাহরণস্বরূপ Example Inc।
• Organizational Unit Name: দায়িত্বপ্রাপ্ত টিম, উদাহরণস্বরূপ IT।
• Common Name: মূল হোস্টনেম, উদাহরণস্বরূপ example.com। Subject Alternative Name তালিকায় আপনি যে নামটি প্রথমে দিয়েছেন সেটিই ব্যবহার করুন।
• Email Address: একটি যোগাযোগের অ্যাড্রেস, উদাহরণস্বরূপ [email protected]। ঐচ্ছিক।

এখানে শুধু Common Name-ই সত্যিকারের গুরুত্বপূর্ণ, এবং তা শুধু একটি লেবেল হিসেবে: হোস্টনেম মিলানো হয় আপনি কমান্ড লাইনে যে Subject Alternative Name সেট করেছেন তা দিয়ে। বাকি সবকিছু বর্ণনামূলক।

আপনি খেয়াল করবেন কমান্ডটি কখনো চ্যালেঞ্জ পাসওয়ার্ড জিজ্ঞাসা করে না। এই প্রম্পট সার্টিফিকেট সাইনিং রিকোয়েস্টের অন্তর্গত, এবং এটি একটি অবশিষ্ট ফিল্ড যা CA-গুলো সাধারণত উপেক্ষা করে বা প্রত্যাখ্যান করে। কারণ এই কমান্ড একটি রিকোয়েস্টের বদলে একটি সম্পূর্ণ সার্টিফিকেট তৈরি করে, প্রম্পটটি মোটেও দেখা যায় না।

পদক্ষেপ ৫: ব্যবহারের আগে সার্টিফিকেটটি যাচাই করুন

এটি এড়িয়ে যাবেন না। একটি সেলফ-সাইনড সার্টিফিকেট সফলভাবে তৈরি হতে পারে এবং তারপরেও অব্যবহারযোগ্য হতে পারে, এবং সেই ব্যর্থতা শুধু পরে একটি ব্রাউজার এরর হিসেবে দেখা যায়। সার্টিফিকেটটি পড়ে দেখুন:

openssl x509 -in certificate.crt -noout -text

X509v3 extensions ব্লকে আপনি ঠিক তিনটি বিষয় খুঁজছেন:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com
X509v3 Basic Constraints: critical
    CA:FALSE
X509v3 Extended Key Usage:
    TLS Web Server Authentication

Subject Alternative Name লাইন অনুপস্থিত থাকলে, সার্টিফিকেটটি কোনো হোস্টনেমের সাথে মিলবে না। Basic Constraints-এ CA:TRUE লেখা থাকলে, Firefox এতে থেমে যাবে। Extended Key Usage লাইন অনুপস্থিত থাকলে, Apple প্ল্যাটফর্মগুলো সার্টিফিকেটটি প্রত্যাখ্যান করবে। এই ক্ষেত্রগুলোর কোনোটি ঘটলে, দুটি ফাইল ডিলিট করুন এবং তিনটি -addext অপশন সহ কমান্ডটি আবার চালান।

OpenSSL 3.x-এ পুরো সার্টিফিকেট পড়ার বদলে আপনি শুধু ওই এক্সটেনশনগুলো চাইতে পারেন:

openssl x509 -in certificate.crt -noout -ext subjectAltName,basicConstraints,extendedKeyUsage

macOS-এ সরবরাহকৃত LibreSSL বিল্ডে -ext ফ্ল্যাগ নেই, যা “unknown option -ext” রিপোর্ট করে। একটি স্টক Mac-এ, উপরের -text ভার্সনটি ব্যবহার করুন।

সার্টিফিকেট এবং কী একসাথে সম্পর্কিত কিনা নিশ্চিত করতে, তাদের modulus তুলনা করুন। দুটি কমান্ডকে একই হ্যাশ প্রিন্ট করতে হবে:

openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in private.key | openssl md5

সার্টিফিকেটটি নিজেই একটি টেক্সট ফাইল। একটি টেক্সট এডিটরে এটি খুললে BEGIN CERTIFICATE এবং END CERTIFICATE লাইনের মধ্যে একটি base64 ব্লক দেখায়, যা আপনি ফাইল আপলোডের বদলে সার্টিফিকেট চাওয়া কন্ট্রোল প্যানেলে পেস্ট করেন।

কমান্ডের বিভিন্ন রূপ

কোনো প্রম্পট ছাড়াই এটি তৈরি করুন

স্ক্রিপ্ট এবং CI পাইপলাইনের জন্য, -subj দিয়ে Distinguished Name সরবরাহ করুন এবং কমান্ডটি অপরিদর্শনভাবে চলে:

openssl req -x509 -newkey rsa:2048 -keyout private.key -out certificate.crt -days 365 -nodes -subj "/C=US/ST=California/L=San Jose/O=Example Inc/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

RSA-এর বদলে একটি EC কী ব্যবহার করুন

সমান শক্তিতে ইলিপ্টিক-কার্ভ কী RSA-এর চেয়ে ছোট এবং দ্রুত, এবং প্রতিটি বর্তমান ব্রাউজার এগুলো সাপোর্ট করে। P-256 হলো স্ট্যান্ডার্ড পছন্দ:

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -keyout private.key -out certificate.crt -days 365 -nodes -addext "subjectAltName=DNS:example.com,DNS:www.example.com" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth"

ফলাফল ecdsa-with-SHA256 দিয়ে সাইন করা হয়। আপনার পুরনো এমবেডেড ক্লায়েন্ট বা লিগ্যাসি Java ভার্সন সাপোর্ট করতে হলে RSA-তেই থাকুন, যেগুলোতে কখনো কখনো EC সাপোর্ট থাকে না।

এর জন্য প্রকৃত OpenSSL ব্যবহার করুন। macOS-এর LibreSSL বিল্ড কমান্ডটি গ্রহণ করে, কিন্তু এটি স্ট্যান্ডার্ড P-256 আইডেন্টিফায়ারের বদলে সার্টিফিকেটে কার্ভটি সম্পূর্ণ এক্সপ্লিসিট প্যারামিটারের সেট হিসেবে লেখে। RFC 5480 বলে যে এক্সপ্লিসিট ফর্ম সার্টিফিকেটে ব্যবহার করা যাবে না, এবং macOS নিজেই এভাবে এনকোড করা সার্টিফিকেট প্রত্যাখ্যান করে।

openssl x509 -in certificate.crt -noout -text দিয়ে ফলাফলটি চেক করুন: আপনি চান “ASN1 OID: prime256v1” লেখা একটি লাইন, Prime, A, B, এবং Generator তালিকাভুক্ত একটি ব্লক নয়। একটি স্টক Mac-এ, উপরের RSA কমান্ডটি ব্যবহার করুন বা প্রথমে Homebrew দিয়ে OpenSSL ইনস্টল করুন।

-nodes নাকি -noenc?

দুটি ফ্ল্যাগই একই কাজ করে: এগুলো OpenSSL-কে একটি পাসফ্রেজ দিয়ে প্রাইভেট কী এনক্রিপ্ট করা থেকে বিরত রাখে। OpenSSL 3.x আরও স্পষ্ট নাম হিসেবে -noenc যুক্ত করেছে এবং -nodes-কে ডিপ্রিকেটেড হিসেবে তালিকাভুক্ত করেছে, যদিও এটি এখনও গ্রহণ করে। macOS-এ সরবরাহকৃত LibreSSL -noenc মোটেও স্বীকৃতি দেয় না এবং এরর দেয়।

এই গাইডে -nodes ব্যবহার করা হয়েছে কারণ এটি এমন অপশন যা আপনি সম্ভবত দেখতে পাবেন এমন প্রতিটি বিল্ডে কাজ করে, স্টক Mac সহ। আপনি যদি OpenSSL 3.x-এ থাকেন এবং ডিপ্রিকেটেড স্পেলিং এড়াতে চান, তাহলে -noenc দিয়ে বদলান। আর কিছু পরিবর্তন হয় না।

আপনি যদি ফ্ল্যাগটি সম্পূর্ণভাবে বাদ দেন, OpenSSL আপনার পছন্দ করা একটি পাসফ্রেজ দিয়ে কী এনক্রিপ্ট করে, এবং আপনার ওয়েব সার্ভার তখন প্রতিটি রিস্টার্টে এটি জিজ্ঞাসা করবে। এটি সাধারণত একটি ডেভেলপমেন্ট সার্টিফিকেটের জন্য যা আপনি চান না।

আপনার মেশিনকে সার্টিফিকেট বিশ্বাস করান

একটি সঠিক সেলফ-সাইনড সার্টিফিকেটও একটি ব্রাউজার সতর্কবার্তা তৈরি করে, কারণ কাউকে এটি বিশ্বাস করতে বলা হয়নি। এটিকে আপনার লোকাল ট্রাস্ট স্টোরে যুক্ত করাই সতর্কবার্তাটি বন্ধ করে, এবং এটি সাধারণত একটি তৈরি করার মূল উদ্দেশ্য।

এটি শুধুমাত্র আপনার নিয়ন্ত্রণে থাকা মেশিনে করুন, এবং শুধুমাত্র আপনি নিজে তৈরি করা সার্টিফিকেটের জন্য। একটি বিশ্বাসযোগ্য সার্টিফিকেট এটি যে প্রতিটি সাইটের নাম উল্লেখ করে সেগুলোর জন্য বিশ্বাসযোগ্য, তাই প্রাইভেট কী-কে সেভাবেই বিবেচনা করুন এবং কখনো শেয়ার করবেন না।

macOS Keychain

সার্টিফিকেটটি সিস্টেম কীচেইনে যুক্ত করুন এবং এটিকে TLS-এর জন্য বিশ্বাসযোগ্য হিসেবে চিহ্নিত করুন। আপনাকে আপনার প্রশাসক পাসওয়ার্ড জিজ্ঞাসা করা হবে:

sudo security add-trusted-cert -d -r trustRoot -p ssl -k /Library/Keychains/System.keychain certificate.crt

-p ssl অংশটি বিশ্বাসকে TLS সংযোগে সীমাবদ্ধ করে। এটি বাদ দিলে সার্টিফিকেটটি macOS জানে এমন প্রতিটি উদ্দেশ্যের জন্য বিশ্বাসযোগ্য হয়ে যায়, কোড সাইনিং সহ, যা একটি ডেভেলপমেন্ট সার্টিফিকেটের প্রয়োজনের চেয়ে অনেক বেশি।

ইন্টারফেসের মাধ্যমে এটি করতে, সার্টিফিকেট ফাইলে ডাবল-ক্লিক করুন Keychain Access খুলতে, System কীচেইনের অধীনে এন্ট্রি খুঁজুন, এটি খুলুন, Trust সম্প্রসারিত করুন, এবং When using this certificate-কে Always Trust-এ সেট করুন। এটি পরে বাতিল করতে, Keychain Access থেকে এন্ট্রি ডিলিট করুন।

Windows সার্টিফিকেট স্টোর

Command Prompt প্রশাসক হিসেবে খুলুন (Win + R চাপুন, cmd টাইপ করুন, তারপর Ctrl + Shift + Enter চাপুন) এবং সার্টিফিকেটটি Trusted Root Certification Authorities স্টোরে যুক্ত করুন:

certutil -addstore -f "Root" certificate.crt

বিকল্পভাবে, সার্টিফিকেট ফাইলে ডাবল-ক্লিক করুন, Install Certificate বেছে নিন, Local Machine নির্বাচন করুন, তারপর Place all certificates in the following store, এবং Trusted Root Certification Authorities-এ ব্রাউজ করুন। এটি পরে অপসারণ করতে, certmgr.msc খুলুন এবং সেই স্টোর থেকে এন্ট্রি ডিলিট করুন।

Linux ca-certificates

Debian এবং Ubuntu-তে, সার্টিফিকেটটি লোকাল অ্যাংকর ডিরেক্টরিতে কপি করুন এবং বান্ডলটি পুনর্নির্মাণ করুন। ফাইলটির .crt এক্সটেনশন থাকতেই হবে অথবা আপডেট টুলটি এটি উপেক্ষা করবে:

sudo cp certificate.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

RHEL, CentOS, AlmaLinux, Rocky, এবং Fedora-তে, পাথগুলো ভিন্ন:

sudo cp certificate.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

Firefox-এর ব্যতিক্রম

Firefox অপারেটিং সিস্টেমের বদলে তার নিজস্ব ট্রাস্ট স্টোর রাখে। Windows এবং macOS-এ এটি ডিফল্টভাবে OS স্টোরে যুক্ত করা রুটগুলোও পড়ে, তাই উপরের পদক্ষেপগুলো সাধারণত এটি কভার করে। Linux-এ এটি করে না, তাই সার্টিফিকেটটি সরাসরি Firefox-এ ইম্পোর্ট করতে হবে: Settings খুলুন, তারপর Privacy & Security, Certificates-এ স্ক্রল করুন, View Certificates ক্লিক করুন, Authorities ট্যাব খুলুন, এবং Import ব্যবহার করুন।

এই কোনো পরিবর্তনের পর ব্রাউজারটি রিস্টার্ট করুন। ব্রাউজারগুলো সার্টিফিকেট সিদ্ধান্ত ক্যাশে রাখে, এবং একটি পুরনো সেশন হলো সঠিক ইম্পোর্টের পরেও সতর্কবার্তাটি অব্যাহত থাকার একটি সাধারণ কারণ।

কখন সেলফ-সাইনড সার্টিফিকেট ব্যবহার করবেন না

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

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