TLS/SSL হ্যান্ডশেক ব্যর্থতা

আপনি Apigee Edge-এর ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন .info- তে যান।

লক্ষণ

যখন কোনো ক্লায়েন্ট এবং সার্ভার TLS/SSL প্রোটোকল ব্যবহার করে যোগাযোগ স্থাপন করতে পারে না, তখন একটি TLS/SSL হ্যান্ডশেক ব্যর্থতা ঘটে। Apigee Edge-এ এই ত্রুটি ঘটলে, ক্লায়েন্ট অ্যাপ্লিকেশনটি 'Service Unavailable' বার্তা সহ একটি HTTP স্ট্যাটাস 503 পায়। TLS/SSL হ্যান্ডশেক ব্যর্থতা ঘটে এমন যেকোনো API কলের পরে আপনি এই ত্রুটিটি দেখতে পাবেন।

ত্রুটির বার্তা

HTTP/1.1 503 Service Unavailable

TLS/SSL হ্যান্ডশেক ব্যর্থ হলে আপনি এই ত্রুটি বার্তাটিও দেখতে পারেন:

Received fatal alert: handshake_failure

সম্ভাব্য কারণসমূহ

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

1. প্রোটোকলের কোন সংস্করণটি ব্যবহার করা হবে, সে বিষয়ে একমত হোন।
2. ব্যবহৃতব্য ক্রিপ্টোগ্রাফিক অ্যালগরিদমটি নির্বাচন করুন।
3. ডিজিটাল সার্টিফিকেট বিনিময় ও যাচাই করার মাধ্যমে একে অপরকে প্রমাণীকরণ করুন।

যদি TLS/SSL হ্যান্ডশেক সফল হয়, তাহলে TLS/SSL ক্লায়েন্ট এবং সার্ভার একে অপরের কাছে নিরাপদে ডেটা আদান-প্রদান করে। অন্যথায়, যদি TLS/SSL হ্যান্ডশেক ব্যর্থ হয়, তাহলে সংযোগটি বিচ্ছিন্ন হয়ে যায় এবং ক্লায়েন্ট একটি 503 Service Unavailable ত্রুটি বার্তা পায়।

TLS/SSL হ্যান্ডশেক ব্যর্থতার সম্ভাব্য কারণগুলো হলো:

প্রোটোকল অমিল

ইনকামিং (নর্থবাউন্ড) বা আউটগোয়িং (সাউথবাউন্ড) সংযোগের ক্ষেত্রে, ক্লায়েন্ট কর্তৃক ব্যবহৃত প্রোটোকলটি সার্ভার দ্বারা সমর্থিত না হলে একটি TLS/SSL হ্যান্ডশেক ব্যর্থতা ঘটে। আরও দেখুন নর্থবাউন্ড এবং সাউথবাউন্ড সংযোগ বোঝা ।

রোগ নির্ণয়

1. ত্রুটিটি উত্তরমুখী নাকি দক্ষিণমুখী সংযোগস্থলে ঘটেছে তা নির্ণয় করুন। এই নির্ণয় করার বিষয়ে আরও নির্দেশনার জন্য, ‘সমস্যার উৎস নির্ণয় ’ দেখুন।
2. আরও তথ্য সংগ্রহ করতে tcpdump ইউটিলিটিটি চালান:
   • আপনি যদি একজন প্রাইভেট ক্লাউড ব্যবহারকারী হন, তাহলে আপনি প্রাসঙ্গিক ক্লায়েন্ট বা সার্ভার থেকে tcpdump ডেটা সংগ্রহ করতে পারেন। একটি ক্লায়েন্ট হতে পারে ক্লায়েন্ট অ্যাপ (ইনকামিং বা নর্থবাউন্ড সংযোগের জন্য) অথবা মেসেজ প্রসেসর (আউটগোয়িং বা সাউথবাউন্ড সংযোগের জন্য)। ধাপ ১-এ আপনার নির্ধারণের উপর ভিত্তি করে একটি সার্ভার হতে পারে এজ রাউটার (ইনকামিং বা নর্থবাউন্ড সংযোগের জন্য) অথবা ব্যাকএন্ড সার্ভার (আউটগোয়িং বা সাউথবাউন্ড সংযোগের জন্য)।
   • আপনি যদি একজন পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে আপনি tcpdump ডেটা শুধুমাত্র ক্লায়েন্ট অ্যাপে (ইনকামিং বা নর্থবাউন্ড সংযোগের জন্য) অথবা ব্যাকএন্ড সার্ভারে (আউটগোয়িং বা সাউথবাউন্ড সংযোগের জন্য) সংগ্রহ করতে পারবেন, কারণ আপনার এজ রাউটার বা মেসেজ প্রসেসরে অ্যাক্সেস নেই।

   tcpdump -i any -s 0 host IP address -w File name
   

   tcpdump কমান্ড ব্যবহারের বিষয়ে আরও তথ্যের জন্য tcpdump ডেটা দেখুন।
3. Wireshark টুল বা অনুরূপ কোনো টুল ব্যবহার করে tcpdump ডেটা বিশ্লেষণ করুন।
4. এখানে Wireshark ব্যবহার করে tcpdump- এর একটি নমুনা বিশ্লেষণ দেওয়া হলো:
   • এই উদাহরণে, মেসেজ প্রসেসর এবং ব্যাকএন্ড সার্ভারের (আউটগোয়িং বা সাউথবাউন্ড কানেকশন) মধ্যে TLS/SSL হ্যান্ডশেক ব্যর্থতা ঘটেছে।
   • নীচের tcpdump আউটপুটের ৪ নম্বর মেসেজটি থেকে দেখা যাচ্ছে যে, মেসেজ প্রসেসর (সোর্স) ব্যাকএন্ড সার্ভারে (ডেস্টিনেশন) একটি "ক্লায়েন্ট হ্যালো" মেসেজ পাঠিয়েছে।
     

     

   • আপনি যদি Client Hello বার্তাটি নির্বাচন করেন, তাহলে দেখা যায় যে মেসেজ প্রসেসরটি TLSv1.2 প্রোটোকল ব্যবহার করছে, যেমনটি নিচে দেখানো হয়েছে:

     

   • বার্তা #৫ থেকে বোঝা যায় যে, ব্যাকএন্ড সার্ভার মেসেজ প্রসেসরের পাঠানো "ক্লায়েন্ট হ্যালো" বার্তাটি স্বীকার করেছে।
   • ব্যাকএন্ড সার্ভার অবিলম্বে মেসেজ প্রসেসরের কাছে একটি 'Fatal Alert : Close Notify' (মেসেজ #৬) পাঠায়। এর অর্থ হলো TLS/SSL হ্যান্ডশেক ব্যর্থ হয়েছে এবং সংযোগটি বন্ধ হয়ে যাবে।

   • বার্তা #৬ আরও খতিয়ে দেখলে দেখা যায় যে, TLS/SSL হ্যান্ডশেক ব্যর্থ হওয়ার কারণ হলো ব্যাকএন্ড সার্ভারটি শুধুমাত্র TLSv1.0 প্রোটোকল সমর্থন করে, যা নিচে দেখানো হলো:

     

   • মেসেজ প্রসেসর এবং ব্যাকএন্ড সার্ভার দ্বারা ব্যবহৃত প্রোটোকলের মধ্যে অমিল থাকার কারণে, ব্যাকএন্ড সার্ভারটি এই বার্তাটি পাঠিয়েছে: মারাত্মক সতর্কতা বার্তা: বিজ্ঞপ্তি বন্ধ করুন ।

সমাধান

মেসেজ প্রসেসরটি জাভা ৮-এ চলে এবং ডিফল্টরূপে TLSv1.2 প্রোটোকল ব্যবহার করে। যদি ব্যাকএন্ড সার্ভারটি TLSv1.2 প্রোটোকল সমর্থন না করে, তাহলে এই সমস্যাটি সমাধান করার জন্য আপনি নিম্নলিখিত পদক্ষেপগুলির মধ্যে একটি নিতে পারেন:

1. আপনার ব্যাকএন্ড সার্ভারকে TLSv1.2 প্রোটোকল সমর্থন করার জন্য আপগ্রেড করুন। এটি একটি প্রস্তাবিত সমাধান, কারণ TLSv1.2 প্রোটোকলটি অধিক সুরক্ষিত।
2. যদি কোনো কারণে আপনি অবিলম্বে আপনার ব্যাকএন্ড সার্ভার আপগ্রেড করতে না পারেন, তাহলে নিম্নলিখিত ধাপগুলো অনুসরণ করে মেসেজ প্রসেসরকে ব্যাকএন্ড সার্ভারের সাথে যোগাযোগের জন্য TLSv1.0 প্রোটোকল ব্যবহার করতে বাধ্য করতে পারেন:
   1. যদি আপনি প্রক্সির TargetEndpoint সংজ্ঞায় কোনো টার্গেট সার্ভার নির্দিষ্ট না করে থাকেন, তাহলে নিচে দেখানো অনুযায়ী Protocol এলিমেন্টটিকে TLSv1.0 এ সেট করুন:

      <TargetEndpoint name="default">
       …
       <HTTPTargetConnection>
         <SSLInfo>
             <Enabled>true</Enabled>
             <Protocols>
                 <Protocol>TLSv1.0</Protocol>
             </Protocols>
         </SSLInfo>
         <URL>https://myservice.com</URL>
       </HTTPTargetConnection>
       …
      </TargetEndpoint>

   2. আপনি যদি আপনার প্রক্সির জন্য একটি টার্গেট সার্ভার কনফিগার করে থাকেন, তাহলে নির্দিষ্ট টার্গেট সার্ভার কনফিগারেশনে প্রোটোকলটি TLSv1.0-এ সেট করতে এই ম্যানেজমেন্ট API-টি ব্যবহার করুন।

সাইফার অমিল

Apigee Edge-এ ইনকামিং (নর্থবাউন্ড) বা আউটগোয়িং (সাউথবাউন্ড) সংযোগের ক্ষেত্রে, ক্লায়েন্ট কর্তৃক ব্যবহৃত সাইফার স্যুট অ্যালগরিদমটি সার্ভার দ্বারা সমর্থিত না হলে আপনি একটি TLS/SSL হ্যান্ডশেক ব্যর্থতা দেখতে পারেন। আরও দেখুন নর্থবাউন্ড এবং সাউথবাউন্ড সংযোগ বোঝা ।

রোগ নির্ণয়

1. ত্রুটিটি উত্তরমুখী নাকি দক্ষিণমুখী সংযোগস্থলে ঘটেছে তা নির্ণয় করুন। এই নির্ণয় করার বিষয়ে আরও নির্দেশনার জন্য, ‘সমস্যার উৎস নির্ণয় ’ দেখুন।
2. আরও তথ্য সংগ্রহ করতে tcpdump ইউটিলিটিটি চালান:
   • আপনি যদি একজন প্রাইভেট ক্লাউড ব্যবহারকারী হন, তাহলে আপনি প্রাসঙ্গিক ক্লায়েন্ট বা সার্ভার থেকে tcpdump ডেটা সংগ্রহ করতে পারেন। একটি ক্লায়েন্ট হতে পারে ক্লায়েন্ট অ্যাপ (ইনকামিং বা নর্থবাউন্ড সংযোগের জন্য) অথবা মেসেজ প্রসেসর (আউটগোয়িং বা সাউথবাউন্ড সংযোগের জন্য)। ধাপ ১-এ আপনার নির্ধারণের উপর ভিত্তি করে একটি সার্ভার হতে পারে এজ রাউটার (ইনকামিং বা নর্থবাউন্ড সংযোগের জন্য) অথবা ব্যাকএন্ড সার্ভার (আউটগোয়িং বা সাউথবাউন্ড সংযোগের জন্য)।
   • আপনি যদি একজন পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে আপনি tcpdump ডেটা শুধুমাত্র ক্লায়েন্ট অ্যাপে (ইনকামিং বা নর্থবাউন্ড সংযোগের জন্য) অথবা ব্যাকএন্ড সার্ভারে (আউটগোয়িং বা সাউথবাউন্ড সংযোগের জন্য) সংগ্রহ করতে পারবেন, কারণ আপনার এজ রাউটার বা মেসেজ প্রসেসরে অ্যাক্সেস নেই।

   tcpdump -i any -s 0 host IP address -w File name
   

   tcpdump কমান্ড ব্যবহারের বিষয়ে আরও তথ্যের জন্য tcpdump ডেটা দেখুন।
3. Wireshark টুল অথবা আপনার পরিচিত অন্য কোনো টুল ব্যবহার করে tcpdump ডেটা বিশ্লেষণ করুন।
4. ওয়্যারশার্ক ব্যবহার করে tcpdump আউটপুটের একটি নমুনা বিশ্লেষণ নিচে দেওয়া হলো:
   • এই উদাহরণে, ক্লায়েন্ট অ্যাপ্লিকেশন এবং এজ রাউটারের (নর্থবাউন্ড কানেকশন) মধ্যে TLS/SSL হ্যান্ডশেক ব্যর্থতা ঘটেছে। এজ রাউটারে tcpdump আউটপুট সংগ্রহ করা হয়েছিল।

   • নীচের tcpdump আউটপুটের ৪ নম্বর বার্তাটি থেকে বোঝা যায় যে, ক্লায়েন্ট অ্যাপ্লিকেশন (সোর্স) এজ রাউটারকে (গন্তব্য) একটি "ক্লায়েন্ট হ্যালো" বার্তা পাঠিয়েছে।

     

   • ক্লায়েন্ট হ্যালো বার্তাটি নির্বাচন করলে বোঝা যায় যে ক্লায়েন্ট অ্যাপ্লিকেশনটি TLSv1.2 প্রোটোকল ব্যবহার করছে।

     

   • বার্তা #৫ থেকে বোঝা যায় যে, এজ রাউটারটি ক্লায়েন্ট অ্যাপ্লিকেশন থেকে আসা "ক্লায়েন্ট হ্যালো" বার্তাটি স্বীকার করেছে।
   • এজ রাউটারটি অবিলম্বে ক্লায়েন্ট অ্যাপ্লিকেশনকে একটি মারাত্মক সতর্কতা: হ্যান্ডশেক ব্যর্থতা (বার্তা #৬) পাঠায়। এর অর্থ হলো TLS/SSL হ্যান্ডশেক ব্যর্থ হয়েছে এবং সংযোগটি বন্ধ করে দেওয়া হবে।
   • বার্তা #৬ আরও খতিয়ে দেখলে নিম্নলিখিত তথ্য পাওয়া যায়:
     • এজ রাউটারটি TLSv1.2 প্রোটোকল সমর্থন করে। এর মানে হলো, ক্লায়েন্ট অ্যাপ্লিকেশন এবং এজ রাউটারের মধ্যে প্রোটোকলটি মিলে যায়।

     • তবে, নিচের স্ক্রিনশটে দেখানো অনুযায়ী এজ রাউটারটি এখনও ক্লায়েন্ট অ্যাপ্লিকেশনে 'Fatal Alert: Handshake Failure' বার্তাটি পাঠায়:

       

   • ত্রুটিটি নিম্নলিখিত সমস্যাগুলোর কোনো একটির কারণে হতে পারে:
     • ক্লায়েন্ট অ্যাপ্লিকেশনটি এজ রাউটার দ্বারা সমর্থিত সাইফার স্যুট অ্যালগরিদমগুলো ব্যবহার করছে না।
     • এজ রাউটারটি SNI-সক্ষম, কিন্তু ক্লায়েন্ট অ্যাপ্লিকেশনটি সার্ভারের নাম পাঠাচ্ছে না।
   • tcpdump আউটপুটের ৪ নম্বর বার্তায় ক্লায়েন্ট অ্যাপ্লিকেশন দ্বারা সমর্থিত সাইফার স্যুট অ্যালগরিদমগুলোর তালিকা দেওয়া থাকে, যা নিচে দেখানো হলো:

     

   • এজ রাউটার দ্বারা সমর্থিত সাইফার স্যুট অ্যালগরিদমগুলির তালিকা /opt/nginx/conf.d/0-default.conf ফাইলে দেওয়া আছে। এই উদাহরণে, এজ রাউটারটি শুধুমাত্র হাই এনক্রিপশন সাইফার স্যুট অ্যালগরিদম সমর্থন করে।
   • ক্লায়েন্ট অ্যাপ্লিকেশনটি হাই এনক্রিপশন সাইফার স্যুটের কোনো অ্যালগরিদম ব্যবহার করে না। এই অমিলের কারণেই TLS/SSL হ্যান্ডশেক ব্যর্থ হচ্ছে।
   • যেহেতু এজ রাউটারটি SNI-সক্ষম, তাই tcpdump আউটপুটের ৪ নম্বর মেসেজ পর্যন্ত স্ক্রল করে নিচে যান এবং নিশ্চিত করুন যে ক্লায়েন্ট অ্যাপ্লিকেশনটি সার্ভারের নাম সঠিকভাবে পাঠাচ্ছে, যেমনটি নিচের চিত্রে দেখানো হয়েছে:
     
     
     
   • যদি এই নামটি বৈধ হয়, তাহলে আপনি অনুমান করতে পারেন যে TLS/SSL হ্যান্ডশেক ব্যর্থ হয়েছে, কারণ ক্লায়েন্ট অ্যাপ্লিকেশন দ্বারা ব্যবহৃত সাইফার স্যুট অ্যালগরিদমগুলো এজ রাউটার দ্বারা সমর্থিত নয়।

সমাধান

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

ভুল সার্টিফিকেট

Apigee Edge-এর ইনকামিং (নর্থবাউন্ড) বা আউটগোয়িং (সাউথবাউন্ড) কানেকশনে, কীস্টোর/ট্রাস্টস্টোরে ভুল সার্টিফিকেট থাকলে একটি TLS/SSL হ্যান্ডশেক ফেইলর ঘটে। আরও দেখুন নর্থবাউন্ড এবং সাউথবাউন্ড কানেকশন বোঝা ।

যদি সমস্যাটি উত্তরমুখী হয়, তাহলে অন্তর্নিহিত কারণের ওপর নির্ভর করে আপনি বিভিন্ন ধরনের ত্রুটি বার্তা দেখতে পারেন।

নিম্নলিখিত বিভাগগুলিতে উদাহরণস্বরূপ ত্রুটির বার্তা এবং এই সমস্যাটি নির্ণয় ও সমাধান করার পদক্ষেপগুলি তালিকাভুক্ত করা হয়েছে।

ত্রুটির বার্তা

TLS/SSL হ্যান্ডশেক ব্যর্থতার কারণের উপর নির্ভর করে আপনি বিভিন্ন ধরনের এরর মেসেজ দেখতে পারেন। এখানে একটি নমুনা এরর মেসেজ দেওয়া হলো যা আপনি কোনো এপিআই প্রক্সি কল করার সময় দেখতে পারেন:

* SSL certificate problem: Invalid certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html

সম্ভাব্য কারণসমূহ

এই সমস্যার সাধারণ কারণগুলো হলো:

হোস্টনেম অমিল

রোগ নির্ণয়

1. নিম্নলিখিত এজ ম্যানেজমেন্ট এপিআই কল দ্বারা ফেরত আসা URL-এ ব্যবহৃত হোস্টনেমটি লক্ষ্য করুন:

   curl -v https://myorg.domain.com/v1/getinfo

   উদাহরণস্বরূপ:

   curl -v https://api.enterprise.apigee.com/v1/getinfo

2. নির্দিষ্ট কীস্টোরে সংরক্ষিত সার্টিফিকেটে ব্যবহৃত CN-টি সংগ্রহ করুন। সার্টিফিকেটের বিস্তারিত তথ্য পেতে আপনি নিম্নলিখিত এজ ম্যানেজমেন্ট API-গুলো ব্যবহার করতে পারেন:
   1. কীস্টোরে সার্টিফিকেটের নামটি খুঁজুন :
      
      আপনি যদি একজন প্রাইভেট ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নলিখিতভাবে ম্যানেজমেন্ট এপিআই ব্যবহার করুন:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      আপনি যদি একজন পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নলিখিতভাবে ম্যানেজমেন্ট এপিআই ব্যবহার করুন:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. Edge ম্যানেজমেন্ট API ব্যবহার করে কীস্টোরে থাকা সার্টিফিকেটের বিস্তারিত তথ্য জানুন।
      
      আপনি যদি একজন প্রাইভেট ক্লাউড ব্যবহারকারী হন:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      আপনি যদি পাবলিক ক্লাউড ব্যবহারকারী হন:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      নমুনা সনদপত্র::

      "certInfo": [
          {
            "basicConstraints": "CA:FALSE",
            "expiryDate": 1456258950000,
            "isValid": "No",
            "issuer": "SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O=\"GoDaddy.com, Inc.\", L=Scottsdale, ST=Arizona, C=US",
            "publicKey": "RSA Public Key, 2048 bits",
            "serialNumber": "07:bc:a7:39:03:f1:56",
            "sigAlgName": "SHA1withRSA",
            "subject": "CN=something.domain.com, OU=Domain Control Validated, O=something.domain.com",
            "validFrom": 1358287055000,
            "version": 3
          },

      প্রাথমিক সার্টিফিকেটের সাবজেক্ট নেমে CN হিসেবে something.domain.com.

      যেহেতু এপিআই অনুরোধের ইউআরএল-এ ব্যবহৃত হোস্টনেম (উপরের ধাপ #১ দেখুন) এবং সার্টিফিকেটের সাবজেক্ট নেম মেলে না, তাই আপনি TLS/SSL হ্যান্ডশেক ব্যর্থতার সম্মুখীন হন।

সমাধান

এই সমস্যাটি নিম্নলিখিত দুটি উপায়ের যেকোনো একটিতে সমাধান করা যেতে পারে:

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

  "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",

• বিদ্যমান সাবজেক্ট সিএন (CN) সহ একটি সার্টিফিকেট সংগ্রহ করুন (যদি আপনার কাছে আগে থেকে না থাকে), কিন্তু সাবজেক্ট অল্টারনেটিভ নেম হিসেবে your-org . your-domain ব্যবহার করুন, তারপর সম্পূর্ণ সার্টিফিকেট চেইনটি কীস্টোরে আপলোড করুন।

তথ্যসূত্র

কীস্টোর এবং ট্রাস্টস্টোর

অসম্পূর্ণ বা ভুল সার্টিফিকেট চেইন

রোগ নির্ণয়

1. নির্দিষ্ট কীস্টোরে সংরক্ষিত সার্টিফিকেটে ব্যবহৃত CN-টি সংগ্রহ করুন। সার্টিফিকেটের বিস্তারিত তথ্য পেতে আপনি নিম্নলিখিত এজ ম্যানেজমেন্ট API-গুলো ব্যবহার করতে পারেন:
   1. কীস্টোরে সার্টিফিকেটের নামটি খুঁজুন :
      
      আপনি যদি একজন প্রাইভেট ক্লাউড ব্যবহারকারী হন:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

      আপনি যদি পাবলিক ক্লাউড ব্যবহারকারী হন:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. কীস্টোর থেকে সার্টিফিকেটটির বিস্তারিত তথ্য নিন:
      
      আপনি যদি একজন প্রাইভেট ক্লাউড ব্যবহারকারী হন:
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      আপনি যদি পাবলিক ক্লাউড ব্যবহারকারী হন:
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

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

   নমুনা অন্তর্বর্তী এবং মূল সার্টিফিকেট যেখানে ইস্যুকারী এবং বিষয় মেলে না

   
   

সমাধান

1. এমন একটি সার্টিফিকেট সংগ্রহ করুন (যদি আপনার কাছে আগে থেকে না থাকে) যাতে একটি সম্পূর্ণ এবং বৈধ সার্টিফিকেট চেইন অন্তর্ভুক্ত থাকে।
2. সার্টিফিকেট চেইনটি সঠিক ও সম্পূর্ণ কিনা তা যাচাই করতে নিম্নলিখিত openssl কমান্ডটি চালান:

   openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert

3. যাচাইকৃত সার্টিফিকেট চেইনটি কীস্টোরে আপলোড করুন।

সার্ভার বা ক্লায়েন্ট কর্তৃক প্রেরিত মেয়াদোত্তীর্ণ বা অজানা সার্টিফিকেট

যদি সার্ভার/ক্লায়েন্ট নর্থবাউন্ড বা সাউথবাউন্ড সংযোগে কোনো ভুল বা মেয়াদোত্তীর্ণ সার্টিফিকেট পাঠায়, তাহলে অপর প্রান্ত (সার্ভার/ক্লায়েন্ট) সার্টিফিকেটটি প্রত্যাখ্যান করে, যার ফলে TLS/SSL হ্যান্ডশেক ব্যর্থ হয়।

রোগ নির্ণয়

1. ত্রুটিটি উত্তরমুখী নাকি দক্ষিণমুখী সংযোগস্থলে ঘটেছে তা নির্ণয় করুন। এই নির্ণয় করার বিষয়ে আরও নির্দেশনার জন্য, ‘সমস্যার উৎস নির্ণয় ’ দেখুন।
2. আরও তথ্য সংগ্রহ করতে tcpdump ইউটিলিটিটি চালান:
   • আপনি যদি একজন প্রাইভেট ক্লাউড ব্যবহারকারী হন, তাহলে আপনি প্রাসঙ্গিক ক্লায়েন্ট বা সার্ভার থেকে tcpdump ডেটা সংগ্রহ করতে পারেন। একটি ক্লায়েন্ট হতে পারে ক্লায়েন্ট অ্যাপ (ইনকামিং বা নর্থবাউন্ড সংযোগের জন্য) অথবা মেসেজ প্রসেসর (আউটগোয়িং বা সাউথবাউন্ড সংযোগের জন্য)। ধাপ ১-এ আপনার নির্ধারণের উপর ভিত্তি করে একটি সার্ভার হতে পারে এজ রাউটার (ইনকামিং বা নর্থবাউন্ড সংযোগের জন্য) অথবা ব্যাকএন্ড সার্ভার (আউটগোয়িং বা সাউথবাউন্ড সংযোগের জন্য)।
   • আপনি যদি একজন পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে আপনি tcpdump ডেটা শুধুমাত্র ক্লায়েন্ট অ্যাপে (ইনকামিং বা নর্থবাউন্ড সংযোগের জন্য) অথবা ব্যাকএন্ড সার্ভারে (আউটগোয়িং বা সাউথবাউন্ড সংযোগের জন্য) সংগ্রহ করতে পারবেন, কারণ আপনার এজ রাউটার বা মেসেজ প্রসেসরে অ্যাক্সেস নেই।

   tcpdump -i any -s 0 host IP address -w File name
   

   tcpdump কমান্ড ব্যবহারের বিষয়ে আরও তথ্যের জন্য tcpdump ডেটা দেখুন।
3. Wireshark বা অনুরূপ কোনো টুল ব্যবহার করে tcpdump ডেটা বিশ্লেষণ করুন।
4. tcpdump আউটপুট থেকে সেই হোস্ট (ক্লায়েন্ট বা সার্ভার) শনাক্ত করুন, যেটি যাচাইকরণ ধাপে সার্টিফিকেটটি প্রত্যাখ্যান করছে।
5. যদি ডেটা এনক্রিপ্ট করা না থাকে, তবে আপনি tcpdump আউটপুট থেকে অপর প্রান্ত থেকে পাঠানো সার্টিফিকেটটি পুনরুদ্ধার করতে পারেন। এই সার্টিফিকেটটি ট্রাস্টস্টোরে থাকা সার্টিফিকেটের সাথে মেলে কিনা, তা তুলনা করার জন্য এটি সহায়ক হবে।
6. মেসেজ প্রসেসর এবং ব্যাকএন্ড সার্ভারের মধ্যে SSL যোগাযোগের জন্য নমুনা tcpdump টি পর্যালোচনা করুন।

   নমুনা tcpdump সার্টিফিকেট অজানা ত্রুটি দেখাচ্ছে

   
   

   1. মেসেজ প্রসেসর (ক্লায়েন্ট) ৫৯ নম্বর মেসেজে ব্যাকএন্ড সার্ভারকে (সার্ভার) "ক্লায়েন্ট হ্যালো" পাঠায়।
   2. ব্যাকএন্ড সার্ভার ৬১ নম্বর বার্তায় মেসেজ প্রসেসরের কাছে "সার্ভার হ্যালো" পাঠায়।
   3. তারা ব্যবহৃত প্রোটোকল এবং সাইফার স্যুট অ্যালগরিদমগুলো পারস্পরিকভাবে যাচাই করে।
   4. ব্যাকএন্ড সার্ভারটি ৬৮ নম্বর বার্তার মাধ্যমে মেসেজ প্রসেসরের কাছে সার্টিফিকেট এবং সার্ভার হ্যালো ডান বার্তাটি পাঠায়।
   5. মেসেজ প্রসেসর ৭০ নম্বর মেসেজে "বিবরণ: সার্টিফিকেট অজানা" নামক মারাত্মক সতর্কতাটি প্রেরণ করে।
   6. বার্তা #৭০ আরও খতিয়ে দেখলে, নীচে দেখানো সতর্কবার্তাটি ছাড়া অন্য কোনো অতিরিক্ত বিবরণ পাওয়া যায়নি:

      
      

   7. ব্যাকএন্ড সার্ভার কর্তৃক প্রেরিত সার্টিফিকেটটির বিস্তারিত জানতে ৬৮ নং বার্তাটি পর্যালোচনা করুন, যা নিম্নলিখিত গ্রাফিকে দেখানো হয়েছে:

      

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

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs

      2. ট্রাস্টস্টোর থেকে সার্টিফিকেটটির বিস্তারিত তথ্য জেনে নিন:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name

   2. রাউটার (নর্থবাউন্ড) বা মেসেজ প্রসেসর (সাউথবাউন্ড)-এর ট্রাস্টস্টোরে সংরক্ষিত সার্টিফিকেটটি, ক্লায়েন্ট অ্যাপ্লিকেশন (নর্থবাউন্ড) বা টার্গেট সার্ভার (সাউথবাউন্ড)-এর কীস্টোরে সংরক্ষিত সার্টিফিকেটের সাথে, অথবা tcpdump আউটপুট থেকে প্রাপ্ত সার্টিফিকেটের সাথে মেলে কিনা তা পরীক্ষা করুন। যদি অমিল থাকে, তবে সেটিই TLS/SSL হ্যান্ডশেক ব্যর্থতার কারণ।
8. যদি ক্লায়েন্ট অ্যাপ্লিকেশন (নর্থবাউন্ড) বা টার্গেট সার্ভার (সাউথবাউন্ড) দ্বারা সার্টিফিকেটটি অজানা বলে পাওয়া যায়, তাহলে এই পদক্ষেপগুলি অনুসরণ করুন:
   1. নির্দিষ্ট কীস্টোরে সংরক্ষিত সার্টিফিকেটে ব্যবহৃত সম্পূর্ণ সার্টিফিকেট চেইনটি সংগ্রহ করুন। (রাউটারের জন্য ভার্চুয়াল হোস্ট কনফিগারেশন এবং মেসেজ প্রসেসরের জন্য টার্গেট এন্ডপয়েন্ট কনফিগারেশন দেখুন।) সার্টিফিকেটের বিস্তারিত তথ্য পেতে আপনি নিম্নলিখিত API-গুলো ব্যবহার করতে পারেন:
      1. কীস্টোর থেকে সার্টিফিকেটের নামটি নিন:

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      2. কীস্টোর থেকে সার্টিফিকেটটির বিস্তারিত তথ্য নিন:
         

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
         

   2. রাউটার (নর্থবাউন্ড) বা মেসেজ প্রসেসর (সাউথবাউন্ড)-এর কীস্টোরে সংরক্ষিত সার্টিফিকেটটি, ক্লায়েন্ট অ্যাপ্লিকেশন (নর্থবাউন্ড) বা টার্গেট সার্ভার (সাউথবাউন্ড)-এর ট্রাস্টস্টোরে সংরক্ষিত সার্টিফিকেটের সাথে, অথবা tcpdump আউটপুট থেকে প্রাপ্ত সার্টিফিকেটের সাথে মেলে কিনা তা পরীক্ষা করুন। যদি অমিল থাকে, তবে সেটিই SSL হ্যান্ডশেক ব্যর্থতার কারণ।
9. যদি কোনো সার্ভার/ক্লায়েন্ট কর্তৃক প্রেরিত সার্টিফিকেট মেয়াদোত্তীর্ণ বলে প্রমাণিত হয়, তাহলে গ্রহণকারী ক্লায়েন্ট/সার্ভার সার্টিফিকেটটি প্রত্যাখ্যান করে এবং আপনি tcpdump এ নিম্নলিখিত সতর্কবার্তাটি দেখতে পাবেন:

   সতর্কতা (স্তর: মারাত্মক, বিবরণ: সার্টিফিকেটের মেয়াদ উত্তীর্ণ)

10. সংশ্লিষ্ট হোস্টের কীস্টোরে থাকা সার্টিফিকেটটির মেয়াদ শেষ হয়ে গেছে কিনা তা যাচাই করুন।

সমাধান

উপরের উদাহরণে চিহ্নিত সমস্যাটি সমাধান করতে, মেসেজ প্রসেসরের ট্রাস্টোরে বৈধ ব্যাকএন্ড সার্ভারের সার্টিফিকেটটি আপলোড করুন।

নিচের সারণিতে সমস্যার কারণের ওপর ভিত্তি করে এটি সমাধানের ধাপগুলো সংক্ষেপে তুলে ধরা হলো।

SNI সক্রিয় সার্ভার

TLS/SSL হ্যান্ডশেক ব্যর্থতা তখন ঘটতে পারে যখন ক্লায়েন্ট একটি সার্ভার নেম ইন্ডিকেশন (SNI) সক্ষম সার্ভারের সাথে যোগাযোগ করছে, কিন্তু ক্লায়েন্টটি নিজে SNI সক্ষম নয়। Edge-এ এটি নর্থবাউন্ড বা সাউথবাউন্ড উভয় সংযোগেই ঘটতে পারে।

প্রথমে, আপনাকে ব্যবহৃত সার্ভারের হোস্টনেম ও পোর্ট নম্বর শনাক্ত করতে হবে এবং সেটি SNI সক্রিয় আছে কি না, তা যাচাই করতে হবে।

SNI সক্রিয় সার্ভার শনাক্তকরণ

1. নিচে দেখানো পদ্ধতি অনুযায়ী, সার্ভারের নাম উল্লেখ না করে openssl কমান্ডটি চালান এবং প্রাসঙ্গিক সার্ভার হোস্টনেমে (এজ রাউটার বা ব্যাকএন্ড সার্ভার) সংযোগ করার চেষ্টা করুন:

   openssl s_client -connect hostname:port

   আপনি সার্টিফিকেটগুলো পেতে পারেন এবং কখনও কখনও openssl কমান্ডে হ্যান্ডশেক ব্যর্থতা লক্ষ্য করতে পারেন, যেমনটি নিচে দেখানো হয়েছে:
   

   CONNECTED(00000003)
   9362:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s23_clnt.c:593

2. openssl কমান্ডটি চালান এবং নিচে দেখানো অনুযায়ী সার্ভারের নামটি দিয়ে প্রাসঙ্গিক সার্ভার হোস্টনেমের (এজ রাউটার বা ব্যাকএন্ড সার্ভার) সাথে সংযোগ করার চেষ্টা করুন:

   openssl s_client -connect hostname:port -servername hostname

3. যদি ধাপ #১-এ হ্যান্ডশেক ব্যর্থতা ঘটে অথবা ধাপ #১ এবং ধাপ #২-এ ভিন্ন ভিন্ন সার্টিফিকেট পাওয়া যায়, তাহলে এটি নির্দেশ করে যে নির্দিষ্ট সার্ভারটি SNI সক্রিয় করা আছে।

সার্ভারটি SNI সক্রিয় কিনা তা শনাক্ত করার পর, ক্লায়েন্ট SNI সার্ভারের সাথে যোগাযোগ করতে না পারার কারণে TLS/SSL হ্যান্ডশেক ব্যর্থ হচ্ছে কিনা তা পরীক্ষা করতে আপনি নিচের ধাপগুলো অনুসরণ করতে পারেন।

রোগ নির্ণয়

1. ত্রুটিটি উত্তরমুখী নাকি দক্ষিণমুখী সংযোগস্থলে ঘটেছে তা নির্ণয় করুন। এই নির্ণয় করার বিষয়ে আরও নির্দেশনার জন্য, ‘সমস্যার উৎস নির্ণয় ’ দেখুন।
2. আরও তথ্য সংগ্রহ করতে tcpdump ইউটিলিটিটি চালান:
   • আপনি যদি একজন প্রাইভেট ক্লাউড ব্যবহারকারী হন, তাহলে আপনি প্রাসঙ্গিক ক্লায়েন্ট বা সার্ভার থেকে tcpdump ডেটা সংগ্রহ করতে পারেন। একটি ক্লায়েন্ট হতে পারে ক্লায়েন্ট অ্যাপ (ইনকামিং বা নর্থবাউন্ড সংযোগের জন্য) অথবা মেসেজ প্রসেসর (আউটগোয়িং বা সাউথবাউন্ড সংযোগের জন্য)। ধাপ ১-এ আপনার নির্ধারণের উপর ভিত্তি করে একটি সার্ভার হতে পারে এজ রাউটার (ইনকামিং বা নর্থবাউন্ড সংযোগের জন্য) অথবা ব্যাকএন্ড সার্ভার (আউটগোয়িং বা সাউথবাউন্ড সংযোগের জন্য)।
   • আপনি যদি একজন পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে আপনি tcpdump ডেটা শুধুমাত্র ক্লায়েন্ট অ্যাপে (ইনকামিং বা নর্থবাউন্ড সংযোগের জন্য) অথবা ব্যাকএন্ড সার্ভারে (আউটগোয়িং বা সাউথবাউন্ড সংযোগের জন্য) সংগ্রহ করতে পারবেন, কারণ আপনার এজ রাউটার বা মেসেজ প্রসেসরে অ্যাক্সেস নেই।

   tcpdump -i any -s 0 host IP address -w File name
   

   tcpdump কমান্ড ব্যবহারের বিষয়ে আরও তথ্যের জন্য tcpdump ডেটা দেখুন।
3. Wireshark বা অনুরূপ কোনো টুল ব্যবহার করে tcpdump আউটপুট বিশ্লেষণ করুন।
4. এখানে Wireshark ব্যবহার করে tcpdump এর একটি নমুনা বিশ্লেষণ দেওয়া হলো:
   1. এই উদাহরণে, এজ মেসেজ প্রসেসর এবং ব্যাকএন্ড সার্ভারের (সাউথবাউন্ড কানেকশন) মধ্যে TLS/SSL হ্যান্ডশেক ব্যর্থতা ঘটেছে।
   2. নীচের tcpdump আউটপুটের ৪ নম্বর বার্তাটি থেকে বোঝা যায় যে, মেসেজ প্রসেসর (সোর্স) ব্যাকএন্ড সার্ভারে (গন্তব্য) একটি "ক্লায়েন্ট হ্যালো" বার্তা পাঠিয়েছে।

      

   3. ‘ক্লায়েন্ট হ্যালো’ বার্তাটি নির্বাচন করলে বোঝা যায় যে মেসেজ প্রসেসরটি TLSv1.2 প্রোটোকল ব্যবহার করছে।

      

   4. বার্তা #৪ থেকে বোঝা যায় যে, ব্যাকএন্ড সার্ভার মেসেজ প্রসেসরের কাছ থেকে আসা "ক্লায়েন্ট হ্যালো" বার্তাটি স্বীকার করেছে।
   5. ব্যাকএন্ড সার্ভার অবিলম্বে মেসেজ প্রসেসরের কাছে একটি মারাত্মক সতর্কতা: হ্যান্ডশেক ব্যর্থতা (বার্তা #৫) পাঠায়। এর অর্থ হলো TLS/SSL হ্যান্ডশেক ব্যর্থ হয়েছে এবং সংযোগটি বন্ধ করে দেওয়া হবে।
   6. নিম্নলিখিত তথ্যগুলো জানতে ৬ নম্বর বার্তাটি পর্যালোচনা করুন।
      • ব্যাকএন্ড সার্ভারটি TLSv1.2 প্রোটোকল সমর্থন করে। এর মানে হলো, মেসেজ প্রসেসর এবং ব্যাকএন্ড সার্ভারের মধ্যে প্রোটোকলটি মিলে গেছে।
      • তবে, ব্যাকএন্ড সার্ভারটি এখনও মেসেজ প্রসেসরের কাছে ' Fatal Alert: Handshake Failure' বার্তাটি পাঠায়, যেমনটি নিচের চিত্রে দেখানো হয়েছে:

        

   7. এই ত্রুটিটি নিম্নলিখিত কারণগুলোর কোনো একটির জন্য ঘটতে পারে:
      • মেসেজ প্রসেসরটি ব্যাকএন্ড সার্ভার দ্বারা সমর্থিত সাইফার স্যুট অ্যালগরিদমগুলো ব্যবহার করছে না।
      • ব্যাকএন্ড সার্ভারটি SNI সক্রিয় করা আছে, কিন্তু ক্লায়েন্ট অ্যাপ্লিকেশনটি সার্ভারের নাম পাঠাচ্ছে না।
   8. tcpdump আউটপুটে থাকা ৩ নং বার্তা (ক্লায়েন্ট হ্যালো) আরও বিস্তারিতভাবে পর্যালোচনা করুন। লক্ষ্য করুন যে, নিচে দেখানো অনুযায়ী Extension: server_name অনুপস্থিত রয়েছে:

      

   9. এটি নিশ্চিত করে যে মেসেজ প্রসেসরটি SNI-সক্ষম ব্যাকএন্ড সার্ভারে server_name পাঠায়নি।
   10. এটাই TLS/SSL হ্যান্ডশেক ব্যর্থ হওয়ার কারণ এবং এই কারণেই ব্যাকএন্ড সার্ভার মেসেজ প্রসেসরের কাছে ‘Fatal Alert: Handshake Failure’ বার্তাটি পাঠায়।
5. মেসেজ প্রসেসরটি যে SNI-সক্ষম সার্ভারের সাথে যোগাযোগের জন্য সক্ষম নয়, তা নিশ্চিত করতে system.properties ফাইলে থাকা jsse.enableSNIExtension property false-এ সেট করা আছে কিনা তা যাচাই করুন।

সমাধান

নিম্নলিখিত ধাপগুলি অনুসরণ করে মেসেজ প্রসেসর(গুলি)-কে SNI সক্ষম সার্ভারগুলির সাথে যোগাযোগ করতে সক্ষম করুন:

1. /opt/apigee/customer/application/message-processor.properties ফাইলটি তৈরি করুন (যদি এটি আগে থেকে বিদ্যমান না থাকে)।
2. এই ফাইলে নিম্নলিখিত লাইনটি যোগ করুন: conf_system_jsse.enableSNIExtension=true
3. এই ফাইলের মালিকানা apigee:apigee তে পরিবর্তন করুন:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. মেসেজ প্রসেসরটি পুনরায় চালু করুন।

   /opt/apigee/apigee-service/bin/apigee-service message-processor restart

5. আপনার যদি একাধিক মেসেজ প্রসেসর থাকে, তাহলে সমস্ত মেসেজ প্রসেসরের ক্ষেত্রে ১ থেকে ৪ নম্বর ধাপগুলো পুনরাবৃত্তি করুন।

যদি আপনি TLS/SSL হ্যান্ডশেক ব্যর্থতার কারণ নির্ণয় করতে এবং সমস্যাটি সমাধান করতে না পারেন অথবা আপনার আরও কোনো সহায়তার প্রয়োজন হয়, তাহলে Apigee Edge Support-এর সাথে যোগাযোগ করুন। tcpdump আউটপুট সহ সমস্যাটির সম্পূর্ণ বিবরণ শেয়ার করুন।