تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

إخفاقات تأكيد الاتصال عبر طبقة المقابس الآمنة - شهادة العميل غير صالحة

أنت تعرض مستندات Apigee Edge.
انتقل إلى مستندات Apigee X. معلومات

المشكلة

يتلقى تطبيق العميل رمز حالة HTTP 503 مع الرسالة "الخدمة غير متوفرة" كرد على طلب من واجهة برمجة التطبيقات. في تتبُّع واجهة المستخدم، ستلاحظ أنّ الخطأ error.cause هو Received fatal alert: bad_certificate في "تدفق الطلب المستهدف" لطلب البيانات من واجهة برمجة التطبيقات الذي تعذّر تنفيذه.

إذا كان بإمكانك الوصول إلى سجلات معالج الرسائل، ستظهر رسالة الخطأ باسم Received fatal alert: bad_certificate لطلب البيانات من واجهة برمجة التطبيقات الذي تعذّر تنفيذه. تتم ملاحظة هذا الخطأ أثناء تأكيد اتصال طبقة المقابس الآمنة (SSL) بين معالج الرسائل وخادم الخلفية بطريقة إعداد بروتوكول أمان طبقة النقل (TLS) بطريقتين.

رسالة الخطأ

يحصل تطبيق العميل على رمز الاستجابة التالي:

HTTP/1.1 503 Service Unavailable

بالإضافة إلى ذلك، قد تلاحظ رسالة الخطأ التالية:

{
 "fault": {
    "faultstring":"The Service is temporarily unavailable",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.ServiceUnavailable"
    }
 }
}

سيظهر لمستخدمي Private Cloud رسالة الخطأ التالية لطلب البيانات من واجهة برمجة التطبيقات المحدّد. في سجلات معالج الرسائل /opt/apigee/var/log/edge-message-processor/system.log:

2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLClientChannel[C:IP address:port # Remote host:IP address:port #]@65461 useCount=1 bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed, message: Received fatal alert: bad_certificate

الأسباب المحتملة

في ما يلي الأسباب المحتمَلة لهذه المشكلة:

السبب	الوصف	تعليمات تحديد المشاكل وحلّها التي تنطبق على
عدم توفّر شهادة عميل	لا يحتوي ملف تخزين المفاتيح المُستخدَم في نقطة النهاية المستهدفة في الخادم المستهدف على أي شهادة عميل.	مستخدمو Edge، سواء على السحابة الإلكترونية الخاصة أو العامة
عدم تطابق هيئة إصدار الشهادات	مرجع التصديق الخاص بالشهادة الطرفية (الشهادة الأولى في سلسلة الشهادات) في مخزن مفاتيح معالج الرسائل لا يتطابق مع أي من مراجع التصديق التي يقبلها خادم الخلفية.	مستخدمو Edge، سواء على السحابة الإلكترونية الخاصة أو العامة

خطوات التشخيص الشائعة

يمكنك تفعيل التتبُّع في واجهة مستخدم Edge، وإجراء طلب بيانات من واجهة برمجة التطبيقات، وإعادة إنتاج المشكلة.
ضمن نتائج التتبع في واجهة المستخدم، تنقل خلال كل مرحلة وحدِّد مكان حدث خطأ. كان هذا الخطأ يحدث في تدفق الطلبات المستهدف.
افحص التدفق الذي يعرض الخطأ، ويجب أن تلاحظ الخطأ كما هو موضح في المثال المتتبّع أدناه:
كما ترى في لقطة الشاشة أعلاه، فإن error.cause هو "تم تلقّي تنبيه خطير: Bad_certificate".

إذا كنت من مستخدمي Cloud Private، يُرجى اتّباع التعليمات التالية:

يمكنك الحصول على رقم تعريف الرسالة لطلب البيانات من واجهة برمجة التطبيقات الذي تعذّر تنفيذه من خلال تحديد قيمة عنوان الخطأ "X-Apigee.Message-ID" في المرحلة المشار إليها بواسطة AX في عملية التتبع.

البحث عن معرّف الرسالة هذا في سجل معالج الرسائل /opt/apigee/var/log/edge-message-processor/system.log وتحديد إذا عثرت على أي معلومات أخرى حول الخطأ:

2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
SSLClientChannel[C:IP address:port # Remote host:IP address:port #]@65461 useCount=1
bytesRead=0 bytesWritten=0 age=529ms lastIO=529ms handshake failed, message: Received fatal alert: bad_certificate
2017-10-23 05:28:57,813 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() : SSLInfo:
KeyStore:java.security.KeyStore@52de60d9 KeyAlias:KeyAlias TrustStore:java.security.KeyStore@6ec45759
2017-10-23 05:28:57,814 org:org-name env:env-name api:apiproxy-name
rev:revision-number messageid:message_id NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
RequestWriteListener.onException(HTTPRequest@6071a73d)
javax.net.ssl.SSLException: Received fatal alert: bad_certificate
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634) ~[na:1.8.0_101]
at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1800) ~[na:1.8.0_101]
at com.apigee.nio.NIOSelector$SelectedIterator.findNext(NIOSelector.java:496) [nio-1.0.0.jar:na]
at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:312) [nio-1.0.0.jar:na]
at com.apigee.nio.NIOSelector$2.findNext(NIOSelector.java:302) [nio-1.0.0.jar:na]
at com.apigee.nio.util.NonNullIterator.computeNext(NonNullIterator.java:21) [nio-1.0.0.jar:na]
at com.apigee.nio.util.AbstractIterator.hasNext(AbstractIterator.java:47) [nio-1.0.0.jar:na]
at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:59) [nio-1.0.0.jar:na]

احتوى سجلّ معالج الرسائل على تتبُّع تسلسل استدعاء الدوال البرمجية للخطأ Received fatal alert: bad_certificate، لكنها لا أو لديك أي معلومات أخرى تشير إلى سبب هذه المشكلة.

للتحقيق في هذه المشكلة بشكل أكبر، ستحتاج إلى التقاط حزم TCP/IP باستخدام tcpdump.
1. إذا كنت مستخدمًا خاصًا على السحابة الإلكترونية، يمكنك التقاط حزم TCP/IP على خادم الخلفية أو معالج الرسائل. ويفضَّل أن يتم التقاطها على خادم الخلفية أثناء فك تشفير الحزم على خادم الخلفية.
2. إذا كنت مستخدمًا عامًا في Cloud، يمكنك التقاط بيانات بروتوكول TCP/IP الحزم على خادم الخلفية.
3. بمجرد أن تقرر أين تريد التقاط حزم TCP/IP، استخدم أسفل tcpdump لالتقاط حزم TCP/IP.
حلِّل حِزم TCP/IP باستخدام أداة Wireshark أو أداة مشابهة تعرفها.

وإليك تحليل نموذج بيانات حزم TCP/IP باستخدام أداة Wireshark:

النص البديل

توضّح الرسالة رقم 4 في الأداة tcpdump أعلاه أن معالج الرسائل (المصدر) تم إرسال رسالة "Client Hello" إلى خادم الخلفية (الوجهة).
توضح الرسالة رقم 5 أن خادم الخلفية يتعرف على رسالة Client Hello. من معالج الرسائل.
يرسل خادم الخلفية رسالة "Server Hello" إلى جانب الشهادة ثم تطلب من العميل إرسال شهادته في الرسالة رقم 7.
يكمل معالج الرسائل التحقق من الشهادة ويقر رسالة ServerHello لخادم الخلفية في الرسالة رقم 8.
يرسل معالج الرسائل شهادته إلى خادم الخلفية في الرسالة رقم 9.
يقر خادم الخلفية باستلام تعليمات الشهادة في الرسالة رقم 11.
ومع ذلك، فإنه يرسل على الفور تنبيه فادح: شهادة سيئة إلى معالج الرسائل (الرسالة رقم 12). يشير هذا إلى أن الشهادة المرسلة من كان معالج الرسائل سيئًا وبالتالي تعذر التحقق من الشهادة في خادم الخلفية. ونتيجةً لذلك، تعذّر إتمام عملية تأكيد اتصال طبقة المقابس الآمنة (SSL) وقد أصبح الاتصال سيتم إغلاقها.
لنلقِ الآن نظرة على الرسالة رقم 9 للتحقق من محتوى الشهادة التي أرسلها معالج الرسائل:
وكما تلاحظ، لم يحصل خادم الخلفية على أي شهادة من جهاز العميل. (مدة الشهادة: 0). وبالتالي، يرسل خادم الخلفية تنبيهًا فادحًا: شهادة سيئة.
يحدث هذا عادةً عندما يكون العميل، أي معالج الرسائل (عملية تستند إلى Java):
1. لا يحتوي على أي شهادة عميل في ملف KeyStore، أو
2. تعذر إرسال شهادة عميل. يمكن أن يحدث هذا إذا لم تتمكن من العثور على شهادة تم إصدارها من خلال إحدى المراجع المصدقة المقبولة لخادم الخلفية. بمعنى، إذا كان مرجع التصديق لشهادة أوراق العميل (أي أن الشهادة الأولى في السلسلة) لا تتطابق مع أي شهادة من شهادات مراجع التصديق المقبولة، فلن يرسل معالج الرسائل الشهادة.

لنلقِ نظرة على كلٍ من هذه الأسباب على حدة على النحو التالي.

السبب: ما مِن شهادة عميل

التشخيص

في حال عدم وجود شهادة في ملف تخزين المفاتيح المحدّد في قسم "معلومات طبقة المقابس الآمنة" (SSL) لنقطة النهاية المستهدفة أو الخادم الهدف المستخدم في نقطة النهاية المستهدفة، فهذا هو سبب هذا الخطأ.

يُرجى اتباع الخطوات التالية لتحديد ما إذا كان هذا هو السبب أم لا:

تحديد ملف تخزين المفاتيح المُستخدَم في "نقطة النهاية المستهدَفة" أو "الخادم الهدف" لخادم وكيل واجهة برمجة التطبيقات المحدد من خلال اتّباع الخطوات التالية:
1. الحصول على الاسم المرجعي لملف تخزين المفاتيح من عنصر Keystore في القسم SSLInfo في "نقطة النهاية المستهدفة" أو "الخادم الهدف".
  لنلقِ نظرة على نموذج قسم SSLInfo في أحد إعدادات نقطة النهاية المستهدفة:
```
<SSLInfo>
  <Enabled>true</Enabled>
  <ClientAuthEnabled>true</ClientAuthEnabled>
  <KeyStore>ref://myKeystoreRef</KeyStore>
  <KeyAlias>myKey</KeyAlias>
  <TrustStore>ref://myTrustStoreRef</TrustStore>
</SSLInfo>
```
2. في المثال أعلاه، يكون الاسم المرجعي لملف Keystore هو myKeystoreref.
3. انتقل إلى واجهة مستخدم Edge وحدد خوادم واجهة برمجة التطبيقات الوكيلة -> إعدادات البيئة.
  اختَر علامة التبويب المراجع وابحث عن اسم مرجع ملف تخزين المفاتيح. دوِّن الاسم في العمود المرجع الخاص بمرجع ملف تخزين المفاتيح المحدّد. سيكون هذا اسم ملف تخزين المفاتيح.
4. في المثال أعلاه، يمكنك ملاحظة أنّ myKeystoreref يحتوي على المرجع إلى "myKeystore". وبالتالي، يكون اسم ملف تخزين المفاتيح هو myKeystore.
تحقق مما إذا كان ملف تخزين المفاتيح هذا يحتوي على الشهادة إما باستخدام واجهة مستخدم Edge أو إدراج شهادات لواجهة برمجة تطبيقات ملف تخزين المفاتيح.
في حال كان ملف تخزين المفاتيح يحتوي على شهادات، انتقِل إلى السبب: عدم تطابق هيئة إصدار الشهادات.
إذا لم يحتوي ملف تخزين المفاتيح على أي شهادة، فإن هذا هو سبب عدم إرسال شهادة العميل بواسطة معالج الرسائل.

الدقة

تأكد من تحميل سلسلة شهادات العميل الصحيحة والكاملة إلى ملف تخزين المفاتيح المحدّد في معالج الرسائل.

السبب: عدم تطابق هيئة إصدار الشهادات

وبشكل عام، عندما يطلب الخادم من العميل إرسال شهادته، فإنه تشير إلى مجموعة جهات الإصدار أو مراجع التصديق المقبولة. إذا كانت جهة الإصدار/هيئة إصدار الشهادات لشهادة الخصائص التفصيلية (أي الشهادة في سلسلة الشهادات) في ملف تخزين مفاتيح معالج الرسائل لا تتطابق مع أي من مراجع التصديق التي يقبلها خادم الخلفية، فسيتولى معالج الرسائل (وهو عملية تستند إلى Java) عدم إرسال الشهادة إلى خادم الخلفية.

يُرجى اتّباع الخطوات التالية للتأكّد من ذلك:

إدراج شهادات لواجهة برمجة تطبيقات ملف تخزين المفاتيح.
احصل على تفاصيل كل شهادة تم الحصول عليها في الخطوة رقم 1 أعلاه باستخدام الحصول على شهادة لواجهة برمجة تطبيقات ملف تخزين المفاتيح

دوِّن جهة إصدار الشهادة التفصيلية (أي الشهادة الأولى في سلسلة الشهادات) المخزّنة في ملف تخزين المفاتيح.

نموذج لشهادة أوراق الشجر

{
  "certInfo" : [ {
    "basicConstraints" : "CA:FALSE",
    "expiryDate" : 1578889324000,
    "isValid" : "Yes",
    "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com",
    "publicKey" : "RSA Public Key, 2048 bits",
    "serialNumber" : "65:00:00:00:d2:3e:12:d8:56:fa:e2:a9:69:00:06:00:00:00:d2",
    "sigAlgName" : "SHA256withRSA",
    "subject" : "CN=nonprod-api.mycompany.com, OU=ITS, O=MyCompany, L=MELBOURNE, ST=VIC, C=AU",
    "subjectAlternativeNames" : [ ],
    "validFrom" : 1484281324000,
    "version" : 3
  } ],
  "certName" : "nonprod-api.mycompany.com.key.pem-cert"
}

في المثال أعلاه، جهة الإصدار/مرجع الشهادة هو "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com"

حدد القائمة المقبولة لخادم الخلفية لجهات الإصدار أو مراجع التصديق باستخدام أحد الأساليب التالية:
الأسلوب 1: استخدِم الأمر opensl أدناه:
```
openssl s_client -host <backend server host name> -port <Backend port#> -cert <Client Certificate> -key <Client Private Key>
```
ارجع إلى القسم بعنوان "أسماء هيئة إصدار الشهادات (CA) المقبولة لشهادة العميل" في مُخرج هذا الأمر كما هو موضّح أدناه:
```
Acceptable client certificate CA names
/C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com
/C=AU/ST=VIC/L=MELBOURNE/O=MyCompany/OU=ITS/CN=nonprod-api.mycompany.com
```
الأسلوب 2: التحقق من حزمة Certificate Request في حزم TCP/IP، حيث يطلب خادم الخلفية من العميل إرسال شهادته:

في نماذج حزم TCP/IP الواردة أعلاه، Certificate Request الحزمة هي الرسالة رقم 7. راجع قسم "الأسماء المميزة"، الذي يحتوي على مراجع التصديق المقبولة لخادم الخلفية.

ملاحظة: قائمة "مراجع التصديق المقبولة" لخادم الخلفية تتم تعبئة هذا الحقل عن طريق إضافة جهات إصدار جميع الشهادات المخزنة في Truststore لخادم الخلفية.
تأكَّد مما إذا كان مرجع التصديق الذي تم الحصول عليه في الخطوة 3 يتطابق مع القائمة. من جهات الإصدار المقبولة أو مراجع التصديق التي تم الحصول عليها في الخطوة رقم 4 لخادم الخلفية وفي حال عدم التطابق، لن يرسل معالج الرسائل شهادة العميل. إلى خادم الخلفية.

في المثال أعلاه، يمكنك ملاحظة أنّ جهة إصدار شهادة ورقة الشجر للعميل في مخزن مفاتيح معالج الرسائل لا يتطابق مع أي من إعدادات خادم الخلفية مراجع التصديق المقبولة. وبالتالي، لا يقوم معالج الرسائل إرسال شهادة العميل إلى خادم الخلفية. يؤدي ذلك إلى تعذُّر تأكيد اتصال طبقة المقابس الآمنة وإرسال خادم الخلفية الرسالة "Fatal alert: bad_certificate". .

الدقة

تأكَّد من تطابق الشهادة مع جهة الإصدار/مرجع الشهادة جهة الإصدار/مرجع التصديق لشهادة أوراق العميل (الشهادة الأولى في السلسلة) في Truststore لخادم الخلفية.
في المثال الموضَّح في هذا الدليل الإرشادي، تظهر الشهادة مع جهة الإصدار "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com" تمت إضافة إلى Truststore لخادم الخلفية لحلّ المشكلة.

في حال استمرار المشكلة، انتقِل إلى ضرورة جمع معلومات التشخيص.

يجب جمع معلومات التشخيص

إذا استمرت المشكلة حتى بعد اتباع التعليمات أعلاه، يُرجى جمع معلومات التشخيص التالية. التواصل معهم ومشاركتهم على دعم Apigee Edge:

إذا كنت تستخدم Public Cloud، يُرجى تقديم المعلومات التالية:
1. اسم المؤسسة
2. اسم البيئة
3. اسم الخادم الوكيل لواجهة برمجة التطبيقات
4. أكمِل أمر curl لإعادة إنتاج الخطأ.
5. ملف تتبُّع يعرض الخطأ
6. حزم TCP/IP التي تم التقاطها على خادم الخلفية
إذا كنت من مستخدمي سحابة خاصة، قدِّم المعلومات التالية:
1. تم ملاحظة رسالة خطأ كاملة
2. حزمة الخادم الوكيل لواجهة برمجة التطبيقات
3. ملف تتبُّع يعرض الخطأ
4. سجلّات معالج الرسائل /opt/apigee/var/log/edge-message-processor/logs/system.log
5. حزم TCP/IP التي تم التقاطها على خادم الخلفية أو معالج الرسائل.
6. نتيجة الحصول على الشهادة لواجهة برمجة تطبيقات ملف تخزين المفاتيح
تفاصيل حول الأقسام التي جرّبتها في هذا الدليل الإرشادي وأي أقسام أخرى الأفكار التي ستساعدنا في إيجاد حل سريع لهذه المشكلة.