कंपनी की CA फ़ाइल पहला URL ठीक करती है, फिर एक रीडायरेक्ट सत्यापन में विफल हो जाता है। जाँचें कि कस्टम CA विकल्प ने क्लाइंट के पिछले विश्वास इनपुट को बदला है या उसमें जोड़ा है।

यह व्यवहार TLS बैकएंड और विकल्प पर निर्भर करता है। केवल कॉर्पोरेट CA वाली फ़ाइल क्लाइंट को उसकी आवश्यक अन्य प्राधिकृतियों के बिना छोड़ सकती है।

  1. हर साथी का अनुसरण करें। पहला होस्ट कॉर्पोरेट जारीकर्ता के अंतर्गत रोका जा सकता है। बाद का होस्ट बायपास, दूसरा निरीक्षण पथ या सार्वजनिक रूप से जारी श्रृंखला का उपयोग कर सकता है।
  2. विफल क्लाइंट के इनपुट दर्ज करें। अनुरोधित होस्टनाम, रीडायरेक्ट लक्ष्य, प्राप्त जारीकर्ता, सत्यापन परिणाम और चुना गया विश्वास कॉन्फ़िगरेशन रखें। काम करने वाला ब्राउज़र दूसरा रूट स्टोर उपयोग कर सकता है।
  3. बैकएंड के चयन नियम जाँचें। curl बिल्ड मूल सत्यापन या फ़ाइल-आधारित रूट उपयोग कर सकते हैं, और स्पष्ट CA विकल्प उस चयन को बदल सकते हैं। उस निष्पादन योग्य के लिए रेसिपी Python वातावरण या JVM कॉन्फ़िगर नहीं करती।

रखरखाव वाला बंडल या समर्थित विश्वास-स्टोर व्यवस्था उपयोग करें जिसमें वे सार्वजनिक और निजी प्राधिकृतियाँ हों जिन पर एप्लिकेशन को भरोसा करना है। CA की निजी कुंजी न जोड़ें और केवल अगली त्रुटि हटाने के लिए हर विफल लीफ़ प्रमाणपत्र को रूट में न बढ़ाएँ।

विश्वास सामग्री को परिनियोजन के समर्थित अद्यतन पथ से पहुँचाएँ। विक्रेता के CA पैकेज को हाथ से बदलना उसके अगले अद्यतन से पूर्ववत हो सकता है; स्वामी और रखरखाव प्रक्रिया स्पष्ट रखें ताकि सत्यापन पूरे अनुरोध मार्ग पर जारी रहे।

संबंधित लेख