400 درخواست بد - خطای گواهی SSL

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

علامت

برنامه مشتری یک HTTP 400 - پاسخ درخواست بد با پیام " خطای گواهی SSL " دریافت می کند. این خطا معمولاً توسط روتر Edge در راه اندازی TLS دو طرفه ارسال می شود که برای اتصال ورودی به Apigee Edge فعال است.

پیغام خطا

برنامه Client کد پاسخ زیر را دریافت می کند:

HTTP/1.1 400 Bad Request

به دنبال صفحه خطای HTML زیر:

<html>
  <head>
    <title>400 The SSL certificate error</title>
  </head>
  <body bgcolor="white">
    <center> <h1>400 Bad Request</h1>
    </center>
    <center>The SSL certificate error</center>
    <hr>
    <center>nginx</center>
  </body>
</html>

علل احتمالی

دلایل احتمالی این موضوع به شرح زیر است:

علت توضیحات دستورالعمل های عیب یابی قابل اجرا برای
گواهی مشتری منقضی شده گواهی ارسال شده توسط مشتری منقضی شده است. کاربران Edge Private و Public Cloud
گواهی نادرست ارسال شده توسط مشتری اگر گواهی ارسال شده توسط برنامه مشتری با گواهی ذخیره شده در Truststore Router Edge مطابقت نداشته باشد، این خطا ایجاد می شود. کاربران Edge Private و Public Cloud
گواهی ریشه مشتری از دست رفته در Truststore اگر گواهی ریشه امضا شده CA مشتری در Truststore روتر Edge وجود نداشته باشد، این خطا ایجاد می شود. کاربران Edge Private و Public Cloud
گواهینامه های مشتری در روتر Edge بارگیری نشده اند اگر گواهی های کلاینت آپلود شده در Truststore در روتر بارگذاری نشوند، این خطا ایجاد می شود. کاربران Edge Private Cloud

علت: گواهی مشتری منقضی شده است

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

در Edge، TLS دو طرفه در میزبان مجازی پیاده‌سازی می‌شود، جایی که گواهی سرور به Keystore و گواهی مشتری به Truststores اضافه می‌شود.

در هنگام دست دادن TLS اگر مشخص شود که گواهی مشتری منقضی شده است، سرور 400 - درخواست بد را با پیام " خطای گواهینامه SSL " ارسال می کند.

تشخیص

  1. وارد رابط کاربری Edge شوید و پیکربندی میزبان مجازی خاص ( Admin > Virtual Host ) را که درخواست API برای آن انجام شده است مشاهده کنید، یا از Get virtual host API management API برای دریافت تعریف میزبان مجازی خاص استفاده کنید.

    به طور معمول یک میزبان مجازی برای ارتباط دو طرفه TLS به صورت زیر است:

    <VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>api.myCompany.com</HostAlias>
    </HostAliases>
    <Port>443</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <KeyStore>ref://myKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
        <TrustStore>ref://myTruststoreRef</TrustStore>
    </SSLInfo>
</VirtualHost>

  2. مرجع Truststore مورد استفاده در هاست مجازی را تعیین کنید. در مثال بالا، نام مرجع Truststore myTrussttoreRef است.

  3. Truststore که توسط مرجع Truststore به آن اشاره شده است را تعیین کنید.
    1. در رابط کاربری Edge به Admin > Environments > References بروید و نام مرجع Truststore را جستجو کنید.

    2. به نام موجود در ستون Reference برای مرجع خاص Truststore توجه کنید. این نام Truststore شما خواهد بود.

      رابط کاربری Edge فهرستی از مراجع را نشان می دهد
      شکل 1

      در مثال بالا، توجه کنید که myTrussttoreRef ارجاع به myTruststore دارد. بنابراین، نام Truststore myTruststore است.

  4. در Admin > Environments > TLS Keystores در Edge UI، به TLS Keystores بروید و Truststore موجود در مرحله 3 را جستجو کنید.

  5. گواهی را در زیر Truststore خاص (که در مرحله شماره 3 در بالا تعیین شده است) مطابق شکل زیر انتخاب کنید:

    شکل 2

    گواهی با نام مستعار client-cert-markw در مثال بالا، نشان می دهد که منقضی شده است.

  6. بررسی کنید که آیا گواهی منقضی شده است برای گواهی مستعار برای فروشگاه اعتماد شما.
  7. اگر گواهی منقضی نشده است، برای سایر علل به مراحل تشخیص رایج بروید.

قطعنامه

یک گواهی جدید تهیه کنید و گواهی را بارگذاری کنید:

  1. یک Truststore جدید ایجاد کنید، برای مثال myNewTrussttore.
  2. گواهی جدید را در فروشگاه اعتماد تازه ایجاد شده آپلود کنید.

  3. مرجع Trustore مورد استفاده در Virtual Host خاص را تغییر دهید تا با استفاده از مراحل ارائه شده در Modifying a reference به فروشگاه اعتماد جدید اشاره کنید.

    در مثالی که در بالا توضیح داده شد، مرجع myTrussttoreRef را به myNewTruststore اشاره کنید.

مراحل تشخیصی رایج برای سایر علل

  1. برای بررسی این موضوع، باید بسته های TCP/IP را با استفاده از ابزار tcpdump ضبط کنید.
    1. اگر کاربر Private Cloud هستید، می توانید بسته های TCP/IP را در برنامه مشتری یا روتر ضبط کنید.
    2. اگر کاربر Public Cloud هستید، بسته‌های TCP/IP را در برنامه مشتری ضبط کنید.

    3. هنگامی که تصمیم گرفتید کجا می‌خواهید بسته‌های TCP/IP را ضبط کنید، از دستور tcpdump زیر برای گرفتن بسته‌های TCP/IP استفاده کنید:

      tcpdump -i any -s 0 host <IP address> -w <File name>

      توجه: اگر بسته‌های TCP/IP را روی روتر می‌گیرید، از آدرس IP عمومی برنامه مشتری در دستور tcpdump استفاده کنید.

      اگر بسته‌های TCP/IP را روی برنامه مشتری می‌گیرید، از آدرس IP عمومی نام میزبان استفاده شده در Virtual Host در دستور tcpdump استفاده کنید.

      برای اطلاعات بیشتر در مورد این ابزار و سایر انواع این دستور به tcpdump مراجعه کنید.

  2. بسته های TCP/IP جمع آوری شده را با استفاده از ابزار Wireshark یا ابزار مشابهی که با آن آشنا هستید، تجزیه و تحلیل کنید.

در اینجا تجزیه و تحلیل داده های بسته های TCP/IP نمونه با استفاده از ابزار Wireshark آمده است:

  1. بسته شماره 30 در tcpdump (تصویر زیر) نشان می دهد که برنامه مشتری (منبع) پیام "Client Hello" را به روتر (مقصد) ارسال کرده است.
  2. بسته شماره 34 نشان می دهد که روتر پیام Client Hello را از برنامه مشتری تأیید می کند.
  3. روتر "Server Hello" را در بسته شماره 35 ارسال می کند و سپس گواهی آن را ارسال می کند و همچنین از برنامه مشتری درخواست می کند تا گواهی خود را در بسته شماره 38 ارسال کند.
  4. در بسته شماره 38، جایی که روتر بسته "درخواست گواهی" را ارسال می کند، بخش "نام های متمایز" را بررسی کنید که جزئیات مربوط به گواهی مشتری، زنجیره آن و مقامات گواهی که توسط روتر (سرور) پذیرفته شده است را ارائه می دهد.
    5. شکل 3

  5. برنامه مشتری گواهی خود را در بسته شماره 41 ارسال می کند. بخش تأیید گواهی را در بسته شماره 41 بررسی کنید و گواهی ارسال شده توسط برنامه مشتری را تعیین کنید.

    شکل 4
  6. بررسی کنید که آیا موضوع و صادر کننده گواهی و زنجیره آن ارسال شده توسط برنامه مشتری (بسته شماره 41) با گواهی پذیرفته شده و زنجیره آن از روتر (بسته شماره 38) مطابقت دارد یا خیر. اگر عدم تطابق وجود دارد، دلیل این خطا است. از این رو روتر (سرور) هشدار رمزگذاری شده (بسته شماره 57) و به دنبال آن FIN، ACK (بسته 58) را به برنامه مشتری ارسال می کند و در نهایت اتصال قطع می شود.
  7. عدم تطابق گواهی و زنجیره آن می تواند ناشی از سناریوهای شرح داده شده در بخش های زیر باشد.

علت: گواهی نادرست ارسال شده توسط مشتری

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

تشخیص

  1. وارد رابط کاربری Edge شوید و پیکربندی میزبان مجازی خاص ( Admin > Virtual Hosts ) را که درخواست API برای آن انجام می شود، مشاهده کنید، یا از Get virtual host API management API برای دریافت تعریف میزبان مجازی خاص استفاده کنید.

    به طور معمول یک میزبان مجازی برای ارتباط دو طرفه TLS به صورت زیر است:

        <VirtualHost name="myTLSVHost">
        <HostAliases>
            <HostAlias>api.myCompany.com</HostAlias>
        </HostAliases>
        <Port>443</Port>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeystoreRef</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
                <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
        </SSLInfo>
    </VirtualHost>
  2. مرجع Truststore مورد استفاده در هاست مجازی را تعیین کنید.

    در مثال بالا، نام مرجع Truststore myCompanyTruststoreRef است.

  3. Truststore را که توسط مرجع Truststore اشاره شده است، تعیین کنید.
    1. در رابط کاربری Edge به Admin > Environments References بروید و نام مرجع Truststore را جستجو کنید.

    2. به نام موجود در ستون Reference برای مرجع خاص Truststore توجه کنید. این نام Truststore شما خواهد بود.

      رابط کاربری Edge مرجع فروشگاه اعتماد را نشان می دهد.
      شکل 5

      در مثال بالا، توجه کنید که myCompanyTrussttoreRef ارجاع به myCompanyTruststore دارد. بنابراین، نام Truststore myCompanyTrussttore است.

  4. گواهی های ذخیره شده در Truststore (که در مرحله قبل مشخص شد) را با استفاده از API های زیر دریافت کنید:

    1. گواهینامه ها را برای یک API ذخیره کلید یا Truststore فهرست کنید .

      این API تمام گواهی‌های موجود در Truststore خاص را فهرست می‌کند.

    2. جزئیات گواهی را از یک API فروشگاه کلید یا Truststore دریافت کنید .

      این API اطلاعات مربوط به یک گواهی خاص را در Truststore خاص برمی گرداند.

  5. بررسی کنید که آیا صادرکننده و موضوع هر یک از گواهینامه ها و زنجیره آن ذخیره شده در myCompanyTrussttore با گواهینامه و زنجیره آن مطابق با بسته های TCP/IP (به بسته شماره 38) در بالا مطابقت دارد یا خیر. اگر عدم تطابق وجود داشته باشد، نشان می‌دهد که گواهی‌های آپلود شده در Truststore در Edge Router بارگیری نمی‌شوند. انتقال به علت: گواهی‌های کلاینت در مسیریاب Edge بارگیری نشده‌اند .
  6. اگر در مرحله 5 عدم تطابق یافت نشد، پس این نشان می دهد که برنامه مشتری گواهی مناسب و زنجیره آن را ارسال نکرده است.

قطعنامه

اطمینان حاصل کنید که گواهی صحیح و زنجیره آن توسط برنامه مشتری به Edge ارسال شده است.

علت: از دست رفتن گواهی ریشه مشتری در Truststore

اگر گواهی ریشه امضا شده CA مشتری در Truststore روتر Edge وجود نداشته باشد، این خطا ایجاد می شود.

تشخیص

  1. وارد رابط کاربری Edge شوید و پیکربندی میزبان مجازی خاصی را که درخواست API برای آن انجام می‌شود، مشاهده کنید ( Admin > Virtual Hosts > virtual_host )، یا از Get virtual host API برای دریافت تعریف میزبان مجازی خاص استفاده کنید.

    به طور معمول یک میزبان مجازی برای ارتباط دو طرفه TLS به صورت زیر است:

        <VirtualHost name="myTLSVHost">
        <HostAliases>
            <HostAlias>api.myCompany.com</HostAlias>
        </HostAliases>
        <Port>443</Port>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>true</ClientAuthEnabled>
            <KeyStore>ref://myKeystoreRef</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
            <TrustStore>ref://myCompanyTruststoreRef</TrustStore>
        </SSLInfo>
    </VirtualHost>
  2. مرجع Truststore مورد استفاده در هاست مجازی را تعیین کنید. در مثال قبلی، نام مرجع Truststore myCompanyTruststoreRef است.
  3. Truststore واقعی مورد استفاده توسط مرجع Truststore را تعیین کنید.
  4. در رابط کاربری Edge، به Admin > Environments > References بروید و نام مرجع Truststore را جستجو کنید.

  5. نام Truststore برای مرجع خاص Truststore در ستون Reference قرار دارد.

    شکل 6

    در این مثال، توجه کنید که myCompanyTruststoreRef دارای myCompanyTruststore در ستون Reference است. بنابراین، نام Truststore myCompanyTrussttore است.

  6. گواهی های ذخیره شده در Truststore (که در مرحله قبل تعیین شد) را با استفاده از API های زیر دریافت کنید:
    1. گواهینامه ها را برای یک API ذخیره کلید یا Truststore فهرست کنید . این API تمام گواهی‌های موجود در Truststore را فهرست می‌کند.
    2. جزئیات گواهی را از یک API فروشگاه کلید یا Truststore دریافت کنید . این API اطلاعات مربوط به یک گواهی خاص را در Truststore برمی گرداند.

  7. بررسی کنید که آیا گواهی شامل یک زنجیره کامل است، از جمله گواهی ریشه ارسال شده توسط مشتری خاص همانطور که در بسته های TCP/IP مشاهده می شود ( شکل 4 را ببینید). Truststore باید شامل گواهی ریشه و همچنین گواهی برگ مشتری یا گواهی برگ و میانی باشد. اگر گواهی ریشه معتبر مشتری در Truststore وجود نداشته باشد، دلیل این خطا است.

    با این حال، اگر زنجیره گواهی کامل مشتری، از جمله گواهی ریشه، در Truststore وجود داشته باشد، نشان می‌دهد که گواهی‌های آپلود شده در truststore احتمالاً در Edge Router بارگیری نشده‌اند. اگر اینطور است، به علت مراجعه کنید: گواهینامه های مشتری در مسیریاب لبه بارگیری نشده اند .

قطعنامه

اطمینان حاصل کنید که گواهی صحیح کلاینت، از جمله گواهی ریشه، در Truststore روتر Apigee Edge موجود است.

علت: گواهینامه های سرویس گیرنده در روتر Edge بارگذاری نشده اند

  1. اگر کاربر Public Cloud هستید، با پشتیبانی Apigee Edge تماس بگیرید.
  2. اگر کاربر Private Cloud هستید، دستورالعمل‌های زیر را در هر روتر دنبال کنید:
    1. بررسی کنید که آیا فایل /opt/nginx/conf.d/OrgName_envName_vhostName-client.pem برای میزبان مجازی خاص وجود دارد یا خیر. اگر فایل وجود ندارد، به بخش Resolution در زیر بروید.
    2. اگر فایل وجود دارد، از دستور openssl زیر برای دریافت جزئیات گواهی‌هایی که در روتر Edge موجود است استفاده کنید: 
      openssl -in <OrgName_envName_vhostName-client.pem> -text -noout
    3. صادرکننده، موضوع و تاریخ انقضای گواهی را بررسی کنید. اگر هر یک از اینها با آنچه در Truststore در Edge UI یا با استفاده از APIهای مدیریتی مشاهده شده مطابقت نداشته باشد، دلیل این خطا است.
    4. این امکان وجود دارد که روتر گواهی های آپلود شده را دوباره بارگیری نکرده باشد.

قطعنامه

برای اطمینان از بارگیری آخرین گواهینامه ها با استفاده از مرحله زیر، روتر را مجددا راه اندازی کنید:

apigee-service edge-router restart

API ها را دوباره اجرا کنید و نتایج را بررسی کنید. اگر مشکل ادامه داشت، به جمع آوری اطلاعات تشخیصی بروید.

جمع آوری اطلاعات تشخیصی

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

  1. اگر کاربر Public Cloud هستید، اطلاعات زیر را ارائه دهید:
    1. نام سازمان
    2. نام محیطی
    3. نام پروکسی API
    4. نام میزبان مجازی
    5. نام مستعار میزبان
    6. برای بازتولید خطا، دستور curl را کامل کنید
    7. بسته های TCP/IP ضبط شده در برنامه مشتری
  2. اگر کاربر Private Cloud هستید، اطلاعات زیر را ارائه دهید:
    1. نام میزبان مجازی و تعریف آن با استفاده از Get virtual host API
    2. نام مستعار میزبان
    3. پیام خطای کامل مشاهده شد
    4. بسته های TCP/IP که در برنامه مشتری یا روتر ضبط شده اند.
    5. خروجی لیست گواهینامه ها از API API ذخیره کلید و همچنین جزئیات هر گواهی که با استفاده از Get Cert details API به دست آمده است.
  3. جزئیات مربوط به بخش‌هایی که در این کتاب راهنما امتحان کرده‌اید و هر بینش دیگری که به ما در حل سریع این مشکل کمک می‌کند.