درحال مشاهده اسناد Apigee Edge هستید.
به
اسناد Apigee X بروید. اطلاعات
نشانه
برنامه مشتری کد پاسخ HTTP 502 را با پیام
Bad Gateway بهعنوان پاسخ برای فراخوانیهای API در Edge Microgateway دریافت میکند.
یا اینکه سرپرست هنگام اجرای فرمان self signed certificate in certificate
chain
edgemicro configure با خطا مواجه خواهد شد.
پیام خطا
کارخواه پیام پاسخ زیر را خواهد دید:
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 گواهینامه سرور مقصد را درستیسنجی میکند و اگر معتبر نباشد، خطای زمان اجرا ایجاد میکند. | کاربران «فضای ابری خصوصی و عمومی لبهای» |
| «سرور مدیریت Apigee Edge» از گواهینامه خودامضا استفاده میکند | هنگام پیکربندی Edge Microgateway برای اولینبار، این دروازه ازطریق «امنیت لایه انتقال» به 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 درنظر بگیرید.
گزینه ۱: تنظیم دارایی سیستم برای اجازه دادن به Edge Microgateway برای اعتماد به همه گواهینامهها
- اگر از docker استفاده میکنید، به استفاده از «مرجع گواهی» که Node.js به آن اعتماد ندارد مراجعه کنید
درغیراینصورت، متغیر محیطی بهنام
NODE_EXTRA_CA_CERTSصادر کنید، که به فایل «مرجع صدور گواهی» ریشه اشاره میکند.این موضوع در وبسایت رسمی Node.js مستند شده است.
گزینه ۲: فایل پیکربندی Edge Microgateway YAML را پیکربندی کنید تا به آن گواهی خاص برای آن سرور هدف اعتماد کند
- مطمئن شوید که گواهی (یا زنجیره) سرور مقصد را در قالب PEM دارید. برای تبدیل قالبهای گواهی دیگر به PEM، دستورالعملهای تبدیل گواهیها به قالب پشتیبانیشده را دنبال کنید.
اگر زنجیره گواهینامه وجود دارد، مطمئن شوید که گواهینامهها به ترتیب صحیح قرار دارند. گواهینامه نهایی همیشه باید اول باشد، سپس گواهینامه واسطه، و در آخر گواهینامه ریشه. توضیحات بیشتری درباره این موضوع در اعتبارسنجی زنجیره گواهینامه وجود دارد.
در مثال زیر، فایل «مرجع صدور گواهی» مطمئن را برای
untrusted-root.badssl.comپیکربندی کردهایم.edgemicro: ... targets: - host: 'untrusted-root.badssl.com' ssl: client ca: /opt/apigee/certs/untrusted-root.pem
دستورالعملهای پیکربندی این مورد نیز در ویدیو واحد Edge Microgateway - پیکربندی «امنیت لایه انتقال» یکطرفه و دوطرفه Southbound پوشش داده شده است. برای اطلاعات بیشتر، به پیکربندی SSL در سرور Edge Microgateway مراجعه کنید.
اگر مشکل همچنان ادامه داشت، به باید اطلاعات تشخیصی را جمعآوری کنید بروید.
دلیل: «سرور مدیریت Apigee Edge» از گواهی خودامضا استفاده میکند
وقتی Edge Microgateway برای اولینبار راهاندازی میشود، یکی از فرمانهایی که باید اجرا کنید
edgemicro configure یا edgemicro private configure است. این فرمان
خوشه را راهاندازی میکند و برای بارگیری اطلاعات موردنیاز با Apigee Edge تماس میگیرد.
برای Edge Private Cloud، نشانی وب «سرور مدیریت» با آرگومان -m تعیین میشود.
اگر «امنیت لایه انتقال» را برای «سرور مدیریت» فعال کردهاید، 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) ممکن است گواهینامه «امنیت لایه انتقال» خودامضایی برگرداند. - احتمالاً سرپرست سیستم 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 استفاده میکنید، به استفاده از «مرجع گواهی» که 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وجود دارد. این فایل را بهطور کامل برای سازمان و محیط تحتتأثیر قرارگرفته بارگذاری کنید.اسناد مرجع