خطاهای دست دادن TLS/SSL

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

علامت

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

پیام های خطا 

HTTP/1.1 503 Service Unavailable

همچنین می توانید این پیغام خطا را در صورت بروز خطای دست دادن TLS/SSL مشاهده کنید:

Received fatal alert: handshake_failure

علل احتمالی

TLS (Transport Layer Security، که سلف آن SSL است) فناوری امنیتی استاندارد برای ایجاد یک پیوند رمزگذاری شده بین یک وب سرور و یک سرویس گیرنده وب، مانند یک مرورگر یا یک برنامه است. دست دادن فرآیندی است که سرویس گیرنده و سرویس گیرنده TLS/SSL را قادر می سازد مجموعه ای از کلیدهای مخفی را ایجاد کند تا بتوانند با آن ارتباط برقرار کنند. در طی این فرآیند، مشتری و سرور:

  1. در مورد نسخه پروتکل مورد استفاده توافق کنید.
  2. الگوریتم رمزنگاری مورد استفاده را انتخاب کنید.
  3. با مبادله و تایید گواهی های دیجیتال، یکدیگر را احراز هویت کنید.

اگر دست دادن TLS/SSL موفقیت آمیز باشد، مشتری و سرور TLS/SSL داده ها را به صورت ایمن به یکدیگر منتقل می کنند. در غیر این صورت، اگر خطای دست دادن TLS/SSL رخ دهد، اتصال قطع می‌شود و سرویس گیرنده خطای 503 Service Unavailable را دریافت می‌کند.

دلایل احتمالی خرابی دست دادن TLS/SSL عبارتند از:

علت توضیحات چه کسی می تواند مراحل عیب یابی را انجام دهد
عدم تطابق پروتکل پروتکل استفاده شده توسط سرویس گیرنده توسط سرور پشتیبانی نمی شود. کاربران خصوصی و عمومی Cloud
عدم تطابق مجموعه رمز مجموعه رمز استفاده شده توسط سرویس گیرنده توسط سرور پشتیبانی نمی شود. کاربران خصوصی و عمومی Cloud
گواهی نادرست نام میزبان در URL استفاده شده توسط مشتری با نام میزبان در گواهی ذخیره شده در انتهای سرور مطابقت ندارد. کاربران خصوصی و عمومی Cloud
یک زنجیره گواهی ناقص یا نامعتبر در انتهای سرویس گیرنده یا سرور ذخیره می شود. کاربران خصوصی و عمومی Cloud
یک گواهی نادرست یا منقضی شده توسط مشتری به سرور یا از سرور به مشتری ارسال می شود. کاربران خصوصی و عمومی Cloud
سرور فعال SNI سرور پشتیبان نشانگر نام سرور (SNI) فعال است. با این حال، مشتری نمی تواند با سرورهای SNI ارتباط برقرار کند. فقط کاربران خصوصی Cloud

عدم تطابق پروتکل

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

تشخیص

  1. تعیین کنید که آیا خطا در اتصال شمال یا جنوب رخ داده است. برای راهنمایی بیشتر در مورد این تعیین، به تعیین منبع مشکل مراجعه کنید.
  2. برای جمع آوری اطلاعات بیشتر، ابزار tcpdump را اجرا کنید:
    • اگر کاربر Private Cloud هستید، می توانید داده های tcpdump را در سرویس گیرنده یا سرور مربوطه جمع آوری کنید. یک کلاینت می تواند برنامه مشتری (برای اتصالات ورودی یا شمال) یا پردازشگر پیام (برای اتصالات خروجی یا جنوب) باشد. بر اساس تصمیم شما از مرحله 1، یک سرور می تواند Edge Router (برای اتصالات ورودی یا شمال) یا سرور Backend (برای اتصالات خروجی یا جنوب) باشد.
    • اگر کاربر Public Cloud هستید، می‌توانید داده‌های tcpdump را فقط در برنامه مشتری (برای اتصالات ورودی یا شمال) یا سرور پشتیبان (برای اتصالات خروجی یا جنوب) جمع‌آوری کنید، زیرا به Edge دسترسی ندارید. روتر یا پردازشگر پیام 
    tcpdump -i any -s 0 host IP address -w File name
    برای اطلاعات بیشتر در مورد استفاده از دستور tcpdump به داده های tcpdump مراجعه کنید.
  3. داده های tcpdump را با استفاده از ابزار Wireshark یا ابزاری مشابه آنالیز کنید.
  4. در اینجا یک نمونه تجزیه و تحلیل از tcpdump با استفاده از Wireshark آورده شده است:
    • در این مثال، خرابی دست دادن TLS/SSL بین پردازشگر پیام و سرور پشتیبان (اتصال خروجی یا به جنوب) رخ داد.
    • پیام شماره 4 در خروجی tcpdump زیر نشان می دهد که پردازشگر پیام (منبع) یک پیام "Client Hello" را به سرور پشتیبان (مقصد) ارسال کرده است.

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

    • پیام شماره 5 نشان می دهد که سرور باطن پیام "Client Hello" را از پردازشگر پیام تأیید می کند.
    • سرور باطن فورا هشدار مرگبار را ارسال می کند: Close Notify to Message Processor (پیام شماره 6). این بدان معناست که TLS/SSL Handshake ناموفق بوده و اتصال بسته خواهد شد.

    • نگاهی بیشتر به پیام شماره 6 نشان می دهد که علت شکست دست دادن TLS/SSL این است که سرور باطن فقط از پروتکل TLSv1.0 همانطور که در زیر نشان داده شده است پشتیبانی می کند:

    • از آنجایی که بین پروتکل مورد استفاده توسط پردازشگر پیام و سرور باطن یک عدم تطابق وجود دارد، سرور باطن این پیام را ارسال کرد: پیام هشدار مرگبار: بستن اطلاع رسانی .

قطعنامه

پردازشگر پیام بر روی جاوا 8 اجرا می شود و به طور پیش فرض از پروتکل TLSv1.2 استفاده می کند. اگر سرور Backend از پروتکل 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 را اجرا کنید:
    • اگر کاربر Private Cloud هستید، می توانید داده های tcpdump را در سرویس گیرنده یا سرور مربوطه جمع آوری کنید. یک کلاینت می تواند برنامه مشتری (برای اتصالات ورودی یا شمال) یا پردازشگر پیام (برای اتصالات خروجی یا جنوب) باشد. بر اساس تصمیم شما از مرحله 1، یک سرور می تواند Edge Router (برای اتصالات ورودی یا شمال) یا سرور Backend (برای اتصالات خروجی یا جنوب) باشد.
    • اگر کاربر Public Cloud هستید، می‌توانید داده‌های tcpdump را فقط در برنامه مشتری (برای اتصالات ورودی یا شمال) یا سرور پشتیبان (برای اتصالات خروجی یا جنوب) جمع‌آوری کنید، زیرا به Edge دسترسی ندارید. روتر یا پردازشگر پیام 
    tcpdump -i any -s 0 host IP address -w File name
    برای اطلاعات بیشتر در مورد استفاده از دستور tcpdump به داده های tcpdump مراجعه کنید.
  3. داده های tcpdump را با استفاده از ابزار Wireshark یا هر ابزار دیگری که با آن آشنا هستید، تجزیه و تحلیل کنید.
  4. در اینجا نمونه تجزیه و تحلیل خروجی tcpdump با استفاده از Wireshark آمده است:
    • در این مثال، شکست TLS/SSL Handshake بین برنامه Client و روتر Edge (اتصال به شمال) رخ داده است. خروجی tcpdump روی روتر Edge جمع آوری شد.

    • پیام شماره 4 در خروجی tcpdump زیر نشان می دهد که برنامه مشتری (منبع) پیام "Client Hello" را به Edge Router (مقصد) ارسال کرده است.

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

    • پیام شماره 5 نشان می دهد که Edge Router پیام "Client Hello" را از برنامه مشتری تأیید می کند.
    • روتر Edge بلافاصله یک هشدار مرگبار: شکست دست دادن به برنامه مشتری ارسال می کند (پیام شماره 6). این بدان معناست که دست دادن TLS/SSL ناموفق بوده و اتصال بسته خواهد شد.
    • نگاهی بیشتر به پیام شماره 6 اطلاعات زیر را نشان می دهد:
      • روتر Edge از پروتکل TLSv1.2 پشتیبانی می کند. این بدان معنی است که پروتکل بین برنامه مشتری و روتر Edge مطابقت دارد.

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

    • خطا می تواند نتیجه یکی از مشکلات زیر باشد:
      • برنامه مشتری از الگوریتم های مجموعه رمز پشتیبانی شده توسط Edge Router استفاده نمی کند.
      • روتر Edge دارای SNI فعال است، اما برنامه مشتری نام سرور را ارسال نمی کند.
    • پیام شماره 4 در خروجی tcpdump الگوریتم های مجموعه رمز پشتیبانی شده توسط برنامه مشتری را فهرست می کند، همانطور که در زیر نشان داده شده است:

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


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

قطعنامه

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

گواهی نادرست

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

علل احتمالی

علل معمول این مشکل عبارتند از:

علت توضیحات چه کسی می تواند مراحل عیب یابی را انجام دهد
عدم تطابق نام میزبان نام میزبان استفاده شده در URL و گواهی موجود در فروشگاه کلید روتر مطابقت ندارد. به عنوان مثال، اگر نام میزبان مورد استفاده در URL myorg.domain.com باشد، در حالی که گواهی نام میزبان در CN خود به صورت CN=something.domain.com.

 کاربران Edge Private و Public Cloud
زنجیره گواهی ناقص یا نادرست زنجیره گواهی کامل نیست یا صحیح نیست. فقط کاربران Edge Private و Public Cloud
گواهی منقضی شده یا ناشناخته ارسال شده توسط سرور یا مشتری یک گواهی منقضی یا ناشناخته توسط سرور یا کلاینت در اتصال شمال یا جنوب ارسال می شود. کاربران Edge Private Cloud و Edge Public Cloud

عدم تطابق نام میزبان

تشخیص

  1. به نام میزبان استفاده شده در URL که توسط فراخوانی API مدیریت Edge زیر برگردانده شده است توجه کنید:
    curl -v https://myorg.domain.com/v1/getinfo
     به عنوان مثال: 
    curl -v https://api.enterprise.apigee.com/v1/getinfo
  2. CN مورد استفاده در گواهی ذخیره شده در فروشگاه کلید خاص را دریافت کنید. برای دریافت جزئیات گواهی می توانید از API های مدیریت Edge زیر استفاده کنید:
    1. نام گواهی را در فروشگاه کلید دریافت کنید :

      اگر کاربر Private Cloud هستید، از مدیریت API به صورت زیر استفاده کنید:
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      اگر کاربر Public Cloud هستید، از مدیریت API به صورت زیر استفاده کنید: 
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
    2. با استفاده از Edge management API جزئیات گواهی را در keystore دریافت کنید.

      اگر کاربر خصوصی Cloud هستید: 
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      اگر کاربر Public Cloud هستید: 
      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.

      از آنجایی که نام میزبان استفاده شده در URL درخواست API (به مرحله شماره 1 در بالا مراجعه کنید) و نام موضوع در گواهی مطابقت ندارند، با شکست دست دادن TLS/SSL مواجه می شوید.

قطعنامه

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

  • گواهی نامه ای دریافت کنید (اگر قبلاً آن را ندارید) که در آن CN موضوع دارای یک گواهی عام است، سپس زنجیره گواهی کامل جدید را در فروشگاه کلید آپلود کنید. به عنوان مثال: 
    "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",
  • یک گواهی (اگر قبلاً آن را ندارید) با موضوع CN موجود دریافت کنید، اما از your-org استفاده کنید. your-domain به عنوان نام جایگزین موضوع، سپس زنجیره کامل گواهی را در فروشگاه کلید آپلود کنید.

مراجع

فروشگاه‌های کلیدی و Truststores

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

تشخیص

  1. CN مورد استفاده در گواهی ذخیره شده در فروشگاه کلید خاص را دریافت کنید. برای دریافت جزئیات گواهی می توانید از API های مدیریت Edge زیر استفاده کنید:
    1. نام گواهی را در فروشگاه کلید دریافت کنید :

      اگر کاربر خصوصی Cloud هستید: 
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      اگر کاربر Public Cloud هستید: 
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
    2. جزئیات گواهی را در فروشگاه کلید دریافت کنید:

      اگر کاربر خصوصی Cloud هستید: 
      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      اگر کاربر Public Cloud هستید: 
      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
    3. گواهینامه و زنجیره آن را اعتبارسنجی کنید و تأیید کنید که به دستورالعمل های ارائه شده در مقاله نحوه عملکرد زنجیره های گواهینامه پایبند است تا مطمئن شوید که یک زنجیره گواهی معتبر و کامل است. اگر زنجیره گواهی ذخیره شده در فروشگاه کلید ناقص یا نامعتبر باشد، در این صورت شاهد شکست دست دادن TLS/SSL هستید.
    4. نمودار زیر یک گواهی نمونه با یک زنجیره گواهی نامعتبر را نشان می دهد که در آن گواهی های میانی و ریشه مطابقت ندارند:

      5. نمونه گواهی میانی و ریشه که صادرکننده و موضوع مطابقت ندارند


قطعنامه

  1. یک گواهی (اگر قبلاً ندارید) دریافت کنید که شامل یک زنجیره گواهی کامل و معتبر باشد.
  2. دستور openssl زیر را برای بررسی صحیح و کامل بودن زنجیره گواهی اجرا کنید: 
    openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert
  3. زنجیره گواهی تایید شده را در فروشگاه کلید آپلود کنید.

گواهی منقضی شده یا ناشناخته ارسال شده توسط سرور یا مشتری

اگر یک گواهی نادرست/منقضی شده توسط سرور/سرویس گیرنده یا در اتصال به شمال یا در اتصال به جنوب ارسال شود، آنگاه طرف دیگر (سرور/سرویس گیرنده) گواهی را رد می کند که منجر به شکست دست دادن TLS/SSL می شود.

تشخیص

  1. تعیین کنید که آیا خطا در اتصال شمال یا جنوب رخ داده است. برای راهنمایی بیشتر در مورد این تعیین، به تعیین منبع مشکل مراجعه کنید.
  2. برای جمع آوری اطلاعات بیشتر، ابزار tcpdump را اجرا کنید:
    • اگر کاربر Private Cloud هستید، می توانید داده های tcpdump را در سرویس گیرنده یا سرور مربوطه جمع آوری کنید. یک کلاینت می تواند برنامه مشتری (برای اتصالات ورودی یا شمال) یا پردازشگر پیام (برای اتصالات خروجی یا جنوب) باشد. بر اساس تصمیم شما از مرحله 1، یک سرور می تواند Edge Router (برای اتصالات ورودی یا شمال) یا سرور Backend (برای اتصالات خروجی یا جنوب) باشد.
    • اگر کاربر Public Cloud هستید، می‌توانید داده‌های tcpdump را فقط در برنامه مشتری (برای اتصالات ورودی یا شمال) یا سرور پشتیبان (برای اتصالات خروجی یا جنوب) جمع‌آوری کنید، زیرا به Edge دسترسی ندارید. روتر یا پردازشگر پیام 
    tcpdump -i any -s 0 host IP address -w File name
    برای اطلاعات بیشتر در مورد استفاده از دستور tcpdump به داده های tcpdump مراجعه کنید.
  3. داده های tcpdump را با استفاده از Wireshark یا یک ابزار مشابه تجزیه و تحلیل کنید.
  4. از خروجی tcpdump ، میزبان (کلاینت یا سرور) را که گواهی را در مرحله تأیید رد می کند، تعیین کنید.
  5. می توانید گواهی ارسال شده از طرف دیگر را از خروجی tcpdump بازیابی کنید، مشروط بر اینکه داده ها رمزگذاری نشده باشند. این برای مقایسه اینکه آیا این گواهی با گواهی موجود در Truststore مطابقت دارد، مفید خواهد بود.
  6. نمونه tcpdump برای ارتباط SSL بین پردازشگر پیام و سرور باطن بررسی کنید.

    نمونه tcpdump خطای ناشناخته گواهی را نشان می دهد


    1. پردازشگر پیام (مشتری) "Client Hello" را به سرور باطن (سرور) در پیام شماره 59 ارسال می کند.
    2. سرور باطن "Server Hello" را در پیام شماره 61 به پردازشگر پیام ارسال می کند.
    3. آنها به طور متقابل پروتکل و الگوریتم های مجموعه رمز استفاده شده را تأیید می کنند.
    4. سرور باطن پیام گواهی و سرور Hello Done را در پیام شماره 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 handshake است.
  9. اگر گواهی ارسال شده توسط سرور/کلینت منقضی شده باشد، مشتری/سرور گیرنده گواهی را رد می کند و پیام هشدار زیر را در tcpdump مشاهده می کنید:

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

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

قطعنامه

برای حل مشکل شناسایی‌شده در مثال بالا، گواهی سرور پشتیبان معتبر را در قسمت امن در پردازشگر پیام آپلود کنید.

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

علت توضیحات قطعنامه
گواهی منقضی شده شمال
  • گواهی ذخیره شده در فروشگاه کلید روتر منقضی شده است.
  • گواهی ذخیره شده در فروشگاه کلید برنامه مشتری منقضی شده است (SSL دو طرفه).
 یک گواهی جدید و زنجیره کامل آن را در فروشگاه کلید در میزبان مناسب آپلود کنید.
جنوب
  • گواهی ذخیره شده در فروشگاه کلید سرور هدف منقضی شده است.
  • گواهی ذخیره شده در فروشگاه کلید پردازشگر پیام منقضی شده است (SSL دو طرفه).
 یک گواهی جدید و زنجیره کامل آن را در فروشگاه کلید در میزبان مناسب آپلود کنید.
گواهی نامعلوم شمال
  • گواهی ذخیره شده در Truststore برنامه مشتری با گواهی روتر مطابقت ندارد.
  • گواهی ذخیره شده در Truststore روتر با گواهی برنامه مشتری (SSL 2 طرفه) مطابقت ندارد.
 گواهی معتبر را در Truststore در میزبان مناسب آپلود کنید.
جنوب
  • گواهی ذخیره شده در Truststore سرور مورد نظر با گواهی پردازشگر پیام مطابقت ندارد.
  • گواهی ذخیره شده در انبار اعتماد پردازنده پیام با گواهی سرور هدف (SSL دو طرفه) مطابقت ندارد.
 گواهی معتبر را در Truststore در میزبان مناسب آپلود کنید.

سرور فعال 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 را اجرا کنید و سعی کنید به نام میزبان سرور مربوطه (روتر Edge یا سرور باطن) با عبور نام سرور مانند شکل زیر متصل شوید: 
    openssl s_client -connect hostname:port -servername hostname
  3. اگر در مرحله شماره 1 با شکست دست دادن مواجه شدید یا در مرحله 1 و 2 گواهینامه های متفاوتی دریافت کردید، این نشان می دهد که سرور مشخص شده SNI فعال است.

هنگامی که متوجه شدید که سرور SNI فعال است، می توانید مراحل زیر را دنبال کنید تا بررسی کنید که آیا خرابی دست دادن TLS/SSL به دلیل عدم امکان ارتباط کلاینت با سرور SNI است یا خیر.

تشخیص

  1. تعیین کنید که آیا خطا در اتصال شمال یا جنوب رخ داده است. برای راهنمایی بیشتر در مورد این تعیین، به تعیین منبع مشکل مراجعه کنید.
  2. برای جمع آوری اطلاعات بیشتر، ابزار tcpdump را اجرا کنید:
    • اگر کاربر Private Cloud هستید، می توانید داده های tcpdump را در سرویس گیرنده یا سرور مربوطه جمع آوری کنید. یک کلاینت می تواند برنامه مشتری (برای اتصالات ورودی یا شمال) یا پردازشگر پیام (برای اتصالات خروجی یا جنوب) باشد. بر اساس تصمیم شما از مرحله 1، یک سرور می تواند Edge Router (برای اتصالات ورودی یا شمال) یا سرور Backend (برای اتصالات خروجی یا جنوب) باشد.
    • اگر کاربر Public Cloud هستید، می‌توانید داده‌های tcpdump را فقط در برنامه مشتری (برای اتصالات ورودی یا شمال) یا سرور پشتیبان (برای اتصالات خروجی یا جنوب) جمع‌آوری کنید، زیرا به Edge دسترسی ندارید. روتر یا پردازشگر پیام 
    tcpdump -i any -s 0 host IP address -w File name
    برای اطلاعات بیشتر در مورد استفاده از دستور tcpdump به داده های tcpdump مراجعه کنید.
  3. خروجی tcpdump را با استفاده از Wireshark یا ابزاری مشابه آنالیز کنید.
  4. در اینجا نمونه تجزیه و تحلیل tcpdump با استفاده از Wireshark آمده است:
    1. در این مثال، شکست دست دادن TLS/SSL بین پردازشگر پیام لبه و سرور باطن (اتصال به سمت جنوب) رخ داده است.
    2. پیام شماره 4 در خروجی tcpdump زیر نشان می دهد که پردازشگر پیام (منبع) یک پیام "Client Hello" را به سرور پشتیبان (مقصد) ارسال کرده است.

    3. انتخاب پیام "Client Hello" نشان می دهد که پردازشگر پیام از پروتکل TLSv1.2 استفاده می کند.

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

    7. این خطا ممکن است به یکی از دلایل زیر رخ دهد:
      • پردازشگر پیام از الگوریتم های مجموعه رمز پشتیبانی شده توسط سرور باطن استفاده نمی کند.
      • سرور Backend SNI فعال است، اما برنامه مشتری نام سرور را ارسال نمی کند.
    8. پیام شماره 3 (Client Hello) را در خروجی tcpdump با جزئیات بیشتر مرور کنید. توجه داشته باشید که Extension: 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. اگر بیش از یک پردازشگر پیام دارید، مراحل 1 تا 4 را در همه پردازشگرهای پیام تکرار کنید.

اگر نمی توانید علت خرابی TLS/SSL Handshake را تعیین کنید و مشکل را برطرف کنید یا به کمک بیشتری نیاز دارید، با پشتیبانی Apigee Edge تماس بگیرید. جزئیات کامل مشکل را همراه با خروجی tcpdump به اشتراک بگذارید.