SSL এরর: এগুলো কী এবং কীভাবে ঠিক করবেন

একটি এসএসএল এরর (SSL error) হলো তখনকার অবস্থা, যখন ব্রাউজার কোনো ওয়েবসাইটের সাথে একটি বিশ্বাসযোগ্য এনক্রিপ্টেড সংযোগ খুলতে পারে না। আপনি যে পেজটি চেয়েছিলেন, তার পরিবর্তে আপনি একটি সতর্কতা স্ক্রিন এবং ছোট বড় হাতের অক্ষরে একটি সংক্ষিপ্ত কোড দেখতে পান, যেমন NET::ERR_CERT_AUTHORITY_INVALID বা SSL_ERROR_NO_CYPHER_OVERLAP।

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

এসএসএল এরর আসলে কী

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

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

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

সংযোগের কোন ধাপে ব্যর্থতা ঘটেছে

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

1. সংযোগটি কখনো TLS হয়নি। আপনার ব্রাউজার একটি সংযোগ খুলেছিল এবং যা ফিরে এসেছিল তা TLS ছিল না, বা অপর প্রান্ত হ্যান্ডশেক শেষ হওয়ার আগেই সংযোগটি বন্ধ করে দিয়েছে। এখানে কোনো সার্টিফিকেট জড়িত নয়, এবং কোনো সার্টিফিকেট প্রতিস্থাপনের প্রয়োজন নেই।
2. হ্যান্ডশেক আলোচনার সময় ব্যর্থ হয়েছে। দুই পক্ষই TLS বলেছিল কিন্তু কোনো প্রোটোকল সংস্করণ, সাইফার স্যুট, বা কোন সাইটের অনুরোধ করা হচ্ছে তা নিয়ে একমত হতে পারেনি। হ্যান্ডশেক সার্টিফিকেট যাচাইয়ের আগেই থেমে যায়, এবং প্রায়ই এটি পাঠানোর আগেই থেমে যায়।
3. সার্টিফিকেট গ্রহণ করা হয়েছিল এবং প্রত্যাখ্যাত হয়েছিল। মানুষ যখন “এসএসএল এরর” বলে, তখন তারা সাধারণত এই গ্রুপটি বোঝায়। মেয়াদ শেষ হওয়া, হোস্টনেম কভারেজ, বিশ্বাসের শৃঙ্খল, বাতিলকরণ এবং সিগনেচারের শক্তি – এসবই এই ধাপে থাকে।
4. হ্যান্ডশেক সফল হয়েছিল এবং পরে কিছু একটা ব্যর্থ হয়েছে। এনক্রিপ্টেড সংযোগ সঠিকভাবে স্থাপিত হয়েছিল, তারপর একটি পরের লেয়ার ভেঙে গেছে। এই পর্যায়ে সার্টিফিকেট নিশ্চিতভাবে সঠিক, তাই এটি প্রতিস্থাপন করলে কিছুই পরিবর্তন হয় না।

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

আপনার এরর খুঁজে নিন

সতর্কতা বার্তার নিচে ছাপা কোডটি পড়ুন। Chrome এবং Edge-এ এটি “Your connection is not private”-এর নিচে ছোট বড় হাতের অক্ষরে থাকে। Firefox-এ আপনার সতর্কতা পেজের অ্যাডভান্সড ডিটেইলস খুলতে হতে পারে। তারপর নিচে এটি খুঁজুন।

ধাপ ১: সংযোগ কখনো TLS হয়নি

• SSL_ERROR_RX_RECORD_TOO_LONG Firefox-এ এই এরর মানে হলো সার্ভার HTTPS অনুরোধের উত্তরে এমন কিছু দিয়েছে যা TLS নয়, প্রায় সবসময় পোর্ট 443-এ পরিবেশিত সরল HTTP। এটি একটি সার্ভার কনফিগারেশন সমস্যা।
• PR_END_OF_FILE_ERROR Firefox-এ এই এরর মানে হলো হ্যান্ডশেক সম্পূর্ণ হওয়ার আগে অপর প্রান্ত সংযোগটি বন্ধ করে দিয়েছে। এর কারণ প্রায়ই আপনার এবং সার্ভারের মধ্যবর্তী কোনো কিছু, সার্ভার বা আপনার শেষ প্রান্ত নয়।

ধাপ ২: হ্যান্ডশেক আলোচনার সময় ব্যর্থ হয়েছে

• ERR_SSL_PROTOCOL_ERROR হলো Chrome-এর একটি সাধারণ কোড, যা এমন একটি হ্যান্ডশেকের জন্য দেখায় যা কোনো নির্দিষ্ট কারণ চিহ্নিত করতে না পেরে ব্যর্থ হয়েছে। আপনার কোড এটি হলে এখান থেকেই শুরু করুন, কারণ প্রথম কাজ হলো এটিকে সংকীর্ণ করা।
• SSL_ERROR_NO_CYPHER_OVERLAP হলো Firefox-এর সমতুল্য, এবং সমানভাবে বিস্তৃত: সার্ভার যে কোনো মারাত্মক হ্যান্ডশেক ব্যর্থতার কথা জানায়, তার জন্যই এটি দেখা যায়, সার্ভারের আসল কারণ যাই হোক না কেন।
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH হলো একই ধরনের ব্যর্থতার জন্য Chrome-এর কোড, যা আলোচনার একটি সংক্ষিপ্ত এবং নির্দিষ্ট শর্তের তালিকার জন্য উত্থিত হয়।
• ERR_SSL_UNRECOGNIZED_NAME_ALERT মানে হলো সার্ভার উদ্দেশ্যমূলকভাবে হ্যান্ডশেক শেষ করে দিয়েছে, কারণ অনুরোধ করা হোস্টনেম তার উপর কনফিগার করা কোনো সাইটের সাথে মিলছে না। কোনো সার্টিফিকেট পাঠানো হয় না, তাই সার্টিফিকেট এর দোষ নয়।
• ERR_BAD_SSL_CLIENT_AUTH_CERT এখানে থাকা অন্য সব এররের বিপরীত দিকে চলে: সাইট আপনার ব্রাউজারের কাছে একটি সার্টিফিকেট চেয়েছিল এবং যা পেয়েছে তা প্রত্যাখ্যান করেছে, বা কিছুই পায়নি। এটি সত্যিই আপনার মেশিনেই সমাধান করা হয়।
• Cloudflare error 525 হলো যাত্রার একটি ভিন্ন অংশে হ্যান্ডশেক ব্যর্থতা: Cloudflare এবং এর পেছনের অরিজিন সার্ভারের মধ্যে, আপনার ব্রাউজার এবং Cloudflare-এর মধ্যে নয়। দর্শকরা এর ওপর কিছু করতে পারে না।

ধাপ ৩: সার্টিফিকেট গ্রহণ করা হয়েছিল এবং প্রত্যাখ্যাত হয়েছিল

Your connection is not private হলো Chrome-এর এই সম্পূর্ণ গ্রুপের জন্য সতর্কতা স্ক্রিন, এর নিজস্ব কোনো কারণ নয়, তাই যদি এটিই আপনার কাছে থাকা সবটুকু হয়, তবে প্রথমে তার নিচের কোডটি পড়ুন।

বিশ্বাসের শৃঙ্খল তৈরি করা যায়নি। ব্রাউজার সাইটের সার্টিফিকেটটিকে তার বিশ্বাস করা কোনো রুটের সাথে সংযুক্ত করতে পারেনি, সাধারণত কারণ সার্ভার তার নিজস্ব সার্টিফিকেট পাঠায় এবং এর উপরের ইন্টারমিডিয়েট সার্টিফিকেট বাদ দেয়।

• NET::ERR_CERT_AUTHORITY_INVALID Chrome এবং Edge-এ।
• SEC_ERROR_UNKNOWN_ISSUER Firefox-এ, একই অবস্থা ভিন্ন নামে।
• একটি মেয়াদ শেষ হওয়া ইন্টারমিডিয়েট সার্টিফিকেট, যেখানে শৃঙ্খল বিদ্যমান কিন্তু আপনার উপরের একটি লিঙ্কের মেয়াদ শেষ হয়ে গেছে।
• MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, যেখানে কোনো শৃঙ্খল নেই কারণ সার্টিফিকেটটি নিজেই স্বাক্ষরিত।

তারিখ বা নাম মিলছে না। সার্টিফিকেটটি বিশ্বাসযোগ্য কিন্তু এই মুহূর্তে বা এই হোস্টনেমের জন্য প্রযোজ্য নয়।

• NET::ERR_CERT_DATE_INVALID, যেখানে সার্টিফিকেটের মেয়াদ শেষ হয়ে গেছে বা এখনো বৈধ হয়নি। এটা জেনে রাখা ভালো যে আপনার নিজের ডিভাইসের ভুল ঘড়িও এটি তৈরি করতে পারে।
• NET::ERR_CERT_COMMON_NAME_INVALID, যেখানে হোস্টনেমটি সার্টিফিকেটে তালিকাভুক্ত নয়।
• DLG_FLAGS_SEC_CERT_CN_INVALID, একই হোস্টনেম সমস্যা যা পুরনো Windows ওয়েব স্ট্যাক-এ তৈরি সফটওয়্যার দ্বারা রিপোর্ট করা হয়, মূলত Edge-এর Internet Explorer মোড এবং লাইন-অব-বিজনেস অ্যাপ্লিকেশনে।

সার্টিফিকেট বিশ্বাসযোগ্য ও বর্তমান, কিন্তু অন্য কোনো কারণে অনুমোদিত নয়।

• NET::ERR_CERT_REVOKED, যেখানে সার্টিফিকেট অথরিটি এটি মেয়াদ শেষ হওয়ার তারিখের আগেই বাতিল করেছে।
• NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED, যেখানে সার্টিফিকেটটি ইস্যু হওয়ার পর্যাপ্ত পাবলিক প্রমাণ নিয়ে আসেনি।
• NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM, যেখানে শৃঙ্খলের কোনো অংশ SHA-1 দিয়ে স্বাক্ষরিত। বর্তমান Chrome একই সার্টিফিকেটকে একটি ভিন্ন কোডের অধীনে রিপোর্ট করতে পারে, কিন্তু অবস্থা এবং সমাধান অপরিবর্তিত।
• SEC_ERROR_REUSED_ISSUER_AND_SERIAL, সংযোগে ত্রুটির বদলে Firefox-এর নিজস্ব সার্টিফিকেট স্টোরের মধ্যে একটি সংঘর্ষ।
• NET::ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN, যা ব্রাউজারে অন্তর্নির্মিত অত্যন্ত ছোট একটি ডোমেইনের সেটে প্রযোজ্য, তাই একটি সাধারণ ওয়েবসাইট এটি তৈরি করতে পারে না।

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

• ERR_SSL_SERVER_CERT_BAD_FORMAT, যেখানে ব্রাউজার সার্ভারের পাঠানো সার্টিফিকেট ডিকোড করতে পারেনি।
• একটি মোডুলাস মিসম্যাচ, যেখানে ইনস্টল করা সার্টিফিকেট ইনস্টল করা প্রাইভেট কী-এর সাথে সংশ্লিষ্ট নয়।

ধাপ ৪: হ্যান্ডশেক সফল হয়েছিল এবং পরে কিছু একটা ব্যর্থ হয়েছে

এগুলো অভ্যাসগতভাবে এসএসএল এরর হিসেবে ফাইল করা হয়। প্রতিটি ক্ষেত্রেই এনক্রিপ্টেড সংযোগ আগে থেকেই কাজ করছিল, তাই সার্টিফিকেটটি সফলভাবে যাচাই করা হয়েছে এবং এটি পুনরায় ইস্যু করলে কোনো সাহায্য হবে না।

• ERR_SSL_BAD_RECORD_MAC_ALERT মানে হলো সার্ভার এমন এনক্রিপ্টেড ডেটা পেয়েছে যা এটি যাচাই করতে পারেনি, যা হ্যান্ডশেকের পরে সেশন কী-এর অধীনে ঘটে। পথের মধ্যে কিছু একটা ট্রাফিক দুর্নীতিগ্রস্ত করছে বা পুনরায় লিখছে।
• ERR_QUIC_PROTOCOL_ERROR হলো QUIC-এর একটি ব্যর্থতা, যা HTTP/3-এর নিচের ট্রান্সপোর্ট। এটি সার্টিফিকেটের সমস্যা নয়, এবং সাধারণ কারণ হলো একটি ফায়ারওয়াল বা VPN যা UDP ফিল্টার করছে।
• ERR_SPDY_PROTOCOL_ERROR হলো HTTP/2 লেয়ারে একটি ব্যর্থতা, যা একটি সম্পূর্ণ TLS হ্যান্ডশেকের উপরে অবস্থিত।
• Mixed content হলো এখানে বিসদৃশ একটি ক্ষেত্র: পেজটি HTTPS-এর মাধ্যমে খুবই ভালোভাবে লোড হয়েছিল, তারপর সাদাসিধা HTTP-এর মাধ্যমে একটি রিসোর্সের অনুরোধ করেছিল। এটি কোনো এরর পেজ তৈরি করে না, শুধু একটি ডাউনগ্রেড করা প্যাডলক এবং অনুপস্থিত স্ক্রিপ্ট বা ইমেজ দেখায়।

ধাপের বদলে ডিভাইসের নামে চিহ্নিত এরর

দুটি প্ল্যাটফর্মের নিজস্ব পর্যাপ্ত অস্বাভাবিকতা রয়েছে, যা আলাদাভাবে বিবেচনা করার মতো, কারণ একই অন্তর্নিহিত অবস্থা তাদের ওপর ভিন্নভাবে আচরণ করে।

• iPhone এবং iPad-এ এসএসএল এরর, “An SSL error has occurred and a secure connection to the server cannot be made” বার্তাটি সহ। তারিখ এবং সময়ের সেটিং হলো প্রথম চেক করার বিষয়।
• Android-এ এসএসএল সংযোগ এরর, যেখানে Chrome এবং অন্য অ্যাপগুলো ভিন্ন বিশ্বাস স্টোর ব্যবহার করে, এবং একটি অনুপস্থিত ইন্টারমিডিয়েট সার্টিফিকেট ডেস্কটপের চেয়ে বেশি সমস্যা তৈরি করে।

এমন কোড যা এখন আর দেখা যায় না

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

• NET::ERR_CERT_SYMANTEC_LEGACY ২০২৫ সালের এপ্রিলে প্রকাশিত Chrome 136-এ মুছে ফেলা হয়েছে।
• ERR_SSL_VERSION_INTERFERENCE ২০১৯ সালে Chrome 76-এ সরানো হয়েছিল, তবে এটি যে হস্তক্ষেপ বর্ণনা করত তা এখনও ঘটে এবং এখন ভিন্নভাবে প্রকাশিত হয়।
• ERR_SPDY_PROTOCOL_ERROR ২০১৯ সালে Chrome 77-এ ERR_HTTP2_PROTOCOL_ERROR-এ নাম পরিবর্তিত হয়েছিল। এটি যে ব্যর্থতা বর্ণনা করে তা এখনও বর্তমান, যার কারণে এটি উপরে ধাপ চারের অধীনে তালিকাভুক্ত করা হয়েছে।

আপনি যদি সাইটটি ভিজিট করছেন

বেশিরভাগ এসএসএল এরর ওয়েবসাইটের সমাধান করার বিষয়, এবং আপনার নিজের ডিভাইসে যত কাজই করুন, এতে কোনো পরিবর্তন হবে না। এখানে সত্যিকারের ব্যতিক্রমের একটি সংক্ষিপ্ত তালিকা আছে, এবং সাইটটি ভাঙা বলে সিদ্ধান্তে পৌঁছানোর আগে এটি দেখে নেওয়া মূল্যবান।

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

এর কোনোটিতে সাহায্য না হলে, সমস্যাটি সার্ভারে এবং সৎ উত্তর হলো আপনি এটি সমাধান করতে পারবেন না। এটি Cloudflare error 525-এর ক্ষেত্রে সম্পূর্ণভাবে প্রযোজ্য, যেখানে ব্যর্থতা এমন একটি সংযোগে ঘটে যার অংশ আপনার ব্রাউজার নয়।

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

আপনি যদি ওয়েবসাইট চালান

কিছু পরিবর্তন করার আগে সমস্যা নির্ণয় করুন। যে সার্টিফিকেট কখনো সমস্যা ছিল না তা পুনরায় ইনস্টল করা সাধারণ উপায়, যার মাধ্যমে একটি ঘণ্টা একটি বিকেলে রূপান্তরিত হয়।

একটি বাহ্যিক চেক দিয়ে শুরু করুন

আমাদের SSL Checker-এর মাধ্যমে ডোমেইনটি চালান। এটি রিপোর্ট করে সার্ভার আসলে বাহ্যিক বিশ্বে কী পাঠাচ্ছে, যা প্রায়ই কনফিগারেশন ফাইলে যা আছে তার থেকে ভিন্ন। ডিস্কে সম্পূর্ণ দেখা যাওয়া একটি শৃঙ্খল যা ব্রাউজারে অসম্পূর্ণ পৌঁছায়, এটি সবচেয়ে সাধারণ ফলাফল, এবং এটিই NET::ERR_CERT_AUTHORITY_INVALID এবং SEC_ERROR_UNKNOWN_ISSUER দুটির পেছনের কারণ।

আপনি কমান্ড লাইন থেকেও একই বিষয় দেখতে পারেন। এটি সার্ভার প্রদান করা প্রতিটি সার্টিফিকেট প্রিন্ট করে, যে ক্রমে তা প্রদান করা হয়:

openssl s_client -connect example.com:443 -servername example.com -showcerts

এই আউটপুটে সার্টিফিকেট তালিকাটি পড়ুন, নিচের Verify return code লাইনটি নয়। সেই লাইন যা মনে হয় তার তুলনায় অনেক কম তথ্যবহুল: এটি শুধুমাত্র OpenSSL-এর শৃঙ্খলের রায় রিপোর্ট করে, আপনি স্পষ্টভাবে চেক না চাইলে এটি হোস্টনেম উপেক্ষা করে, এবং যখন হ্যান্ডশেক বাতিল করা হয়েছিল বলে সার্ভার কোনো সার্টিফিকেটই পাঠায়নি, তখনও এটি 0 (ok) প্রিন্ট করে। যদি আউটপুটে subject= লাইন দেখানোর বদলে no peer certificate available লেখা থাকে, তবে কিছুই যাচাই করা হয়নি এবং ব্যর্থতা আগেই ঘটেছে।

তারিখ এবং হোস্টনেম চেক করুন

এই দুটি সার্টিফিকেট প্রত্যাখ্যানের একটি বড় অংশের কারণ। সার্ভার যে সার্টিফিকেট পরিবেশন করছে তার বৈধতার সময়সীমা পড়তে:

openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject

ব্রাউজারগুলো হোস্টনেমকে subjectAltName এক্সটেনশনের বিপরীতে মেলায় এবং Common Name সম্পূর্ণভাবে উপেক্ষা করে, তাই এটিই একটি স্থানীয় সার্টিফিকেট ফাইলে পরিদর্শন করার ক্ষেত্র:

openssl x509 -noout -text -in certificate.crt | grep -A1 "Subject Alternative Name"

OpenSSL-কে ব্রাউজার যে হোস্টনেম চেক প্রয়োগ করে তা প্রয়োগ করাতে, একটি পরিষ্কার ফলাফল এটি কভার করে ধরে নেওয়ার বদলে ফ্ল্যাগ যুক্ত করুন:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com

macOS-এ এই কমান্ডগুলোর প্রতি মনোযোগ প্রয়োজন। macOS-এর সাথে আসা openssl আসলে LibreSSL, এবং এটি -verify_hostname সরাসরি প্রত্যাখ্যান করে এবং কিছু সত্যিই ভাঙা শৃঙ্খলে একটি স্বাস্থ্যকর ফলাফল রিপোর্ট করে। Homebrew-এর মাধ্যমে OpenSSL ইনস্টল করুন, তারপর openssl version আবার চালিয়ে নিশ্চিত করুন আপনি আসলে কোন বাইনারিটি কল করছেন। এখনও LibreSSL রিপোর্ট করলে, আপনার PATH প্রথমে সিস্টেম কপি খুঁজে পাচ্ছে, তাই /opt/homebrew/bin/openssl-কে এর সম্পূর্ণ পাথ দিয়ে কল করুন।

তারপর সংশোধন করুন এবং যাচাই করুন

কী পরিবর্তন করতে হবে তা ধাপের ওপর নির্ভর করে, এবং উপরে লিঙ্ক করা পৃথক গাইডগুলোতে প্ল্যাটফর্ম-নির্দিষ্ট পদক্ষেপ থাকে। তিনটি সমাধান বেশিরভাগ ক্ষেত্র কভার করে:

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

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

এসএসএল এরর প্রতিরোধের উপায়

কর্মক্ষম ওয়েবসাইটে প্রায় প্রতিটি এসএসএল এরর তিনটি বিষয়ের একটি থেকে আসে: মেয়াদ শেষ হওয়া একটি সার্টিফিকেট, একটি শৃঙ্খল যা কখনো সম্পূর্ণ ছিল না, বা একটি কনফিগারেশন যা বিচ্যুত হয়েছে। এই তিনটিই প্রতিরোধযোগ্য।

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

প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী