دست‌دهی ناموفق TLS/SSL

درحال مشاهده اسناد Apigee Edge هستید.
به اسناد Apigee X بروید. اطلاعات

نشانه

خطای دست دادن TLS/SSL زمانی رخ می‌دهد که یک کارخواه و سرور نتوانند بااستفاده از پروتکل TLS/SSL ارتباط برقرار کنند. وقتی این خطا در Apigee Edge رخ می‌دهد، برنامه کاربر وضعیت HTTP 503 را با پیام سرویس دردسترس نیست دریافت می‌کند. این خطا را پس‌از هر فراخوانی API که در آن دست دادن TLS/SSL ناموفق باشد می‌بینید.

پیام های خطا

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 داده‌ها را فقط در برنامه مشتری (برای اتصالات ورودی یا شمالی) یا سرور پشتیبان (برای اتصالات خروجی یا جنوبی) جمع‌آوری کنید، زیرا به «روتر لبه» یا «پردازشگر پیام» دسترسی ندارید.

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

   برای اطلاعات بیشتر درباره استفاده از فرمان tcpdump ، داده‌های tcpdump را ببینید.
3. داده‌های tcpdump را بااستفاده از ابزار Wireshark یا ابزاری مشابه تجزیه‌وتحلیل کنید.
4. در اینجا تجزیه‌وتحلیل نمونه‌ای از tcpdump بااستفاده از Wireshark آمده است:
   • در این مثال، تبادل دست TLS/SSL بین «پردازنده پیام» و سرور زیرینه (اتصال خروجی یا جنوبی) ناموفق بود.
   • پیام شماره ۴ در برونداد tcpdump در زیر نشان می‌دهد که «پردازشگر پیام» (منبع) پیام «سلام مشتری» را به سرور پشتیبان (مقصد) ارسال کرده است.
     

     

   • اگر پیام Client Hello را انتخاب کنید، نشان می‌دهد که «پردازنده پیام» از پروتکل TLSv1.2 استفاده می‌کند، همان‌طور که در زیر نشان داده شده است:

     

   • پیام شماره ۵ نشان می‌دهد که سرور زیرینه پیام «سلام کارخواه» را از «پردازشگر پیام» تأیید می‌کند.
   • سرور زیرینه بلافاصله هشدار مهلک : اعلان بستن را به «پردازشگر پیام» (پیام شماره ۶) ارسال می‌کند. این یعنی «دست‌دهی امنیت لایه انتقال/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. اگر سرور هدف را برای پراکسی خود پیکربندی کرده‌اید، از این API مدیریت برای تنظیم پروتکل روی TLSv1.0 در پیکربندی سرور هدف خاص استفاده کنید.

عدم تطابق رمز

اگر الگوریتم مجموعه رمز مورد استفاده توسط مشتری در اتصال ورودی (شمالی) یا خروجی (جنوبی) در Apigee Edge توسط سرور پشتیبانی نشود، می‌توانید خطای دست دادن TLS/SSL را مشاهده کنید. همچنین درک اتصالات شمالی و جنوبی را ببینید.

تشخیص

1. تعیین کنید که خطا در اتصال شمالی یا جنوبی رخ داده است. برای راهنمایی بیشتر درباره انجام این تعیین، به تعیین منبع مشکل مراجعه کنید.
2. برای جمع‌آوری اطلاعات بیشتر، ابزار tcpdump را اجرا کنید:
   • اگر کاربر «ابر خصوصی» هستید، می‌توانید tcpdump داده‌ها را در کارخواه یا سرور مربوطه جمع‌آوری کنید. کارخواه می‌تواند برنامه کارخواه (برای اتصالات ورودی یا شمالی) یا «پردازشگر پیام» (برای اتصالات خروجی یا جنوبی) باشد. براساس تشخیص شما در «مرحله ۱»، سرور می‌تواند «رهیاب لبه» (برای اتصالات ورودی یا شمالی) یا سرور زیرینه (برای اتصالات خروجی یا جنوبی) باشد.
   • اگر کاربر «ابر عمومی» هستید، می‌توانید tcpdump داده‌ها را فقط در برنامه مشتری (برای اتصالات ورودی یا شمالی) یا سرور پشتیبان (برای اتصالات خروجی یا جنوبی) جمع‌آوری کنید، زیرا به «روتر لبه» یا «پردازشگر پیام» دسترسی ندارید.

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

   برای اطلاعات بیشتر درباره استفاده از فرمان tcpdump، داده‌های tcpdump را ببینید.
3. داده‌های tcpdump را بااستفاده از ابزار Wireshark یا هر ابزار دیگری که با آن آشنا هستید تجزیه‌وتحلیل کنید.
4. در اینجا تجزیه‌وتحلیل نمونه‌ای از برونداد tcpdump بااستفاده از Wireshark آمده است:
   • در این مثال، خطای «دست دادن امنیت لایه انتقال/پوسته ایمن» بین «برنامه کارخواه» و روتر Edge (اتصال شمالی) رخ داده است. برونداد tcpdump در رهیاب Edge جمع‌آوری شد.

   • پیام شماره ۴ در برونداد tcpdump در زیر نشان می‌دهد که برنامه کارخواه (منبع) پیام «سلام کارخواه» را به «مسیریاب لبه» (مقصد) ارسال کرده است.

     

   • انتخاب پیام «سلام مشتری» نشان می‌دهد که برنامه مشتری از پروتکل TLSv1.2 استفاده می‌کند.

     

   • پیام شماره ۵ نشان می‌دهد که «مسیریاب لبه» پیام «سلام کارخواه» را از برنامه کارخواه تأیید می‌کند.
   • روتر Edge بلافاصله هشدار مهلک : دست‌دهی ناموفق را به برنامه کارخواه ارسال می‌کند (پیام شماره ۶). این یعنی دست‌دهی TLS/SSL ناموفق بود و اتصال بسته خواهد شد.
   • با بررسی بیشتر پیام شماره ۶، اطلاعات زیر نشان داده می‌شود:
     • «مسیریاب لبه» از پروتکل TLSv1.2 پشتیبانی می‌کند. این یعنی پروتکل بین برنامه کلاینت و «مسیریاب لبه» مطابقت دارد.

     • بااین‌حال، همان‌طور که در نماگرفت زیر نشان داده شده است، مسیریاب Edge همچنان هشدار مهلک: دست دادن ناموفق را به برنامه کارخواه ارسال می‌کند:

       

   • این خطا می‌تواند نتیجه یکی از مشکلات زیر باشد:
     • برنامه کارخواه از الگوریتم‌های مجموعه رمز پشتیبانی‌شده توسط «مسیریاب لبه» استفاده نمی‌کند.
     • «مسیریاب لبه» دارای قابلیت SNI است، اما برنامه کارخواه نام سرور را ارسال نمی‌کند.
   • پیام شماره ۴ در برونداد tcpdump فهرست الگوریتم‌های مجموعه رمز پشتیبانی‌شده توسط برنامه کاربر را نشان می‌دهد، همان‌طور که در زیر نشان داده شده است:

     

   • فهرست الگوریتم‌های مجموعه رمز پشتیبانی‌شده توسط «مسیریاب لبه» در فایل /opt/nginx/conf.d/0-default.conf فهرست شده است. در این مثال، «مسیریاب لبه» فقط از الگوریتم‌های مجموعه رمز «رمزگذاری بالا» پشتیبانی می‌کند.
   • برنامه کارخواه از هیچ‌یک از الگوریتم‌های مجموعه رمز «رمزگذاری بالا» استفاده نمی‌کند. این عدم تطابق دلیل ناموفق بودن دست دادن TLS/SSL است.
   • چون «مسیریاب Edge» با SNI فعال است، به پیام شماره ۴ در برونداد tcpdump پیمایش کنید و تأیید کنید که برنامه مشتری نام سرور را به‌درستی ارسال می‌کند، همان‌طور که در شکل زیر نشان داده شده است:
     
     
     
   • اگر این نام معتبر است، می‌توانید نتیجه بگیرید که مبادله دست TLS/SSL به این دلیل ناموفق بوده است که الگوریتم‌های مجموعه رمز استفاده‌شده توسط برنامه کارخواه توسط «مسیریاب لبه» پشتیبانی نمی‌شود.

وضوح

باید مطمئن شوید که کارخواه از الگوریتم‌های مجموعه رمز که توسط سرور پشتیبانی می‌شوند استفاده می‌کند. برای حل مشکل شرح‌داده‌شده در بخش «تشخیص خرابی»، بسته Java Cryptography Extension (JCE) را بارگیری و نصب کنید و آن را در نصب Java قرار دهید تا از الگوریتم‌های مجموعه رمزگذاری «رمزگذاری بالا» پشتیبانی کند.

گواهینامه نادرست

اگر گواهینامه‌های نادرستی در keystore/truststore داشته باشید، چه در اتصال ورودی (شمالی) و چه در اتصال خروجی (جنوبی) در 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» زیر را یادداشت کنید:

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

   برای مثال:

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

2. «نام متعارف» استفاده‌شده در گواهی ذخیره‌شده در انبار کلید خاص را دریافت کنید. می‌توانید از Edge management APIs زیر برای دریافت جزئیات گواهینامه استفاده کنید:
   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» دریافت کنید.
      
      اگر کاربر «ابر خصوصی» هستید:
      

      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 (به مرحله ۱ در بالا مراجعه کنید) و نام موضوع در گواهینامه مطابقت ندارند، با خطای دست دادن TLS/SSL مواجه می‌شوید.

وضوح

این مشکل را می‌توان به یکی از دو روش زیر حل کرد:

• گواهی‌ای (اگر ازقبل ندارید) دریافت کنید که در آن CN موضوع گواهی دارای کارت عام باشد، سپس زنجیره گواهی کامل جدید را در انبار کلید بارگذاری کنید. برای مثال:

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

• گواهی‌ای (اگر ازقبل ندارید) با CN موضوع موجود دریافت کنید، اما از your-org استفاده کنید.your-domain را به‌عنوان نام جایگزین موضوع، سپس زنجیره گواهی کامل را در انبار کلید بارگذاری کنید.

مرجع‌ها

فروشگاه‌های کلید و فروشگاه‌های مطمئن

زنجیره گواهینامه ناقص یا نادرست

تشخیص

1. «نام متعارف» استفاده‌شده در گواهی ذخیره‌شده در انبار کلید خاص را دریافت کنید. می‌توانید از Edge management APIs زیر برای دریافت جزئیات گواهینامه استفاده کنید:
   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. داده‌های tcpdump را بااستفاده از Wireshark یا ابزاری مشابه تجزیه‌وتحلیل کنید.
4. از برونداد tcpdump، میزبان (کارخواه یا سرور) را که گواهینامه را در مرحله درستی‌سنجی رد می‌کند تعیین کنید.
5. می‌توانید گواهینامه ارسال‌شده از طرف دیگر را از برونداد tcpdump بازیابی کنید، به‌شرطی که داده‌ها رمزگذاری نشده باشند. این کار برای مقایسه اینکه آیا این گواهینامه با گواهینامه موجود در فروشگاه مطمئن مطابقت دارد یا نه مفید است.
6. نمونه tcpdump را برای ارتباط SSL بین «پردازشگر پیام» و سرور زیرینه مرور کنید.

   نمونه tcpdump نشان‌دهنده خطای «گواهینامه ناشناخته»

   
   

   1. «پردازشگر پیام» (کارخواه) در پیام شماره ۵۹ «سلام کارخواه» را به سرور زیرینه (سرور) ارسال می‌کند.
   2. سرور زیرینه «سلام سرور» را در پیام #۶۱ به «پردازشگر پیام» ارسال می‌کند.
   3. آن‌ها الگوریتم‌های پروتکل و مجموعه رمز مورد استفاده را به‌صورت متقابل اعتبارسنجی می‌کنند.
   4. سرور زیرینه پیام «گواهی» و «سرور سلام تمام» را در پیام شماره ۶۸ به «پردازنده پیام» ارسال می‌کند.
   5. «پردازشگر پیام» هشدار مهلک «شرح: گواهینامه ناشناس» را در پیام شماره ۷۰ ارسال می‌کند.
   6. با بررسی بیشتر پیام شماره ۷۰، جزئیات دیگری به‌جز پیام هشدار که در زیر نشان داده شده است وجود ندارد:

      
      

   7. برای دریافت جزئیات گواهینامه ارسالی از سرور زیرینه، پیام شماره ۶۸ را مرور کنید، همان‌طور که در گرافیک زیر نشان داده شده است:

      

   8. گواهینامه سرور زیرینه و زنجیره کامل آن در بخش «گواهینامه‌ها» دردسترس است، همان‌طور که در شکل بالا نشان داده شده است.
7. اگر گواهینامه توسط «مسیریاب» (شمالی) یا «پردازشگر پیام» (جنوبی) ناشناخته تشخیص داده شود، همان‌طور که در مثال بالا نشان داده شده است، مراحل زیر را دنبال کنید:
   1. گواهی و زنجیره آن را که در انبار اعتماد خاصی ذخیره شده است دریافت کنید. (به پیکربندی میزبان مجازی برای «روتر» و پیکربندی نقطه پایانی هدف برای «پردازشگر پیام» مراجعه کنید). می‌توانید از میاناهای برنامه‌سازی کاربردی زیر برای دریافت جزئیات گواهینامه استفاده کنید:
      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. بررسی کنید گواهی ذخیره‌شده در truststore «مسیریاب» (شمالی) یا «پردازشگر پیام» (جنوبی) با گواهی ذخیره‌شده در keystore برنامه کارخواه (شمالی) یا سرور هدف (جنوبی)، یا گواهی‌ای که از برونداد tcpdump به‌دست آمده است مطابقت داشته باشد. اگر عدم تطابقی وجود داشته باشد، دلیل ناموفق بودن دست دادن TLS/SSL همین است.
8. اگر مشخص شود که گواهینامه توسط برنامه کارخواه (شمالی) یا سرور هدف (جنوبی) ناشناخته است، این مراحل را دنبال کنید:
   1. زنجیره گواهینامه کامل استفاده‌شده در گواهینامه ذخیره‌شده در محل ذخیره کلید خاص را دریافت کنید. (برای پیکربندی میزبان مجازی «روتر» و پیکربندی نقطه پایانی مقصد «پردازشگر پیام» مراجعه کنید.) می‌توانید از میاناهای برنامه‌سازی کاربردی زیر برای دریافت جزئیات گواهینامه استفاده کنید:
      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. بررسی کنید گواهینامه ذخیره‌شده در keystore «مسیریاب» (شمالی) یا «پردازشگر پیام» (جنوبی) با گواهینامه ذخیره‌شده در truststore برنامه کارخواه (شمالی) یا سرور مقصد (جنوبی) یا گواهینامه‌ای که از برونداد tcpdump به‌دست آمده است مطابقت داشته باشد. اگر عدم تطابقی وجود داشته باشد، دلیل ناموفق بودن دست‌دهی SSL همین است.
9. اگر گواهینامه ارسالی از سرور/کارخواه منقضی شده باشد، کارخواه/سرور دریافت‌کننده گواهینامه را رد می‌کند و پیام هشدار زیر را در tcpdump می‌بینید:

   هشدار (سطح: مهلک، شرح: گواهینامه منقضی شده است)

10. تأیید کنید که گواهینامه در انبار کلید میزبان مناسب منقضی شده است.

وضوح

برای حل کردن مشکل شناسایی‌شده در مثال بالا، گواهینامه معتبر سرور زیرینه را در «مخزن اعتماد» در «پردازشگر پیام» بارگذاری کنید.

جدول زیر مراحل حل مشکل را بسته به علت مشکل خلاصه می‌کند.

‫SNI فعال است سرور

وقتی مشتری با سرور «نام سرور مشخص‌شده» (SNI) فعال ارتباط برقرار می‌کند، اما مشتری SNI فعال نیست، ممکن است مذاکره TLS/SSL با شکست مواجه شود. این اتفاق می‌تواند در اتصال شمالی یا جنوبی در Edge رخ دهد.

ابتدا باید نام میزبان و شماره درگاه سرور مورد استفاده را شناسایی کنید و بررسی کنید که آیا «نشانگر نام سرور» فعال است یا نه.

شناسایی سرور فعال 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 داده‌ها را فقط در برنامه مشتری (برای اتصالات ورودی یا شمالی) یا سرور پشتیبان (برای اتصالات خروجی یا جنوبی) جمع‌آوری کنید، زیرا به «روتر لبه» یا «پردازشگر پیام» دسترسی ندارید.

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

   برای اطلاعات بیشتر درباره استفاده از فرمان tcpdump، داده‌های tcpdump را ببینید.
3. برونداد tcpdump را بااستفاده از Wireshark یا ابزاری مشابه تجزیه‌وتحلیل کنید.
4. در اینجا تجزیه‌وتحلیل نمونه tcpdump بااستفاده از Wireshark آمده است:
   1. در این مثال، دست دادن TLS/SSL بین «پردازنده پیام Edge» و سرور زیرینه (اتصال جنوبی) انجام نشد.
   2. پیام شماره ۴ در برونداد tcpdump در زیر نشان می‌دهد که «پردازشگر پیام» (منبع) پیام «سلام مشتری» را به سرور زیرینه (مقصد) ارسال کرده است.

      

   3. انتخاب پیام «سلام مشتری» نشان می‌دهد که «پردازنده پیام» از پروتکل TLSv1.2 استفاده می‌کند.

      

   4. پیام شماره ۴ نشان می‌دهد که سرور زیرینه پیام «سلام کارخواه» از «پردازشگر پیام» را تأیید می‌کند.
   5. سرور زیرینه بلافاصله هشدار مهلک : دست دادن ناموفق را به «پردازشگر پیام» (پیام شماره ۵) ارسال می‌کند. این یعنی دست‌دهی TLS/SSL ناموفق بود و اتصال بسته خواهد شد.
   6. برای کشف اطلاعات زیر، پیام شماره ۶ را مرور کنید
      • سرور زیرینه از پروتکل TLSv1.2 پشتیبانی می‌کند. این یعنی پروتکل بین «پردازشگر پیام» و سرور زیرینه مطابقت دارد.
      • بااین‌حال، سرور زیرینه همچنان Fatal Alert: Handshake Failure را به «پردازشگر پیام» ارسال می‌کند، همان‌طور که در شکل زیر نشان داده شده است:

        

   7. این خطا ممکن است به یکی از دلایل زیر رخ دهد:
      • «پردازشگر پیام» از الگوریتم‌های مجموعه رمز پشتیبانی‌شده توسط سرور زیرینه استفاده نمی‌کند.
      • سرور زیرینه SNI فعال است، اما برنامه مشتری نام سرور را ارسال نمی‌کند.
   8. پیام شماره ۳ (Client Hello) را در برونداد tcpdump با جزئیات بیشتری مرور کنید. توجه داشته باشید که افزونه: server_name وجود ندارد، همان‌طور که در زیر نشان داده شده است:

      

   9. این تأیید می‌کند که «پردازنده پیام» server_name را به سرور پشتیبان فعال‌شده با SNI ارسال نکرده است.
   10. این دلیل عدم موفقیت دست دادن TLS/SSL و دلیل ارسال هشدار مهلک: عدم موفقیت دست دادن ازسوی سرور زیرینه به «پردازنده پیام» است.
5. تأیید کنید که jsse.enableSNIExtension property در system.properties در «پردازشگر پیام» روی false تنظیم شده باشد تا مطمئن شوید که «پردازشگر پیام» برای ارتباط با سرور فعال‌شده با SNI فعال نشده است.

وضوح

با انجام مراحل زیر، «پردازشگر(های) پیام» را برای برقراری ارتباط با سرورهای دارای 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 هم‌رسانی کنید.