شما در حال مشاهده اسناد 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 گواهی سرور مورد نظر را تأیید میکند و اگر مورد اعتماد نباشد خطای زمان اجرا ایجاد میکند. | کاربران Edge Public و Private Cloud |
سرور مدیریت Apigee Edge از یک گواهی امضا شده استفاده می کند | هنگام پیکربندی Edge Microgateway برای اولین بار، از طریق TLS به Apigee Edge متصل می شود تا بوت استرپ شود. اگر Edge یک گواهی خودامضا ارائه کند، این مورد ناموفق خواهد بود. | کاربران Edge Private Cloud |
علت: سرور هدف یک گواهی خودامضا ارائه می دهد
اگر یک گواهی خودامضا شده توسط سرور هدف در اتصال به جنوب ارائه شود، 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 به احتمال زیاد یک گواهی خودامضا از سرور هدف دریافت کرده است. برای تایید این موضوع مراحل زیر را انجام دهید:
- دستور
openssl
زیر را برای تأیید زنجیره گواهی سرور مورد نظر اجرا کنید:echo | openssl s_client -connect TARGET_SERVER_HOSTNAME:PORT -servername TARGET_SERVER_HOSTNAME | openssl x509 -noout
اگر زنجیره گواهی سرور هدف واقعاً خود امضا شده باشد، دلیل این مشکل همین است.
در مثال زیر، توجه داشته باشید که سرور مورد نظر یک گواهی امضا شده ارائه می دهد:
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
قطعنامه
- با تیم صاحب سرور هدف کار کنید تا یک گواهی TLS مناسب امضا شده توسط یک مرجع گواهی معتبر (CA) تهیه کنید.
اگر این امکان وجود ندارد، یکی از گزینههای زیر را برای اجازه دادن به گواهیهای خودامضا در Edge Microgateway در نظر بگیرید.
گزینه شماره 1: یک ویژگی سیستم را تنظیم کنید تا به Edge Microgateway اجازه دهد به همه گواهی ها اعتماد کند
- اگر از docker استفاده می کنید ، به استفاده از CA که مورد اعتماد Node.js نیست مراجعه کنید
در غیر این صورت، یک متغیر محیطی به نام
NODE_EXTRA_CA_CERTS
صادر کنید که به فایل CA ریشه اشاره دارد.این در وب سایت رسمی Node.js مستند شده است.
گزینه شماره 2: فایل پیکربندی Edge Microgateway YAML را پیکربندی کنید تا به آن گواهی خاص برای آن سرور مورد نظر اعتماد کند.
- اطمینان حاصل کنید که گواهی (یا زنجیره) سرور مورد نظر را در قالب PEM دارید. برای تبدیل سایر قالبهای گواهی به PEM، دستورالعملهای موجود در تبدیل گواهیها به فرمت پشتیبانی شده را دنبال کنید.
اگر زنجیره گواهی وجود دارد، اطمینان حاصل کنید که گواهینامه ها به ترتیب صحیح هستند. گواهی برگ همیشه باید ابتدا باشد و پس از آن گواهی میانی و سپس گواهی ریشه باشد. توضیح بیشتری در این مورد در زنجیره گواهی اعتبار سنجی وجود دارد.
در مثال زیر، فایل 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، URL سرور مدیریت با آرگومان -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' }
تشخیص
- در این مورد، سرور مدیریت (
management.apigee-dev.net
) ممکن است گواهی TLS خود امضا شده را برگرداند. - به احتمال زیاد مدیر سیستم Apigee Edge شما گواهی را ارائه کرده و یک کپی از آن را دارد.
- در غیر این صورت، دستور زیر را برای دریافت اطلاعات مربوط به گواهی اجرا کنید:
echo | openssl s_client -connect management.apigee-dev.net:8443 -servername management.apigee-dev.net | openssl x509 -noout
- اگر سرور مدیریت دارای گواهینامه خود امضا شده باشد، دلیل این مشکل همین است.
قطعنامه
- با تیم صاحب سرور هدف کار کنید تا یک گواهی TLS مناسب امضا شده توسط یک مرجع گواهی معتبر (CA) تهیه کنید.
اگر این امکان پذیر نیست، برای اجازه دادن به گواهینامه های خودامضا در Edge Microgateway، موارد زیر را انجام دهید.
- یک ویژگی سیستم را تنظیم کنید تا به Edge Microgateway اجازه دهید به همه گواهی ها اعتماد کند.
- اگر از docker استفاده می کنید ، به استفاده از CA که مورد اعتماد Node.js نیست مراجعه کنید.
- در غیر این صورت، یک متغیر محیطی به نام
NODE_EXTRA_CA_CERTS
صادر کنید که به فایل CA ریشه اشاره می کند. این در وب سایت رسمی Node.js مستند شده است.
باید اطلاعات تشخیصی را جمع آوری کرد
اگر حتی پس از پیروی از دستورالعملهای بالا، مشکل همچنان ادامه داشت، اطلاعات تشخیصی زیر را جمعآوری کنید و سپس با پشتیبانی Apigee Edge تماس بگیرید:
- فایلهای گزارش : پوشه پیشفرض
/var/tmp
است اما ممکن است در فایل اصلیconfig.yaml
لغو شود (logging > dir parameter
). توصیه می شود قبل از ارائه فایل های گزارش به پشتیبانی Apigee Edge،log > level
بهinfo
تغییر دهید. - فایل پیکربندی : پیکربندی اصلی Edge Microgateway در فایل YAML در پوشه پیشفرض Edge Microgateway،
$HOME/.edgemicro
قرار دارد. یک فایل پیکربندی پیشفرض به نامdefault.yaml
و سپس یک فایل برای هر محیط ORG - ENV -config.yaml
وجود دارد. این فایل را به طور کامل برای org و env تحت تاثیر آپلود کنید.اسناد مرجع
Edge UI را برای استفاده از TLS برای دسترسی به Edge API پیکربندی کنید