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 گواهی سرور مورد نظر را تأیید می‌کند و اگر مورد اعتماد نباشد خطای زمان اجرا ایجاد می‌کند. کاربران 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 به احتمال زیاد یک گواهی خودامضا از سرور هدف دریافت کرده است. برای تایید این موضوع مراحل زیر را انجام دهید:

  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 در نظر بگیرید.

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

    1. اگر از docker استفاده می کنید ، به استفاده از CA که مورد اعتماد Node.js نیست مراجعه کنید
    2. در غیر این صورت، یک متغیر محیطی به نام NODE_EXTRA_CA_CERTS صادر کنید که به فایل CA ریشه اشاره دارد.

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

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

    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، 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' }

تشخیص

  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، log > level به info تغییر دهید.
  • فایل پیکربندی : پیکربندی اصلی Edge Microgateway در فایل YAML در پوشه پیش‌فرض Edge Microgateway، $HOME/.edgemicro قرار دارد. یک فایل پیکربندی پیش‌فرض به نام default.yaml و سپس یک فایل برای هر محیط ORG - ENV - config.yaml وجود دارد. این فایل را به طور کامل برای org و env تحت تاثیر آپلود کنید.

    اسناد مرجع

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