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

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

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

المشكلة

يتلقى تطبيق العميل رمز حالة HTTP برقم 503 مع الرسالة "Service Unavailable" كاستجابة لطلب عرض بيانات من واجهة برمجة التطبيقات. في تتبُّع واجهة المستخدم، ستلاحظ أنّ 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 هو error.cause .

إذا كنت مستخدمًا خاصًا في السحابة الإلكترونية، يُرجى اتّباع التعليمات التالية:

يمكنك الحصول على معرّف الرسالة لطلب واجهة برمجة التطبيقات الذي تعذّر تنفيذه من خلال تحديد قيمة عنوان الخطأ "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 Cloud، ننصحك بالتقاط حزم TCP/IP على خادم الخلفية.
3. بعد تحديد المكان الذي تريد التقاط حزم TCP/IP فيه، استخدِم الأمر tcpdump التالي لالتقاط حزم TCP/IP.
حلِّل حزم TCP/IP باستخدام أداة Wireshark أو أداة مشابهة تعرفها.

وفي ما يلي تحليل عينة من بيانات حزم TCP/IP باستخدام أداة Wireshark:

alt_text

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

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

السبب: لا يوجد شهادة عميل

التشخيص

إذا لم يتم تحديد أي شهادة في ملف تخزين المفاتيح ضمن قسم معلومات طبقة المقابس الآمنة في نقطة النهاية المستهدفة أو الخادم الهدف المستخدم في نقطة النهاية المستهدفة، يكون سبب هذا الخطأ هو سبب الخطأ.

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

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

درجة الدقّة

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

السبب: عدم تطابق مرجع التصديق

وبوجه عام عندما يطلب الخادم من العميل إرسال شهادته، فإنه يشير إلى مجموعة من جهات الإصدار أو مراجع التصديق المقبولة. إذا لم تتطابق جهة الإصدار/المرجع المصدق للشهادة النهائية (أي الشهادة الأولى في سلسلة الشهادات) في ملف تخزين مفاتيح معالج الرسائل مع أي من مراجع التصديق التي يقبلها الخادم الخلفية، لن يرسل معالج الرسائل (وهي عملية تستند إلى 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. وفي حال عدم التطابق، لن يرسل "معالج الرسائل" شهادة العميل إلى الخادم الخلفي.

في المثال أعلاه، يمكنك ملاحظة أن جهة إصدار شهادة ورقة الشجر للعميل في ملف تخزين المفاتيح الخاص بمعالج الرسائل لا تتطابق مع أي من مراجع التصديق المقبولة لخادم الخلفية. وبالتالي، لا يرسل معالج الرسائل شهادة العميل إلى خادم الخلفية. يؤدي ذلك إلى تعذُّر تأكيد اتصال طبقة المقابس الآمنة (SSL) ويرسل خادم الخلفية الرسالة "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 ومشاركته مع:

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