این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

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

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

علامت

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

پیام خطا

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

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 روتر Edge مطابقت نداشته باشد.	کاربران Edge Private و Public Cloud
گواهی ریشه کلاینت در Truststore وجود ندارد	این خطا زمانی رخ می‌دهد که گواهی ریشه امضا شده توسط CA کلاینت در truststore روتر Edge وجود نداشته باشد.	کاربران Edge Private و Public Cloud
گواهی‌های کلاینت در روتر لبه بارگذاری نشده‌اند	این خطا زمانی رخ می‌دهد که گواهی‌های کلاینت آپلود شده در truststore روی روتر بارگذاری نشده باشند.	کاربران فضای ابری خصوصی اج

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

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

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

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

تشخیص

به رابط کاربری Edge وارد شوید و پیکربندی میزبان مجازی خاص ( Admin > Virtual Hosts ) را که درخواست API برای آن ارسال شده است، مشاهده کنید، یا از API مدیریت 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://myTruststoreRef</TrustStore>
    </SSLInfo>
</VirtualHost>
```
مرجع Truststore مورد استفاده در Virtual Host را تعیین کنید. در مثال بالا، نام مرجع Truststore، myTruststoreRef است.
فروشگاه اعتمادی که با ارجاع به فروشگاه اعتماد به آن اشاره شده است را تعیین کنید.
1. در رابط کاربری Edge به مسیر Admin > Environments > References بروید و نام مرجع Truststore را جستجو کنید.
2. نامی را که در ستون مرجع برای مرجع Truststore خاص وجود دارد، یادداشت کنید. این نام Truststore شما خواهد بود.
  شکل ۱
  در مثال بالا، توجه داشته باشید که myTruststoreRef به myTruststore ارجاع داده شده است. بنابراین، نام Truststore، myTruststore است.
در مسیر Admin > Environments > TLS Keystores در رابط کاربری Edge، به TLS Keystores بروید و Truststore موجود در مرحله ۳ را پیدا کنید.
گواهی‌نامه‌ی مربوط به Truststore خاص (که در مرحله‌ی ۳ بالا تعیین شده است) را مطابق شکل زیر انتخاب کنید:
شکل ۲
گواهی با نام مستعار client-cert-markw در مثال بالا، نشان می‌دهد که منقضی شده است.
بررسی کنید که آیا گواهی‌نامه‌ی مربوط به نام مستعار گواهی‌نامه‌ی فروشگاه اعتماد شما منقضی شده است یا خیر.
اگر گواهی منقضی نشده است، برای سایر علل به مراحل تشخیص مشترک بروید.

وضوح تصویر

یک گواهی جدید تهیه کنید و گواهی را آپلود کنید:

یک فروشگاه اعتماد جدید ایجاد کنید، مثلاً myNewTruststore.
گواهی جدید را در truststore تازه ایجاد شده آپلود کنید.
مرجع trustore مورد استفاده در Virtual Host خاص را با استفاده از مراحل ذکر شده در بخش «اصلاح یک مرجع» تغییر دهید تا به truststore جدید اشاره کند.
در مثالی که در بالا توضیح داده شد، مرجع myTruststoreRef را به myNewTruststore ارجاع دهید.

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

برای بررسی این مشکل، باید بسته‌های TCP/IP را با استفاده از ابزار tcpdump ضبط کنید.
1. اگر شما یک کاربر ابر خصوصی هستید، می‌توانید بسته‌های TCP/IP را در برنامه کلاینت یا روتر ضبط کنید.
2. اگر شما یک کاربر ابر عمومی هستید، بسته‌های 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 مراجعه کنید.
بسته‌های TCP/IP جمع‌آوری‌شده را با استفاده از ابزار Wireshark یا ابزار مشابهی که با آن آشنا هستید، تجزیه و تحلیل کنید.

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

بسته شماره ۳۰ در tcpdump (تصویر زیر) نشان می‌دهد که برنامه کلاینت (منبع) یک پیام "Client Hello" به روتر (مقصد) ارسال کرده است.
بسته شماره ۳۴ نشان می‌دهد که روتر پیام Client Hello را از برنامه کلاینت تایید می‌کند.
روتر عبارت "Server Hello" را در بسته شماره ۳۵ ارسال می‌کند و سپس گواهی خود را ارسال می‌کند و همچنین از برنامه کلاینت درخواست می‌کند که گواهی خود را در بسته شماره ۳۸ ارسال کند.
در بسته شماره ۳۸، جایی که روتر بسته "درخواست گواهی" را ارسال می‌کند، بخش "نام‌های متمایز" را بررسی کنید که جزئیاتی در مورد گواهی کلاینت، زنجیره آن و مراجع گواهی که توسط روتر (سرور) پذیرفته می‌شوند، ارائه می‌دهد.

برنامه‌ی کلاینت گواهی خود را در بسته‌ی شماره‌ی ۴۱ ارسال می‌کند. بخش تأیید گواهی را در بسته‌ی شماره‌ی ۴۱ بررسی کنید و گواهی ارسال شده توسط برنامه‌ی کلاینت را تعیین کنید.
شکل ۴
بررسی کنید که آیا موضوع و صادرکننده گواهی و زنجیره آن که توسط برنامه کلاینت ارسال شده است (بسته شماره ۴۱) با گواهی پذیرفته شده و زنجیره آن از روتر (بسته شماره ۳۸) مطابقت دارد یا خیر. اگر عدم تطابق وجود داشته باشد، دلیل این خطا همین است. از این رو، روتر (سرور) هشدار رمزگذاری شده (بسته شماره ۵۷) و به دنبال آن FIN و ACK (بسته شماره ۵۸) را به برنامه کلاینت ارسال می‌کند و در نهایت اتصال قطع می‌شود.
عدم تطابق گواهی و زنجیره آن می‌تواند ناشی از سناریوهایی باشد که در بخش‌های بعدی توضیح داده شده است.

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

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

تشخیص

وارد رابط کاربری Edge شوید و پیکربندی میزبان مجازی خاص ( Admin > Virtual Hosts ) را که درخواست API برای آن ارسال شده است، مشاهده کنید، یا از API مدیریت 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>

مرجع Truststore مورد استفاده در میزبان مجازی را تعیین کنید.
در مثال بالا، نام مرجع Truststore، myCompanyTruststoreRef است.
Truststore مورد اشاره توسط مرجع Truststore را تعیین کنید.
1. در رابط کاربری Edge به مسیر Admin > Environments References بروید و نام مرجع Truststore را جستجو کنید.
2. نامی را که در ستون مرجع برای مرجع Truststore خاص وجود دارد، یادداشت کنید. این نام Truststore شما خواهد بود.
  شکل ۵
  در مثال بالا، توجه داشته باشید که myCompanyTruststoreRef به myCompanyTruststore ارجاع داده شده است. بنابراین، نام Truststore، myCompanyTruststore است.
با استفاده از API های زیر، گواهی‌های ذخیره شده در Truststore (که در مرحله قبل تعیین شده‌اند) را دریافت کنید:
1. فهرست گواهینامه‌های مربوط به یک API مربوط به keystore یا truststore .
  این API تمام گواهینامه‌های موجود در Truststore خاص را فهرست می‌کند.
2. جزئیات گواهینامه را از یک API مربوط به keystore یا truststore دریافت کنید .
  این API اطلاعات مربوط به یک گواهی خاص را در Truststore خاص برمی‌گرداند.
بررسی کنید که آیا صادرکننده و موضوع هر یک از گواهی‌ها و زنجیره آن که در myCompanyTruststore ذخیره شده‌اند، با صادرکننده و زنجیره آن، همانطور که در بسته‌های TCP/IP (به بسته شماره ۳۸ مراجعه کنید) در بالا مشاهده می‌شود، مطابقت دارند یا خیر. اگر عدم تطابق وجود داشته باشد، نشان می‌دهد که گواهی‌های آپلود شده در truststore در Edge Router بارگذاری نمی‌شوند. به علت بروید: گواهی‌های کلاینت در Edge Router بارگذاری نمی‌شوند .
اگر در مرحله ۵ هیچ عدم تطابقی یافت نشد، نشان می‌دهد که برنامه کلاینت، گواهی صحیح و زنجیره آن را ارسال نکرده است.

وضوح تصویر

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

علت: فقدان گواهی ریشه کلاینت در Truststore

این خطا زمانی رخ می‌دهد که گواهی ریشه امضا شده توسط CA کلاینت در truststore روتر Edge وجود نداشته باشد.

تشخیص

وارد رابط کاربری 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>

مرجع truststore مورد استفاده در میزبان مجازی را تعیین کنید. در مثال قبلی، نام مرجع truststore، myCompanyTruststoreRef است.
فروشگاه اعتماد واقعی مورد استفاده توسط مرجع فروشگاه اعتماد را تعیین کنید.
در رابط کاربری Edge، به مسیر Admin > Environments > References بروید و نام مرجع truststore را جستجو کنید.
نام فروشگاه اعتماد برای مرجع فروشگاه اعتماد خاص در ستون مرجع قرار دارد.
شکل ۶
در این مثال، توجه داشته باشید که myCompanyTruststoreRef در ستون Reference دارای myCompanyTruststore است. بنابراین، نام truststore، myCompanyTruststore است.
با استفاده از API های زیر، گواهی‌های ذخیره شده در truststore (که در مرحله قبل تعیین شده‌اند) را دریافت کنید:
1. فهرست کردن گواهینامه‌های مربوط به یک API مربوط به keystore یا truststore . این API تمام گواهینامه‌های موجود در truststore را فهرست می‌کند.
2. دریافت جزئیات گواهی از یک API مربوط به keystore یا truststore . این API اطلاعات مربوط به یک گواهی خاص در truststore را برمی‌گرداند.
بررسی کنید که آیا گواهی شامل یک زنجیره کامل، از جمله گواهی ریشه ارسال شده توسط کلاینت خاص، همانطور که در بسته‌های TCP/IP مشاهده می‌شود ( شکل ۴ را ببینید)، می‌شود یا خیر. محل نگهداری گواهی باید شامل گواهی ریشه و همچنین گواهی برگ کلاینت یا گواهی برگ و میانی باشد. اگر گواهی ریشه معتبر کلاینت در محل نگهداری گواهی وجود ندارد، دلیل خطا همین است.
با این حال، اگر کل زنجیره گواهی کلاینت، از جمله گواهی ریشه، در truststore وجود داشته باشد، نشان می‌دهد که گواهی‌های آپلود شده در truststore احتمالاً در Edge Router بارگذاری نشده‌اند. در این صورت، به بخش «علت: گواهی‌های کلاینت در Edge Router بارگذاری نشده‌اند» مراجعه کنید.

وضوح تصویر

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

علت: گواهی‌های کلاینت در روتر لبه بارگذاری نشده‌اند

اگر کاربر فضای ابری عمومی هستید، با پشتیبانی Apigee Edge تماس بگیرید.
اگر کاربر 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 یا با استفاده از APIهای مدیریتی مشاهده شده است، مطابقت ندارد، علت خطا همین است.
4. ممکن است روتر گواهی‌های آپلود شده را دوباره بارگذاری نکرده باشد.

وضوح تصویر

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

apigee-service edge-router restart

APIها را دوباره اجرا کنید و نتایج را بررسی کنید. اگر مشکل همچنان ادامه داشت، به Gather Diagnostic Information بروید.

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

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

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