502 Bad Gateway - گواهی نامه خود امضا شده در زنجیره

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

علامت

برنامه‌ی کلاینت، کد پاسخ HTTP برابر با 502 را به همراه پیام Bad Gateway به عنوان پاسخی برای فراخوانی‌های API در Edge Microgateway دریافت می‌کند.

از طرف دیگر، مدیر سیستم هنگام اجرای دستور edgemicro configure با خطای self signed certificate in certificate chain مواجه خواهد شد.

پیام خطا

کلاینت پیام پاسخ زیر را مشاهده خواهد کرد:

HTTP/1.1 502 Bad Gateway

دو نمونه رایج از پاسخ‌های خطا عبارتند از:

{"message":"self signed certificate in certificate chain","code":"SELF_SIGNED_CERT_IN_CHAIN"}

{"message":"self signed certificate","code":"DEPTH_ZERO_SELF_SIGNED_CERT"}

از طرف دیگر، این خطا می‌تواند هنگام اجرای edgemicro configure رخ دهد:

{ Error: self signed certificate in certificate chain
at TLSSocket.onConnectSecure (_tls_wrap.js:1051:34)
at TLSSocket.emit (events.js:189:13)
at TLSSocket._finishInit (_tls_wrap.js:633:8) code: 'SELF_SIGNED_CERT_IN_CHAIN' }

علل احتمالی

علت: سرور هدف یک گواهی خودامضا ارائه می‌دهد

اگر یک گواهی خودامضا توسط سرور هدف در اتصال به سمت جنوب ارائه شود، Edge Microgateway به طور پیش‌فرض این خطا را ایجاد می‌کند زیرا به گواهی‌های خودامضا اعتماد ندارد.

تشخیص

ممکن است خطای زیر را در گزارش‌ها ( /var/tmp/edgemicro-`hostname`- *.log ) مشاهده کنید:

2021-05-18T10:52:46.425Z [error][0:8000][1][gsc][test][edgemicro_badtargethost][][][2db53f80-
b7c7-11eb-9abe-05b6297863f1][microgateway-core][][GET][502][self signed certificate in certificate
chain][SELF_SIGNED_CERT_IN_CHAIN][]

کد خطای SELF_SIGNED_CERT_IN_CHAIN ​​نشان می‌دهد که Edge Microgateway به احتمال زیاد یک گواهی خودامضا از سرور هدف دریافت کرده است. برای تأیید این موضوع، مراحل زیر را انجام دهید:

1. برای تأیید زنجیره گواهی سرور هدف، دستور openssl زیر را اجرا کنید:

   echo | openssl s_client -connect TARGET_SERVER_HOSTNAME:PORT -servername TARGET_SERVER_HOSTNAME | openssl x509 -noout
   

2. اگر زنجیره گواهی سرور هدف واقعاً خودامضا باشد، پس دلیل مشکل همین است.

   در مثال زیر، توجه کنید که سرور هدف یک گواهی خودامضا ارائه می‌دهد:

   echo | openssl s_client -connect untrusted-root.badssl.com:443 -servername untrusted-root.badssl.com | openssl x509 -noout
   

   depth=1 C = US, ST = California, L = San Francisco, O = BadSSL, CN = BadSSL Untrusted Root Certificate Authority
   verify error:num=19:self signed certificate in certificate chain
   verify return:0
   DONE

وضوح تصویر

1. با تیمی که مالک سرور هدف است همکاری کنید تا یک گواهی TLS مناسب که توسط یک مرجع صدور گواهی (CA) معتبر امضا شده باشد، تهیه کنید.

2. اگر این امکان وجود ندارد، یکی از گزینه‌های زیر را برای مجاز کردن گواهی‌های خودامضا در Edge Microgateway در نظر بگیرید.

   گزینه شماره ۱: تنظیم یک ویژگی سیستمی برای اجازه دادن به Edge Microgateway برای اعتماد به همه گواهینامه‌ها

   1. اگر از docker استفاده می‌کنید ، به «استفاده از CA که توسط Node.js قابل اعتماد نیست» مراجعه کنید.

   2. در غیر این صورت، یک متغیر محیطی به نام NODE_EXTRA_CA_CERTS صادر کنید که به فایل CA ریشه اشاره می‌کند.

      این در وب‌سایت رسمی Node.js مستند شده است.

   گزینه شماره ۲: فایل پیکربندی YAML مربوط به Edge Microgateway را طوری پیکربندی کنید که به آن گواهی خاص برای آن سرور هدف اعتماد کند.

   1. مطمئن شوید که گواهی (یا زنجیره) سرور هدف را با فرمت PEM دارید. برای تبدیل سایر فرمت‌های گواهی به PEM، دستورالعمل‌های موجود در بخش «تبدیل گواهی‌ها به فرمت پشتیبانی‌شده» را دنبال کنید.

   2. اگر زنجیره گواهی وجود دارد، مطمئن شوید که گواهی‌ها به ترتیب صحیح هستند. گواهی برگ همیشه باید اول باشد، پس از آن گواهی میانی و سپس گواهی ریشه. توضیحات بیشتر در این مورد در بخش اعتبارسنجی زنجیره گواهی‌ها آمده است.

      در مثال زیر، فایل CA مورد اعتماد را برای untrusted-root.badssl.com پیکربندی کرده‌ایم.

      edgemicro:
      ...
      targets:
        - host: 'untrusted-root.badssl.com'
          ssl:
            client
              ca: /opt/apigee/certs/untrusted-root.pem

   دستورالعمل‌های پیکربندی این مورد نیز در ویدیوی « ماژول Edge Microgateway - پیکربندی TLS یک طرفه و دو طرفه Southbound» پوشش داده شده است. برای اطلاعات بیشتر به «پیکربندی SSL روی سرور Edge Microgateway» مراجعه کنید.

اگر مشکل همچنان ادامه داشت، به «باید اطلاعات تشخیصی جمع‌آوری شود» بروید.

علت: سرور مدیریت Apigee Edge از یک گواهی خودامضا استفاده می‌کند

وقتی Edge Microgateway برای اولین بار راه‌اندازی می‌شود، یکی از دستوراتی که باید اجرا کنید edgemicro configure یا edgemicro private configure است. این دستور کلاستر را بوت‌استرپ می‌کند و برای دانلود اطلاعات مورد نیاز با Apigee Edge تماس می‌گیرد.

برای Edge Private Cloud، آدرس اینترنتی سرور مدیریت توسط آرگومان -m تعیین می‌شود. اگر TLS را برای سرور مدیریت فعال کرده باشید، Edge Microgateway تلاش می‌کند گواهی ارائه شده توسط سرور مدیریت را تأیید کند.

یک نمونه از دستور edgemicro configure برای Edge Private Cloud به شرح زیر است:

edgemicro private configure -u <username> -p <password> -o apigee -e dev -v secure -r https://apigee-dev.net -m https://management.apigee-dev.net:8443

اگر سرور مدیریت با یک گواهی خودامضا پیکربندی شده باشد، در خروجی کنسول خطای زیر را دریافت خواهید کرد.

{ Error: self signed certificate in certificate chain
at TLSSocket.onConnectSecure (_tls_wrap.js:1051:34)
at TLSSocket.emit (events.js:189:13)
at TLSSocket._finishInit (_tls_wrap.js:633:8) code: 'SELF_SIGNED_CERT_IN_CHAIN' }

تشخیص

1. در این حالت، سرور مدیریت ( management.apigee-dev.net ) ممکن است یک گواهی TLS خودامضا شده را برگرداند.
2. احتمالاً مدیر سیستم Apigee Edge شما این گواهی را ارائه داده و یک کپی از آن را دارد.
3. در غیر این صورت، دستور زیر را برای دریافت اطلاعات مربوط به گواهی اجرا کنید:

   echo | openssl s_client -connect management.apigee-dev.net:8443 -servername management.apigee-dev.net | openssl x509 -noout
   

4. اگر سرور مدیریت دارای گواهی خودامضا باشد، دلیل این مشکل همین است.

وضوح تصویر

1. با تیمی که مالک سرور هدف است همکاری کنید تا یک گواهی TLS مناسب که توسط یک مرجع صدور گواهی (CA) معتبر امضا شده باشد، تهیه کنید.

2. اگر این امکان وجود ندارد، موارد زیر را برای مجاز کردن گواهی‌های خودامضا در Edge Microgateway انجام دهید.

3. یک ویژگی سیستمی تنظیم کنید تا Edge Microgateway به همه گواهینامه‌ها اعتماد کند.
4. اگر از docker استفاده می‌کنید ، به «استفاده از CA که توسط Node.js قابل اعتماد نیست» مراجعه کنید.
5. در غیر این صورت، یک متغیر محیطی به نام NODE_EXTRA_CA_CERTS صادر کنید که به فایل CA ریشه اشاره می‌کند. این موضوع در وب‌سایت رسمی Node.js مستند شده است.

باید اطلاعات تشخیصی جمع‌آوری کند

اگر مشکل حتی پس از دنبال کردن دستورالعمل‌های بالا ادامه داشت، اطلاعات تشخیصی زیر را جمع‌آوری کرده و سپس با پشتیبانی Apigee Edge تماس بگیرید:

• فایل‌های لاگ : پوشه پیش‌فرض /var/tmp است، اما ممکن است در فایل اصلی config.yaml ( logging > dir parameter ) بازنویسی شود. توصیه می‌شود قبل از ارائه فایل‌های لاگ به Apigee Edge Support، log > level را به info تغییر دهید.
• فایل پیکربندی : پیکربندی اصلی Edge Microgateway در فایل YAML در پوشه پیش‌فرض Edge Microgateway، $HOME/.edgemicro ، قرار دارد. یک فایل پیکربندی پیش‌فرض به نام default.yaml و سپس یکی برای هر محیط ORG - ENV - config.yaml وجود دارد. این فایل را به طور کامل برای org و env آسیب‌دیده بارگذاری کنید.

  اسناد مرجع

  رابط کاربری Edge را طوری پیکربندی کنید که از TLS برای دسترسی به Edge API استفاده کند.