एसएसएल हैंडशेक की कोशिशें - खराब क्लाइंट सर्टिफ़िकेट

आपको Apigee Edge का दस्तावेज़ दिख रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी

पर क्लिक करें.

समस्या का ब्यौरा

क्लाइंट ऐप्लिकेशन को एपीआई अनुरोध के जवाब के तौर पर, "सेवा उपलब्ध नहीं है" मैसेज के साथ 503 एचटीटीपी स्टेटस कोड मिलता है. यूज़र इंटरफ़ेस (यूआई) ट्रेस में, आपको दिखेगा कि एपीआई अनुरोध पूरा न होने पर, टारगेट अनुरोध फ़्लो में error.cause Received fatal alert: bad_certificate है.

अगर आपके पास मैसेज प्रोसेसर के लॉग का ऐक्सेस है, तो आपको एपीआई अनुरोध पूरे न होने पर गड़बड़ी का मैसेज Received fatal alert: bad_certificate के तौर पर दिखेगा. यह गड़बड़ी, दो तरफ़ा टीएलएस सेटअप में मैसेज प्रोसेसर और बैकएंड सर्वर के बीच एसएसएल हैंडशेक की प्रोसेस के दौरान दिखती है.

गड़बड़ी का मैसेज

क्लाइंट ऐप्लिकेशन को यह रिस्पॉन्स कोड मिलता है:

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

संभावित वजहें

इस समस्या की ये वजहें हो सकती हैं:

Cause ब्यौरा समस्या हल करने के निर्देश
कोई क्लाइंट सर्टिफ़िकेट नहीं है टारगेट सर्वर के टारगेट एंडपॉइंट में इस्तेमाल किए गए कीस्टोर में कोई क्लाइंट सर्टिफ़िकेट नहीं है. Edge Private और Public Cloud के उपयोगकर्ता
सर्टिफ़िकेट देने वाली संस्था का मेल न खाना मैसेज प्रोसेसर के कीस्टोर में मौजूद लीफ़ सर्टिफ़िकेट (सर्टिफ़िकेट चेन में पहला सर्टिफ़िकेट) की सर्टिफ़िकेट देने वाली संस्था, बैकएंड सर्वर से स्वीकार की गई किसी भी सर्टिफ़िकेट देने वाली संस्था से मेल नहीं खाती. Edge Private और Public Cloud के उपयोगकर्ता

गड़बड़ी का पता लगाने के सामान्य चरण

  1. Edge यूज़र इंटरफ़ेस (यूआई) में ट्रेस की सुविधा चालू करें, एपीआई कॉल करें, और समस्या को फिर से दोहराएं.
  2. यूज़र इंटरफ़ेस (यूआई) ट्रेस के नतीजों में, हर फ़ेज़ पर जाएं और पता लगाएं कि गड़बड़ी कहां हुई है. यह गड़बड़ी, टारगेट अनुरोध फ़्लो में हुई होगी.
  3. उस फ़्लो की जांच करें जिसमें गड़बड़ी दिख रही है. आपको गड़बड़ी इस तरह दिखनी चाहिए, जैसा कि यहां दिए गए उदाहरण में दिखाया गया है:

    alt_text

  4. ऊपर दिए गए स्क्रीनशॉट में दिखाया गया है कि error.cause की वैल्यू "Received fatal alert: bad_certificate" है.
  5. अगर आप Private Cloud के उपयोगकर्ता हैं, तो यहां दिया गया तरीका अपनाएं:
    1. एपीआई अनुरोध पूरा न होने पर, आपको मैसेज आईडी मिल सकता है. इसके लिए, आपको ट्रेस में AX की ओर से बताए गए फ़ेज़ में, गड़बड़ी के हेडर "X-Apigee.Message-ID" की वैल्यू का पता लगाना होगा.
    2. Message Processor के लॉग में इस मैसेज आईडी को खोजें /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]

      Message Processor के लॉग में गड़बड़ी Received fatal alert: bad_certificate का स्टैक ट्रेस मौजूद है. हालांकि, इसमें इस समस्या की वजह के बारे में कोई अन्य जानकारी नहीं है.

  6. इस समस्या की ज़्यादा जांच करने के लिए, आपको tcpdump टूल का इस्तेमाल करके, टीसीपी/आईपी पैकेट कैप्चर करने होंगे.
    1. अगर आप Private Cloud के उपयोगकर्ता हैं, तो बैकएंड सर्वर या मैसेज प्रोसेसर पर टीसीपी/आईपी पैकेट कैप्चर किए जा सकते हैं. बेहतर होगा कि इन्हें बैकएंड सर्वर पर कैप्चर किया जाए, क्योंकि पैकेट बैकएंड सर्वर पर डिक्रिप्ट किए जाते हैं.
    2. अगर आप सार्वजनिक क्लाउड के उपयोगकर्ता हैं, तो बैकएंड सर्वर पर टीसीपी/आईपी पैकेट कैप्चर करें.
    3. टीसीपी/आईपी पैकेट को कैप्चर करने के लिए जगह तय करने के बाद, टीसीपी/आईपी पैकेट को कैप्चर करने के लिए यहां दी गई tcpdump कमांड का इस्तेमाल करें.
      4. tcpdump -i any -s 0 host <IP address> -w <File name>

      अगर मैसेज प्रोसेसर पर टीसीपी/आईपी पैकेट लिए जा रहे हैं, तो tcpdump कमांड में बैकएंड सर्वर के सार्वजनिक आईपी पते का इस्तेमाल करें.

      अगर बैकएंड सर्वर/मैसेज प्रोसेसर के लिए एक से ज़्यादा आईपी पते हैं, तो आपको tcpdump कमांड का इस्तेमाल करना होगा. इस टूल और इस कमांड के अन्य वैरिएंट के बारे में ज़्यादा जानने के लिए, tcpdump देखें.

  7. Wireshark टूल या इसी तरह के किसी ऐसे टूल का इस्तेमाल करके टीसीपी/आईपी पैकेट का विश्लेषण करें जिसके बारे में आपको जानकारी हो.

यहां Wireshark टूल का इस्तेमाल करके, टीसीपी/आईपी पैकेट के सैंपल डेटा का विश्लेषण किया गया है:

alt_text

  1. ऊपर दिए गए tcpdump में मैसेज #4 से पता चलता है कि मैसेज प्रोसेसर (सोर्स) ने बैकएंड सर्वर (डेस्टिनेशन) को "क्लाइंट हैलो" मैसेज भेजा है.
  2. मैसेज #5 से पता चलता है कि बैकएंड सर्वर, मैसेज प्रोसेसर से मिले Client Hello मैसेज को स्वीकार करता है.
  3. बैकएंड सर्वर, "Server Hello" मैसेज के साथ अपना सर्टिफ़िकेट भेजता है. इसके बाद, वह क्लाइंट से मैसेज #7 में अपना सर्टिफ़िकेट भेजने का अनुरोध करता है.
  4. मैसेज प्रोसेसर, सर्टिफ़िकेट की पुष्टि करता है. साथ ही, मैसेज #8 में बैकएंड सर्वर के ServerHello मैसेज की पुष्टि करता है.
  5. मैसेज प्रोसेसर, मैसेज #9 में बैकएंड सर्वर को अपना सर्टिफ़िकेट भेजता है.
  6. बैकएंड सर्वर, मैसेज #11 में मैसेज प्रोसेसर के सर्टिफ़िकेट की रसीद की पुष्टि करता है.

  7. हालांकि, यह तुरंत मैसेज प्रोसेसर (मैसेज #12) को गंभीर सूचना: खराब सर्टिफ़िकेट भेजता है. इससे पता चलता है कि मैसेज प्रोसेसर ने जो सर्टिफ़िकेट भेजा है वह खराब है. इसलिए, बैकएंड सर्वर पर सर्टिफ़िकेट की पुष्टि नहीं हो सकी. इस वजह से, एसएसएल हैंडशेक नहीं हो सका और कनेक्शन बंद हो जाएगा.


    alt_text

  8. अब मैसेज #9 देखते हैं, ताकि मैसेज प्रोसेसर से भेजे गए सर्टिफ़िकेट का कॉन्टेंट देखा जा सके:


    alt_text

  9. जैसा कि आपको दिख रहा है, बैकएंड सर्वर को क्लाइंट से कोई सर्टिफ़िकेट नहीं मिला (सर्टिफ़िकेट की लंबाई: 0). इसलिए, बैकएंड सर्वर, गंभीर सूचना: गलत सर्टिफ़िकेट भेजता है.
  10. आम तौर पर, ऐसा तब होता है, जब क्लाइंट यानी मैसेज प्रोसेसर (Java पर आधारित प्रोसेस):
    1. इसके KeyStore में कोई क्लाइंट सर्टिफ़िकेट नहीं है या;
    2. यह क्लाइंट सर्टिफ़िकेट नहीं भेज सकता. ऐसा तब हो सकता है, जब उसे ऐसा सर्टिफ़िकेट न मिले जिसे बैकएंड सर्वर के लिए मान्य सर्टिफ़िकेट देने वाली संस्थाओं में से किसी एक ने जारी किया हो. इसका मतलब है कि अगर क्लाइंट के लीफ़ सर्टिफ़िकेट (यानी कि चेन में मौजूद पहला सर्टिफ़िकेट) की सर्टिफ़िकेट अथॉरिटी, बैकएंड सर्वर की स्वीकार की गई किसी भी सर्टिफ़िकेट अथॉरिटी से मेल नहीं खाती है, तो मैसेज प्रोसेसर सर्टिफ़िकेट नहीं भेजेगा.

आइए, इन सभी वजहों के बारे में अलग-अलग जानकारी देखें.

वजह: कोई क्लाइंट सर्टिफ़िकेट नहीं है

संक्रमण की जांच

अगर टारगेट एंडपॉइंट के एसएसएल की जानकारी वाले सेक्शन में बताए गए कीस्टोर या टारगेट एंडपॉइंट में इस्तेमाल किए गए टारगेट सर्वर में कोई सर्टिफ़िकेट नहीं है, तो इस गड़बड़ी की वजह यही है.

यह पता लगाने के लिए कि समस्या की वजह यही है या नहीं, यहां दिया गया तरीका अपनाएं:

  1. नीचे दिया गया तरीका अपनाकर, यह पता लगाएं कि किसी खास एपीआई प्रॉक्सी के लिए, टारगेट एंडपॉइंट या टारगेट सर्वर में कौनसे कीस्टोर का इस्तेमाल किया जा रहा है:
    1. टारगेट एंडपॉइंट या टारगेट सर्वर में, SSLInfo सेक्शन में मौजूद Keystore एलिमेंट से, Keystore का रेफ़रंस नाम पाएं.

      आइए, टारगेट एंडपॉइंट कॉन्फ़िगरेशन में SSLInfo सेक्शन का एक सैंपल देखें:

      <SSLInfo>
  <Enabled>true</Enabled>
  <ClientAuthEnabled>true</ClientAuthEnabled>
  <KeyStore>ref://myKeystoreRef</KeyStore>
  <KeyAlias>myKey</KeyAlias>
  <TrustStore>ref://myTrustStoreRef</TrustStore>
</SSLInfo>
    2. ऊपर दिए गए उदाहरण में, कीस्टोर के रेफ़रंस का नाम "myKeystoreRef" है.
    3. Edge UI पर जाएं और एपीआई प्रॉक्सी -> एनवायरमेंट कॉन्फ़िगरेशन चुनें.

      पहचान फ़ाइलें टैब चुनें और कीस्टोर के रेफ़रंस का नाम खोजें. किसी खास कीस्टोर रेफ़रंस के लिए, रेफ़रंस कॉलम में दिया गया नाम नोट करें. यह आपके कीस्टोर का नाम होगा.


      alt_text

    4. ऊपर दिए गए उदाहरण में, आपको दिखेगा कि myKeystoreRef में "myKeystore" का रेफ़रंस है. इसलिए, कीस्टोर का नाम myKeystore है.
  2. Edge यूज़र इंटरफ़ेस (यूआई) या कीस्टोर के लिए सर्टिफ़िकेट की सूची बनाने वाले एपीआई का इस्तेमाल करके, यह देखें कि इस कीस्टोर में सर्टिफ़िकेट मौजूद है या नहीं.
  3. अगर कीस्टोर में सर्टिफ़िकेट मौजूद हैं, तो वजह: सर्टिफ़िकेट देने वाली संस्था का मेल न खाना पर जाएं.
  4. अगर कीस्टोर में कोई सर्टिफ़िकेट नहीं है, तो मैसेज प्रोसेसर क्लाइंट सर्टिफ़िकेट नहीं भेजता है.

रिज़ॉल्यूशन

  1. पक्का करें कि मैसेज प्रोसेसर में मौजूद किसी खास कीस्टोर में, क्लाइंट सर्टिफ़िकेट की सही और पूरी चेन अपलोड की गई हो.

वजह: सर्टिफ़िकेट देने वाली संस्था का मेल न खाना

आम तौर पर, जब सर्वर, क्लाइंट से अपना सर्टिफ़िकेट भेजने का अनुरोध करता है, तो वह स्वीकार किए गए जारीकर्ताओं या सर्टिफ़िकेट अथॉरिटी के सेट के बारे में बताता है. अगर मैसेज प्रोसेसर के कीस्टोर में मौजूद लीफ़ सर्टिफ़िकेट (यानी कि सर्टिफ़िकेट चेन में मौजूद पहला सर्टिफ़िकेट) का जारीकर्ता/सर्टिफ़िकेट देने वाली संस्था, बैकएंड सर्वर से स्वीकार की गई किसी भी सर्टिफ़िकेट देने वाली संस्था से मेल नहीं खाती है, तो मैसेज प्रोसेसर (जो Java पर आधारित प्रोसेस है) बैकएंड सर्वर को सर्टिफ़िकेट नहीं भेजेगा.

इस बात की पुष्टि करने के लिए, कृपया यह तरीका अपनाएं:

  1. keystore API के लिए सर्टिफ़िकेट की सूची बनाएं.
  2. ऊपर दिए गए पहले चरण में मिले हर सर्टिफ़िकेट की जानकारी पाने के लिए, Get cert for keystore API का इस्तेमाल करें.
  3. Keystore में सेव किए गए लीफ़ सर्टिफ़िकेट (यानी कि सर्टिफ़िकेट चेन में मौजूद पहला सर्टिफ़िकेट) जारी करने वाली संस्था का नाम नोट करें.

    पत्ते के सर्टिफ़िकेट का सैंपल

    {
  "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" है

  4. बैकएंड सर्वर पर स्वीकार किए जाने वाले, जारी करने वालों या सर्टिफ़िकेट देने वाली संस्थाओं की सूची का पता लगाने के लिए, इनमें से किसी एक तकनीक का इस्तेमाल करें:

    पहला तरीका: नीचे दी गई openssl कमांड का इस्तेमाल करें:

    openssl s_client -host <backend server host name> -port <Backend port#> -cert <Client Certificate> -key <Client Private Key>

    इस कमांड के आउटपुट में, "स्वीकार किए जाने वाले क्लाइंट सर्टिफ़िकेट सीए के नाम" सेक्शन देखें. यह सेक्शन यहां दिखाया गया है:

    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 पैकेट की जांच करें. इसमें बैकएंड सर्वर, क्लाइंट से अपना सर्टिफ़िकेट भेजने का अनुरोध करता है:

    ऊपर दिखाए गए सैंपल टीसीपी/आईपी पैकेट में, Certificate Request पैकेट, मैसेज #7 है. "डिस्टिंग्विश्ड नेम" सेक्शन देखें. इसमें बैकएंड सर्वर के लिए, सर्टिफ़िकेट जारी करने वाली मान्य संस्थाओं की जानकारी दी गई है.

    alt_text

  5. पुष्टि करें कि तीसरे चरण में मिली सर्टिफ़िकेट अथॉरिटी, चौथे चरण में मिली बैकएंड सर्वर की स्वीकार की गई सर्टिफ़िकेट अथॉरिटी या जारी करने वाली संस्थाओं की सूची से मेल खाती हो. अगर यह मेल नहीं खाती, तो मैसेज प्रोसेसर, क्लाइंट सर्टिफ़िकेट को बैकएंड सर्वर पर नहीं भेजेगा.

    ऊपर दिए गए उदाहरण में, आपको दिख सकता है कि मैसेज प्रोसेसर के कीस्टोर में मौजूद क्लाइंट के लीफ़ सर्टिफ़िकेट का जारीकर्ता, बैकएंड सर्वर की सर्टिफ़िकेट जारी करने वाली स्वीकार की गई संस्थाओं में से किसी से भी मेल नहीं खाता. इसलिए, मैसेज प्रोसेसर, क्लाइंट सर्टिफ़िकेट को बैकएंड सर्वर पर नहीं भेजता है. इस वजह से, एसएसएल हैंडशेक नहीं हो पाता और बैकएंड सर्वर "Fatal alert: bad_certificate" मैसेज भेजता है.

रिज़ॉल्यूशन

  1. पक्का करें कि जारी करने वाली संस्था/सर्टिफ़िकेट देने वाली संस्था (सीए) का वह सर्टिफ़िकेट, बैकएंड सर्वर के ट्रस्टस्टोर में सेव हो जो क्लाइंट के लीफ़ सर्टिफ़िकेट (चेन में पहला सर्टिफ़िकेट) की जारी करने वाली संस्था/सर्टिफ़िकेट देने वाली संस्था (सीए) से मेल खाता हो.
  2. इस Playbook में दिए गए उदाहरण में, समस्या को हल करने के लिए, जारी करने वाले "issuer" : "CN=MyCompany Test SHA2 CA G2, DC=testcore, DC=test, DC=dir, DC=mycompany, DC=com" वाले सर्टिफ़िकेट को बैकएंड सर्वर के ट्रस्टस्टोर में जोड़ा गया था.

अगर समस्या अब भी बनी रहती है, तो गड़बड़ी की जानकारी इकट्ठा करना पर जाएं.

गड़बड़ी की जानकारी इकट्ठा करना ज़रूरी है

अगर ऊपर दिए गए निर्देशों का पालन करने के बाद भी समस्या बनी रहती है, तो कृपया डाइग्नोस्टिक्स से जुड़ी यह जानकारी इकट्ठा करें. इनसे संपर्क करें और इन्हें Apigee Edge की सहायता टीम के साथ शेयर करें:

  1. अगर आप पब्लिक क्लाउड के उपयोगकर्ता हैं, तो यह जानकारी दें:
    1. संगठन का नाम
    2. एनवायरमेंट का नाम
    3. एपीआई प्रॉक्सी का नाम
    4. गड़बड़ी को फिर से बनाने के लिए, कर्ल कमांड को पूरा करें
    5. गड़बड़ी दिखाने वाली ट्रेस फ़ाइल
    6. बैकएंड सर्वर पर कैप्चर किए गए टीसीपी/आईपी पैकेट
  2. अगर आप Private Cloud के उपयोगकर्ता हैं, तो यह जानकारी दें:
    1. गड़बड़ी का पूरा मैसेज मिला
    2. एपीआई प्रॉक्सी बंडल
    3. गड़बड़ी दिखाने वाली ट्रेस फ़ाइल
    4. मैसेज प्रोसेसर के लॉग /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. बैकएंड सर्वर या मैसेज प्रोसेसर पर कैप्चर किए गए टीसीपी/आईपी पैकेट.
    6. Get cert for keystore API का आउटपुट.
  3. इस प्लेबुक के किन सेक्शन में दिए गए सुझावों को आपने आज़माया है और इस समस्या को तेज़ी से हल करने में मदद करने वाली कोई अन्य अहम जानकारी.