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

আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশনে যান । তথ্য

উপসর্গ

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

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

HTTP/1.1 503 Service Unavailable

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

Received fatal alert: handshake_failure

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

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

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

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

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

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

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

রোগ নির্ণয়

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

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

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

     

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

     

   • বার্তা #5 দেখায় যে ব্যাকএন্ড সার্ভার মেসেজ প্রসেসরের "ক্লায়েন্ট হ্যালো" বার্তাটি স্বীকার করে।
   • ব্যাকএন্ড সার্ভার অবিলম্বে মারাত্মক সতর্কতা পাঠায় : মেসেজ প্রসেসরকে অবহিত করুন (বার্তা #6)। এর মানে TLS/SSL হ্যান্ডশেক ব্যর্থ হয়েছে এবং সংযোগটি বন্ধ হয়ে যাবে।

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

     

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

রেজোলিউশন

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

1. TLSv1.2 প্রোটোকল সমর্থন করতে আপনার ব্যাকএন্ড সার্ভার আপগ্রেড করুন। এটি একটি প্রস্তাবিত সমাধান কারণ প্রোটোকল TLSv1.2 আরও সুরক্ষিত৷
2. আপনি যদি কোনো কারণে অবিলম্বে আপনার ব্যাকএন্ড সার্ভার আপগ্রেড করতে না পারেন, তাহলে আপনি এই পদক্ষেপগুলি অনুসরণ করে ব্যাকএন্ড সার্ভারের সাথে যোগাযোগ করতে TLSv1.0 প্রোটোকল ব্যবহার করতে বার্তা প্রসেসরকে বাধ্য করতে পারেন:
   1. আপনি যদি প্রক্সির টার্গেটএন্ডপয়েন্ট সংজ্ঞায় একটি টার্গেট সার্ভার নির্দিষ্ট না করে থাকেন, তাহলে নীচে দেখানো হিসাবে 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 ব্যবহার করুন।

সাইফার অমিল

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

রোগ নির্ণয়

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

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

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

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

     

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

     

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

     • যাইহোক, এজ রাউটার এখনও ক্লায়েন্ট অ্যাপ্লিকেশনে মারাত্মক সতর্কতা পাঠায়: হ্যান্ডশেক ব্যর্থতা নীচের স্ক্রিনশটে দেখানো হয়েছে:

       

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

     

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

রেজোলিউশন

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

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

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

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

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

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

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

* 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. নিম্নলিখিত এজ ম্যানেজমেন্ট API কল দ্বারা ফেরত URL-এ ব্যবহৃত হোস্টনামটি নোট করুন:

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

   যেমন:

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

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

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

      আপনি যদি একজন পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে নিম্নরূপ ব্যবস্থাপনা API ব্যবহার করুন:
      

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

   2. এজ ম্যানেজমেন্ট 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
          },

      প্রাথমিক শংসাপত্রে বিষয়ের নাম something.domain.com.

      যেহেতু API অনুরোধ URL-এ ব্যবহৃত হোস্টনাম (উপরে ধাপ #1 পড়ুন) এবং সার্টিফিকেটের বিষয়ের নাম মিলছে না, আপনি 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 ডেটা সংগ্রহ করতে পারেন। একজন ক্লায়েন্ট ক্লায়েন্ট অ্যাপ হতে পারে (আগত, বা উত্তরমুখী সংযোগের জন্য) অথবা বার্তা প্রসেসর (আউটগোয়িং বা দক্ষিণমুখী সংযোগের জন্য)। একটি সার্ভার হতে পারে এজ রাউটার (আগত, বা উত্তরমুখী সংযোগের জন্য) অথবা ব্যাকএন্ড সার্ভার (আউটগোয়িং বা দক্ষিণমুখী সংযোগের জন্য) ধাপ 1 থেকে আপনার সংকল্পের ভিত্তিতে।
   • আপনি যদি একজন পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে আপনি শুধুমাত্র ক্লায়েন্ট অ্যাপে (আগত, বা উত্তরমুখী সংযোগের জন্য) বা ব্যাকএন্ড সার্ভারে (আউটগোয়িং, বা সাউথবাউন্ড সংযোগের জন্য) 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. মেসেজ প্রসেসর (ক্লায়েন্ট) ব্যাকএন্ড সার্ভারে (সার্ভার) বার্তা #59 এ "ক্লায়েন্ট হ্যালো" পাঠায়।
   2. ব্যাকএন্ড সার্ভার মেসেজ প্রসেসরে "সার্ভার হ্যালো" পাঠায় #61 নম্বরে।
   3. তারা পারস্পরিকভাবে ব্যবহৃত প্রোটোকল এবং সাইফার স্যুট অ্যালগরিদম যাচাই করে।
   4. ব্যাকএন্ড সার্ভার সার্টিফিকেট এবং সার্ভার হ্যালো ডন বার্তা পাঠায় মেসেজ প্রসেসরকে #68-এ।
   5. মেসেজ প্রসেসর বার্তা #70 এ মারাত্মক সতর্কতা "বিবরণ: সার্টিফিকেট অজানা" পাঠায়।
   6. বার্তা #70 এর আরও খোঁজ করলে, নীচে দেখানো সতর্কতা বার্তা ছাড়া অন্য কোনও অতিরিক্ত বিবরণ নেই:

      
      

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

      

   8. ব্যাকএন্ড সার্ভারের শংসাপত্র এবং এর সম্পূর্ণ চেইন সমস্ত "শংসাপত্র" বিভাগের নীচে উপলব্ধ, যেমনটি উপরের চিত্রে দেখানো হয়েছে।
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 সক্ষম নয়৷ এটি উত্তরমুখী বা প্রান্তের দক্ষিণমুখী সংযোগে ঘটতে পারে।

প্রথমে, আপনাকে ব্যবহার করা সার্ভারের হোস্টনাম এবং পোর্ট নম্বর সনাক্ত করতে হবে এবং এটি 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. আপনি যদি ধাপ # 1 এ হ্যান্ডশেক ব্যর্থতা পান বা ধাপ # 1 এবং ধাপ # 2-এ বিভিন্ন শংসাপত্র পান, তাহলে এটি নির্দেশ করে যে নির্দিষ্ট সার্ভারটি SNI সক্ষম।

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

রোগ নির্ণয়

1. উত্তরমুখী বা দক্ষিণমুখী সংযোগে ত্রুটি ঘটেছে কিনা তা নির্ধারণ করুন। এই সংকল্প করার জন্য আরও নির্দেশনার জন্য, সমস্যার উৎস নির্ধারণ দেখুন।
2. আরও তথ্য সংগ্রহ করতে tcpdump ইউটিলিটি চালান:
   • আপনি যদি একজন ব্যক্তিগত ক্লাউড ব্যবহারকারী হন, তাহলে আপনি প্রাসঙ্গিক ক্লায়েন্ট বা সার্ভারে tcpdump ডেটা সংগ্রহ করতে পারেন। একজন ক্লায়েন্ট ক্লায়েন্ট অ্যাপ হতে পারে (আগত, বা উত্তরমুখী সংযোগের জন্য) অথবা বার্তা প্রসেসর (আউটগোয়িং বা দক্ষিণমুখী সংযোগের জন্য)। একটি সার্ভার হতে পারে এজ রাউটার (আগত, বা উত্তরমুখী সংযোগের জন্য) অথবা ব্যাকএন্ড সার্ভার (আউটগোয়িং বা দক্ষিণমুখী সংযোগের জন্য) ধাপ 1 থেকে আপনার সংকল্পের ভিত্তিতে।
   • আপনি যদি একজন পাবলিক ক্লাউড ব্যবহারকারী হন, তাহলে আপনি শুধুমাত্র ক্লায়েন্ট অ্যাপে (আগত, বা উত্তরমুখী সংযোগের জন্য) বা ব্যাকএন্ড সার্ভারে (আউটগোয়িং, বা সাউথবাউন্ড সংযোগের জন্য) 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 আউটপুটে বার্তা #4 দেখায় যে মেসেজ প্রসেসর (উৎস) ব্যাকএন্ড সার্ভারে (গন্তব্য) একটি "ক্লায়েন্ট হ্যালো" বার্তা পাঠিয়েছে।

      

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

      

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

        

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

      

   9. এটি নিশ্চিত করে যে মেসেজ প্রসেসর SNI- সক্ষম ব্যাকএন্ড সার্ভারে সার্ভার_নাম পাঠায়নি।
   10. এটি TLS/SSL হ্যান্ডশেক ব্যর্থতার কারণ এবং ব্যাকএন্ড সার্ভার মেসেজ প্রসেসরে মারাত্মক সতর্কতা: হ্যান্ডশেক ব্যর্থতার কারণ ।
5. যাচাই করুন যে system.properties এ jsse.enableSNIExtension property মেসেজ প্রসেসরে মিথ্যা সেট করা হয়েছে তা নিশ্চিত করতে যে মেসেজ প্রসেসর SNI-সক্ষম সার্ভারের সাথে যোগাযোগ করতে সক্ষম নয়।

রেজোলিউশন

নিম্নলিখিত পদক্ষেপগুলি সম্পাদন করে SNI সক্ষম সার্ভারগুলির সাথে যোগাযোগ করতে বার্তা প্রসেসর(গুলি) সক্ষম করুন:

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

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

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

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

5. আপনার যদি একাধিক মেসেজ প্রসেসর থাকে, তাহলে সমস্ত মেসেজ প্রসেসরে ধাপ #1 থেকে #4 পুনরাবৃত্তি করুন।

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