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

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

علامت

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

پیام‌های خطا 

HTTP/1.1 503 Service Unavailable

همچنین می‌توانید این پیام خطا را هنگام بروز خطای TLS/SSL handshake مشاهده کنید:

Received fatal alert: handshake_failure

علل احتمالی

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

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

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

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

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

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

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

تشخیص

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

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

    • پیام شماره ۵ نشان می‌دهد که سرور backend پیام "Client Hello" را از پردازنده پیام تأیید می‌کند.
    • سرور backend بلافاصله Fatal Alert : Close Notify را به پردازشگر پیام (پیام شماره ۶) ارسال می‌کند. این به این معنی است که TLS/SSL Handshake ناموفق بوده و اتصال قطع خواهد شد.

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

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

وضوح تصویر

پردازشگر پیام (Message Processor) روی جاوا ۸ اجرا می‌شود و به طور پیش‌فرض از پروتکل TLSv1.2 استفاده می‌کند. اگر سرور backend از پروتکل TLSv1.2 پشتیبانی نمی‌کند، می‌توانید یکی از مراحل زیر را برای حل این مشکل انجام دهید:

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

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

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

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

      • با این حال، روتر Edge همچنان هشدار Fatal Alert: Handshake Failure را همانطور که در تصویر زیر نشان داده شده است، به برنامه کلاینت ارسال می‌کند:

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

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


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

وضوح تصویر

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

گواهی نادرست

اگر گواهی‌های نادرستی در keystore/truststore، چه در اتصال ورودی (شمال) و چه در اتصال خروجی (جنوب) در Apigee Edge، داشته باشید، خطای handshake 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 و گواهی موجود در keystore روتر با هم مطابقت نداشته باشند. برای مثال، اگر نام میزبان استفاده شده در 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 مورد استفاده در گواهی را که در keystore خاص ذخیره شده است، دریافت کنید. می‌توانید از APIهای مدیریت Edge زیر برای دریافت جزئیات گواهی استفاده کنید:
    1. نام گواهی را در فروشگاه کلید دریافت کنید :

      اگر کاربر Private Cloud هستید، از Management 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 مدیریت Edge، جزئیات گواهی را در keystore دریافت کنید.

      اگر شما یک کاربر فضای ابری خصوصی هستید: 
      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.

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

وضوح تصویر

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

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

منابع

فروشگاه‌های کلیدی و فروشگاه‌های معتمد

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

تشخیص

  1. CN مورد استفاده در گواهی را که در keystore خاص ذخیره شده است، دریافت کنید. می‌توانید از APIهای مدیریت Edge زیر برای دریافت جزئیات گواهی استفاده کنید:
    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. گواهی و زنجیره آن را اعتبارسنجی کنید و تأیید کنید که از دستورالعمل‌های ارائه شده در مقاله « زنجیره‌های گواهی چگونه کار می‌کنند» پیروی می‌کند تا از معتبر و کامل بودن زنجیره گواهی اطمینان حاصل شود. اگر زنجیره گواهی ذخیره شده در keystore ناقص یا نامعتبر باشد، خطای TLS/SSL handshake را مشاهده خواهید کرد.
    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، روتر لبه (برای اتصالات ورودی یا شمالی) یا سرور backend (برای اتصالات خروجی یا جنوبی) باشد.
    • اگر شما یک کاربر ابر عمومی هستید، می‌توانید داده‌های tcpdump را فقط در برنامه کلاینت (برای اتصالات ورودی یا شمالی) یا سرور backend (برای اتصالات خروجی یا جنوبی) جمع‌آوری کنید، زیرا به روتر لبه یا پردازنده پیام دسترسی ندارید. 
    tcpdump -i any -s 0 host IP address -w File name
    برای اطلاعات بیشتر در مورد استفاده از دستور tcpdump به داده‌های tcpdump مراجعه کنید.
  3. داده‌های tcpdump را با استفاده از Wireshark یا ابزار مشابه تجزیه و تحلیل کنید.
  4. از خروجی tcpdump ، میزبان (کلاینت یا سرور) که گواهی را در مرحله تأیید رد می‌کند، تعیین کنید.
  5. شما می‌توانید گواهی ارسال شده از طرف دیگر را از خروجی tcpdump بازیابی کنید، مشروط بر اینکه داده‌ها رمزگذاری نشده باشند. این کار برای مقایسه اینکه آیا این گواهی با گواهی موجود در truststore مطابقت دارد یا خیر، مفید خواهد بود.
  6. نمونه tcpdump برای ارتباط SSL بین پردازنده پیام و سرور backend بررسی کنید.

    نمونه‌ای از tcpdump که خطای نامشخص گواهی را نشان می‌دهد


    1. پردازشگر پیام (کلاینت) عبارت "Client Hello" را به سرور backend (سرور) در پیام شماره ۵۹ ارسال می‌کند.
    2. سرور backend عبارت "Server Hello" را به پردازشگر پیام در پیام شماره ۶۱ ارسال می‌کند.
    3. آنها متقابلاً پروتکل و الگوریتم‌های مجموعه رمز مورد استفاده را اعتبارسنجی می‌کنند.
    4. سرور backend پیام Certificate و Server Hello Done را به Message Processor در پیام شماره ۶۸ ارسال می‌کند.
    5. پردازشگر پیام، هشدار مهلک "شرح: گواهی‌نامه نامشخص" را در پیام شماره ۷۰ ارسال می‌کند.
    6. با نگاهی دقیق‌تر به پیام شماره ۷۰، هیچ جزئیات اضافی به جز پیام هشدار که در زیر نشان داده شده است، وجود ندارد:


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

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

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

  10. تأیید کنید که گواهی موجود در keystore میزبان مربوطه منقضی شده باشد.

وضوح تصویر

برای حل مشکل شناسایی شده در مثال بالا، گواهی معتبر سرور backend را در trustore روی Message Processor آپلود کنید.

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

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

سرور فعال SNI

خطای TLS/SSL handshake می‌تواند زمانی رخ دهد که کلاینت با یک سرور فعال‌شده با SNI در حال ارتباط است، اما SNI کلاینت فعال نیست. این اتفاق می‌تواند در اتصال Northbound یا Southbound در Edge رخ دهد.

ابتدا باید نام میزبان و شماره پورت سرور مورد استفاده را شناسایی کنید و بررسی کنید که آیا SNI فعال است یا خیر.

شناسایی سرور فعال‌شده با SNI

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

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

تشخیص

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

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

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

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

    9. این تأیید می‌کند که پردازنده پیام، server_name را به سرور backend دارای SNI ارسال نکرده است.
    10. این دلیل شکست اتصال TLS/SSL و دلیلی است که سرور backend ، هشدار نهایی: شکست اتصال را به پردازنده پیام ارسال می‌کند.
  5. تأیید کنید که jsse.enableSNIExtension property در system.properties در Message Processor روی false تنظیم شده باشد تا تأیید شود که Message Processor برای برقراری ارتباط با سرور دارای 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 Handshake را تعیین کرده و مشکل را برطرف کنید یا به کمک بیشتری نیاز دارید، با پشتیبانی Apigee Edge تماس بگیرید. جزئیات کامل مشکل را به همراه خروجی tcpdump به اشتراک بگذارید.