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 ডেটা সংগ্রহ করতে পারবেন। ক্লায়েন্ট, ক্লায়েন্ট অ্যাপ (ইনকামিং, বা নর্থবাউন্ড কানেকশনের জন্য) বা মেসেজ প্রসেসর (আউটগোয়িং বা সাউথবাউন্ড কানেকশনের জন্য) হতে পারে। ধাপ ১ থেকে আপনার নির্ধারণের উপর ভিত্তি করে, কোনও সার্ভার এজ রাউটার (ইনকামিং বা নর্থবাউন্ড কানেকশনের জন্য) বা ব্যাকএন্ড সার্ভার (আউটগোয়িং বা সাউথবাউন্ড কানেকশনের জন্য) হতে পারে।
   • আপনি পাবলিক ক্লাউড ব্যবহারকারী হলে, আপনি শুধুমাত্র ক্লায়েন্ট অ্যাপে (ইনকামিং বা নর্থবাউন্ড কানেকশনের জন্য) অথবা ব্যাকএন্ড সার্ভারে (আউটগোয়িং বা সাউথবাউন্ড কানেকশনের জন্য) tcpdump ডেটা সংগ্রহ করতে পারবেন, কারণ আপনার কাছে Edge রাউটার বা মেসেজ প্রসেসরের অ্যাক্সেস নেই।

   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 প্রোটোকল ব্যবহার করে, যেমন নিচে দেখানো হয়েছে:

     

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

রেজোলিউশন

মেসেজ প্রসেসর Java 8-এ চলে এবং ডিফল্ট হিসেবে 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 ডেটা সংগ্রহ করতে পারবেন, কারণ আপনার কাছে Edge রাউটার বা মেসেজ প্রসেসরের অ্যাক্সেস নেই।

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

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

   • নিচের tcpdump আউটপুটে #৪ মেসেজ থেকে দেখা যাচ্ছে যে ক্লায়েন্ট অ্যাপ্লিকেশন (সোর্স) Edge Router (ডেস্টিনেশন)-কে একটি "Client Hello" মেসেজ পাঠিয়েছে।

     

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

     

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

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

       

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

     

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

রেজোলিউশন

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

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

আপনার কীস্টোর/ট্রাস্টস্টোরে ভুল সার্টিফিকেট থাকলে, 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. নিম্নলিখিত Edge ম্যানেজমেন্ট API কলের মাধ্যমে ফিরে আসা URL-এ ব্যবহৃত হোস্টনেমটি মনে রাখবেন:

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

   যেমন:

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

2. নির্দিষ্ট কীস্টোরে সেভ করা সার্টিফিকেটে ব্যবহৃত CN পান। সার্টিফিকেটের বিবরণ পেতে, আপনি নিম্নলিখিত Edge ম্যানেজমেন্ট 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. 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.

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

রেজোলিউশন

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

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

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

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

রেফারেন্স

কীস্টোর ও ট্রাস্টস্টোর

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

ডায়াগনসিস

1. নির্দিষ্ট কীস্টোরে সেভ করা সার্টিফিকেটে ব্যবহৃত CN পান। সার্টিফিকেটের বিবরণ পেতে, আপনি নিম্নলিখিত Edge ম্যানেজমেন্ট 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 ডেটা সংগ্রহ করতে পারবেন, কারণ আপনার কাছে Edge রাউটার বা মেসেজ প্রসেসরের অ্যাক্সেস নেই।

   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. ব্যাকএন্ড সার্ভার মেসেজ #61-এ মেসেজ প্রসেসরকে "Server Hello" পাঠায়।
   3. তারা ব্যবহৃত প্রোটোকল এবং সাইফার স্যুট অ্যালগরিদমকে পারস্পরিকভাবে যাচাই করে।
   4. ব্যাকএন্ড সার্ভার মেসেজ #৬৮-এ মেসেজ প্রসেসরকে সার্টিফিকেট ও সার্ভার হ্যালো সম্পূর্ণ মেসেজ পাঠায়।
   5. মেসেজ প্রসেসর মেসেজ #৭০-এ Fatal Alert "Description: Certificate Unknown" পাঠায়।
   6. মেসেজ #৭০-এ আরও বিশদে দেখলে, নিচে দেখানো সতর্কতা মেসেজ ছাড়া আর কোনও অতিরিক্ত বিবরণ নেই:

      
      

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

      

   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 চালু করা নেই। এটি Edge-এ নর্থবাউন্ড বা সাউথবাউন্ড কানেকশনে হতে পারে।

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

SNI চালু থাকা সার্ভার শনাক্তকরণ

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

   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 চালু আছে বলে শনাক্ত করার পরে, আপনি নিচের ধাপগুলি অনুসরণ করে TLS/SSL হ্যান্ডশেক ব্যর্থ হওয়ার কারণ ক্লায়েন্ট SNI সার্ভারের সাথে যোগাযোগ করতে না পারা কিনা তা চেক করতে পারবেন।

ডায়াগনসিস

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

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

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

      

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

      

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

        

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

      

   9. এটি কনফার্ম করে যে মেসেজ প্রসেসর SNI চালু থাকা ব্যাকএন্ড সার্ভারে server_name পাঠায়নি।
   10. এটি TLS/SSL হ্যান্ডশেক ব্যর্থ হওয়ার কারণ এবং এই কারণে ব্যাকএন্ড সার্ভার মেসেজ প্রসেসরকে মারাত্মক সতর্কতা: হ্যান্ডশেক ব্যর্থ হয়েছে পাঠায়।
5. SNI চালু থাকা সার্ভারের সাথে যোগাযোগ করার জন্য মেসেজ প্রসেসর চালু করা নেই তা কনফার্ম করতে, মেসেজ প্রসেসরে jsse.enableSNIExtension property in system.properties 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 সহায়তা টিমের সাথে যোগাযোগ করুন। সমস্যার সম্পূর্ণ বিবরণ এবং tcpdump আউটপুট শেয়ার করুন।