TLS निरीक्षण समस्या निवारण

परिचय

यह लेख TLS निरीक्षण के लिए उन्नत समस्या निवारण परिदृश्यों को कवर करता है। आगे बढ़ने से पहले, यह अनुशंसा की जाती है कि TLS निरीक्षण कॉन्फ़िगरेशन और व्यवहार की समीक्षा करें ताकि यह समझ सकें कि ट्रैफ़िक कैसे प्रोसेस और लागू किया जाता है।

सामान्य परिस्थितियों में, TLS निरीक्षण अंतिम उपयोगकर्ताओं को दिखाई नहीं देता है। यह सत्यापित करने के लिए कि क्या ट्रैफ़िक निरीक्षण किया जा रहा है, खाता इवेंट्स में TLS निरीक्षण फ़ील्ड की जांच करें (1 = निरीक्षित, 0 = बायपास किया गया), ब्राउज़र में प्रमाणपत्र जारीकर्ता की समीक्षा करें (Cato Networks), या TLS निरीक्षण रिपोर्ट का उपयोग करें।

Cato में प्रतिष्ठित एप्लिकेशन, उपकरण और डोमेनों के लिए डिफ़ॉल्ट बायपास नियमों का एक सेट शामिल है। ये सिस्टम-प्रबंधित नियम संपादन योग्य नहीं होते हैं और कस्टम नियम बनाने से पहले हमेशा समीक्षा किया जाना चाहिए। अधिक विवरण के लिए, देखें डिफ़ॉल्ट बायपास नियम

लक्षण

• वेबसाइट लोड नहीं होती है / समय समाप्त होता है

• \u003ca href="#h_01KMZF0JVKTM3KX09DM7T21B8S"\u003eब्राउज़र TLS / प्रमाणपत्र त्रुटियाँ\u003c/a\u003e\u003cbr\u003eउपयोगकर्ता निम्नलिखित त्रुटियाँ देख सकते हैं:

  • "आपका कनेक्शन निजी नहीं है"
  • "सुरक्षित कनेक्शन विफल"
  • ERR_SSL_PROTOCOL_ERROR
  • ERR_SSL_VERSION_OR_CIPHER_MISMATCH
  • ERR_EMPTY_RESPONSE

• अनुप्रयोग काम नहीं कर रहा है या लोड हो रहा है 

• नेटवर्क के बाहर काम करता है (उदा., हॉटस्पॉट) लेकिन Cato के पीछे नहीं

• मान्य प्रमाणपत्र दिखाया गया, लेकिन कनेक्शन विफल

• उपकरण/प्लेटफ़ॉर्म पर असंगत व्यवहार

• अवरुद्ध पेज प्रदर्शित किया गया

संभावित कारण

अधिकांश TLS निरीक्षण समस्याएं कुछ सामान्य परिस्थितियों से संबंधित होती हैं।

• कुछ अनुप्रयोग TLS निरीक्षण के साथ संगत नहीं होते हैं। \u003cstrong data-start="1402" data-end="1463"\u003eप्रमाणपत्र पिनिंग, सख्त TLS मान्यकरण, या आपसी TLS\u003c/strong\u003e का उपयोग करने वाले अनुप्रयोग इंटरसेप्शन को अस्वीकार कर देंगे और कनेक्ट होने में विफल हो जाएंगे।

• क्लाइंट पर प्रमाणपत्र विश्वास समस्याएं एक अन्य सामान्य कारण हैं। यदि Cato रूट प्रमाणपत्र अनुपलब्ध, अनट्रस्टेड, या असंगत रूप से तैनात है, निरीक्षित ट्रैफ़िक विफल होगा, भले ही नीति सही हो।

• अन्य मामलों में, समस्या गंतव्य सर्वर से उत्पन्न होती है। \u003cstrong data-start="1807" data-end="1907"\u003eसमाप्त प्रमाणपत्र, अपूर्ण चेन, होस्टनाम असंगतता, या अज्ञात प्रमाणपत्र प्राधिकरण\u003c/strong\u003e जैसी समस्याएं हमेशा ब्राउज़र में नहीं दिखाई देतीं जब TLS निरीक्षण सक्षम होता है लेकिन PoP द्वारा लागू होती हैं।

• \u003cstrong data-start="2041" data-end="2076"\u003eTLS प्रोटोकॉल या साइफर असंगतता\u003c/strong\u003e के कारण लिगेसी सिस्टम विफल हो सकते हैं। पुराने TLS वर्जन या कमजोर साइफर सूट का उपयोग करने वाले अनुप्रयोग TLS निरीक्षण नीति में परिभाषित आवश्यकताओं को पूरा नहीं कर सकते।

• \u003cstrong data-start="2259" data-end="2289"\u003eकई निर्भर डोमेन\u003c/strong\u003e के कारण आधुनिक वेबसाइटें भी समस्याएं पेश कर सकती हैं। यदि केवल मुख्य डोमेन की अनुमति दी जाती है या बायपास किया जाता है जबकि सहायक डोमेन अवरुद्ध या विभिन्न तरीके से निरीक्षित किए जाते हैं, उपयोगकर्ताओं को धीमी लोडिंग या सामग्री की कमी का अनुभव हो सकता है।

• अंत में, प्लेटफ़ॉर्म-विशिष्ट व्यवहार भूमिका निभाता है। मोबाइल उपकरण, BYOD अंतर्क्रियाएं, और लिनक्स सिस्टम प्रमाणपत्र विश्वास सीमाओं, आवेदन-विशिष्ट मान्यकरण या डिफ़ॉल्ट बायपास नियमों के कारण अलग ढंग से व्यवहार कर सकते हैं।

प्रारंभिक समस्या निवारण

TLS संबंधित समस्याओं की जांच करते समय, प्राथमिक लक्ष्य यह निर्धारित करना है कि समस्या \u003cstrong data-start="1186" data-end="1253"\u003eक्लाइंट, नेटवर्क (TLS निरीक्षण), या गंतव्य सर्वर\u003c/strong\u003e से उत्पन्न होती है।

1. स्कोप अलग करें

यह मान्य करके शुरू करें कि समस्या क्लाइंट-विशिष्ट है। उसी URL का परीक्षण करें:

• किसी भिन्न ब्राउज़र से
• उसी नेटवर्क पर किसी अन्य उपकरण से
• अलग नेटवर्क (उदा., हॉटस्पॉट) में एक ही उपकरण से

यदि समस्या एक विशिष्ट ब्राउज़र या उपकरण पर सीमित है, तो यह आमतौर पर \u003cstrong data-start="1586" data-end="1624"\u003eस्थानीय विश्वास या रूपरेखा समस्या\u003c/strong\u003e को इंगित करता है। यदि यह नेटवर्क के बाहर काम करता है, तो समस्या \u003cstrong data-start="1692" data-end="1732"\u003eTLS निरीक्षण या नीति प्रवर्तन\u003c/strong\u003e से संबंधित होने की संभावना है।

2. TLS निरीक्षण / प्रमाणपत्र जारीकर्ता की जाँच करें

ब्राउज़र से:

• \u003cstrong data-start="1094" data-end="1110"\u003eसुरक्षा टैब\u003c/strong\u003e खोलें या \u003cstrong data-start="1124" data-end="1137"\u003eलॉक आइकन\u003c/strong\u003e पर क्लिक करें
• प्रमाणपत्र चेन की जांच करें

जारीकर्ता की जांच करें:

• \u003cstrong data-start="1195" data-end="1231"\u003eप्रॉक्सी/एंटरप्राइज CA (उदा., Cato)\u003c/strong\u003e → TLS निरीक्षण सक्रिय है
• \u003cstrong data-start="1263" data-end="1308"\u003eसार्वजनिक CA (उदा., DigiCert, Let’s Encrypt)\u003c/strong\u003e → सीधे TLS सत्र

3. क्लाइंट पर प्रमाणपत्र विश्वास की पुष्टि करें

• सुनिश्चित करें कि Cato रूट प्रमाणपत्र ठीक से एंडपॉइंट पर इंस्टॉल किया गया है।

• पुष्टि करें कि रूट प्रमाणपत्र OS ट्रस्ट स्टोर में है:
  • विंडोज पर, \u003cem\u003eकंप्यूटर सर्टिफिकेट मैनेजर\u003c/em\u003e खोलें \u003ccode data-start="2253" data-end="2266"\u003ecertlm.msc\u003c/code\u003e टाइप करके और \u003cem\u003eट्रस्टेड रूट प्रमाणन प्राधिकरण\u003c/em\u003e के अंतर्गत रूट प्रमाणपत्र खोजें
  • मैक पर, \u003cem\u003eकीचेन एक्सेस\u003c/em\u003e खोलें और \u003cem\u003eसिस्टम कीचेन\u003c/em\u003e के अंतर्गत रूट प्रमाणपत्र खोजें
• सिस्टम समय और तारीख की जांच करें
• यदि Cato रूट प्रमाणपत्र एंडपॉइंट से अनुपलब्ध है, तो इसे डाउनलोड करें और \u003ca href="https://support.catonetworks.com/hc/en-us/sections/32060452545821-Installing-the-Cato-Certificate-on-Devices" target="_blank" rel="noopener noreferrer"\u003eडिवाइस पर Cato रूट प्रमाणपत्र स्थापित करने\u003c/a\u003e में बताए अनुसार इंस्टॉल करें

• अनुपलब्ध या गलत विश्वास रूपरेखा त्वरित TLS विफलताओं का कारण बनेगी।

4. क्लाइंट से TLS हैंडशेक का परीक्षण करें

क्लाइंट-साइड टूल का उपयोग करके TLS कनेक्शन का अनुकरण करें और \u003cstrong data-start="200" data-end="245"\u003eहैंडशेक विफल होने का सटीक कारण और स्थान\u003c/strong\u003e को पहचानें। ये उपकरण अक्सर सामान्य ब्राउज़र संदेशों के पीछे छिपी हुई त्रुटियों को उजागर करते हैं।

प्रभावित एंडपॉइंट से निम्न या समान चलाएँ:

curl.exe -v https://\u003cdomain\u003e

यदि ओपनएसएसएल उपलब्ध है:

openssl s_client -connect \u003cdomain\u003e:443 -servername \u003cdomain\u003e

अपेक्षित आउटपुट (सफलता)

* SSL कनेक्शन TLS1.2 / TLS1.3 का उपयोग करके\u003cbr\u003e* सर्वर प्रमाणपत्र:\u003cbr\u003e* विषय: CN=www.google.com\u003cbr\u003e* जारीकर्ता: CN=GTS CA 1C3\u003cbr\u003e\u003e GET / HTTP/1.1\u003cbr\u003e\u003c HTTP/1.1 200 OK

यह महत्वपूर्ण है कि पहले यह निर्धारित करें कि समस्या \u003cstrong data-start="168" data-end="246"\u003eक्लाइंट, गंतव्य सर्वर, या स्वयं TLS निरीक्षण रूपरेखा\u003c/strong\u003e से संबंधित है। 

सामान्य समस्याओं का समस्या निवारण

\u003cstrong data-start="308" data-end="317"\u003eनोट:\u003c/strong\u003e\u003cbr\u003eनीचे सूची की गई समस्याएं TLS निरीक्षण तैनाती में देखे गए सामान्य परिदृश्यों का प्रतिनिधित्व करती हैं। इनमें से कई त्रुटियाँ \u003cstrong data-start="438" data-end="459"\u003eसामान्य\u003c/strong\u003e होती हैं और आपके विशिष्ट वातावरण पर लागू हो सकती हैं या नहीं।\u003cbr\u003eयदि वर्णित लक्षण या समाधान आपके केस के साथ मेल नहीं खाते हैं, तो क्लाइंट मशीन से डायग्नोस्टिक डेटा (उदा., \u003cstrong data-start="643" data-end="674"\u003eSSS, HAR, और PCAP\u003c/strong\u003e) एकत्रित करना और गहरी जांच के लिए समर्थन टिकट उठाना प्रस्तावित है।

विफल अनुप्रयोग का समस्या निवारण 

\u003cstrong data-start="653" data-end="663"\u003eसमस्या: \u003c/strong\u003eकुछ अनुप्रयोग सुरक्षित कनेक्शन स्थापित करने में विफल होते हैं या बाद में TLS निरीक्षण सक्षम होने पर कार्य करना बंद कर देते हैं।

\u003cstrong data-start="778" data-end="805"\u003eव्यवहार की अपेक्षा\u003c/strong\u003e:\u003cbr\u003eकठोर सुरक्षा नियंत्रण वाले अनुप्रयोग (उदा., बैंकिंग ऐप्स, एंडपॉइंट सुरक्षा उपकरण) \u003cstrong data-start="901" data-end="933"\u003eतुरंत कनेक्शन विफल\u003c/strong\u003e कर देंगे, चुपचाप क्रैश हो जाएंगे, या बार-बार कनेक्शन पुनः प्रयास करेंगे। यह होता है क्योंकि TLS निरीक्षण \u003cstrong data-start="1032" data-end="1072"\u003eमैन-इन-द-मिडल (MITM) प्रमाणपत्र\u003c/strong\u003e प्रस्तुत करता है, जिसे ये अनुप्रयोग विशेष रूप से पहचान और अस्वीकार करने के लिए डिज़ाइन किए गए हैं।

\u003cstrong data-start="1321" data-end="1336"\u003eसमाधान:\u003c/strong\u003e\u003cbr\u003eनीति के शीर्ष पर नियम का उपयोग करके \u003cstrong data-start="688" data-end="716"\u003eएकल उपयोगकर्ता या स्रोत IP\u003c/strong\u003e के लिए TLS निरीक्षण को बायपास करके मान्य करें। यदि अनुप्रयोग बायपास किए जाने पर काम करता है, तो लक्षित छूट (डोमेन/FQDN आधारित) बनाएं और व्यापक नियमों से बचें। इसके अलावा, Cato के \u003ca href="https://support.catonetworks.com/hc/en-us/articles/23739970551453-Using-the-TLS-Inspection-Configuration-Wizard"\u003eTLS निरीक्षण कॉन्फ़िगरेशन विजार्ड\u003c/a\u003e का उपयोग संवेदनशील डोमेनों को न्यूनतम रूपरेखा के साथ बायपास करने के लिए किया जा सकता है। 

यदि अनुप्रयोग या सर्वर प्रमाणपत्र पिनिंग या कठोर TLS आवश्यकताओं को लागू करता है, \u003cstrong data-start="958" data-end="994"\u003eTLS निरीक्षण लागू नहीं किया जा सकता है\u003c/strong\u003e। ऐसे मामलों में, उचित दृष्टिकोण यह है कि उस ट्रैफ़िक को \u003cstrong data-start="1038" data-end="1060"\u003eस्थायी रूप से बायपास\u003c/strong\u003e किया जाए।

\u003cstrong data-start="1076" data-end="1088"\u003eउदाहरण:\u003c/strong\u003e\u003cbr\u003eयदि कोई वित्तीय ऐप लॉग इन करने में विफल होता है और उस उपयोगकर्ता के लिए TLS निरीक्षण बायपास करने के बाद तुरंत काम करता है, तो यह असंगतता की पुष्टि करता है - एप्लिकेशन डोमेन को बायपास सूची में जोड़ें। 

ब्राउज़र प्रमाणपत्र की चेतावनी का समस्या निवारण

\u003cstrong data-start="131" data-end="141"\u003eसमस्या: \u003c/strong\u003eउपयोगकर्ता प्रमाणपत्र चेतावनियाँ देखते हैं या TLS निरीक्षण सक्षम करने के बाद अनुप्रयोग विफल होते हैं।

\u003cstrong data-start="228" data-end="255"\u003eव्यवहार की अपेक्षा\u003c/strong\u003e:\u003cbr\u003eउपयोगकर्ता ब्राउज़र चेतावनियों का सामना कर सकते हैं (उदा., \u003cem data-start="302" data-end="327"\u003e"कनेक्शन सुरक्षित नहीं है"\u003c/em\u003e) या पूर्ण कनेक्शन विफलताएँ। व्यवहार उपकरणों में इस पर निर्भर करता है कि Cato प्रमाणपत्र सही तरीके से इंस्टॉल किया गया है या नहीं।

\u003cstrong data-start="591" data-end="606"\u003eसमाधान:\u003c/strong\u003e\u003cbr\u003eसुनिश्चित करें कि \u003cstrong data-start="620" data-end="660"\u003eCato TLS निरीक्षण रूट प्रमाणपत्र\u003c/strong\u003e सभी अंतर्क्रियाओं पर स्थापित और ट्रस्टेड है। \u003cstrong data-start="717" data-end="728"\u003eGPO/MDM\u003c/strong\u003e का उपयोग करके तैनात करें और क्लाइंट पर पूरी प्रमाणपत्र चेन की पुष्टि करें।

यदि निजी/आंतरिक प्रमाणपत्रों का उपयोग किया जाता है, यह सुनिश्चित करें कि वे ठीक से ट्रस्टेड हैं या TLS निरीक्षण प्रमाणपत्र हैंडलिंग प्रक्रियाओं का पालन करें।

यदि व्यवहार असंगत है, \u003cstrong data-start="999" data-end="1024"\u003eएकल उपयोगकर्ता या उपकरण\u003c/strong\u003e के लिए TLS निरीक्षण को बायपास करके इसे मान्य करें ताकि प्रमाणपत्र-संबंधी प्रभाव की पुष्टि हो सके।

यदि आपकी संस्था में निजी प्रमाणपत्रों का उपयोग किया जा रहा है, तो \u003ca href="https://support.catonetworks.com/hc/en-us/articles/10492801153693-Securing-Traffic-with-TLS-Inspection-Using-Private-Certificates"\u003eनिजी प्रमाणपत्रों का उपयोग करते हुए TLS निरीक्षण के साथ ट्रैफ़िक को सुरक्षित करें\u003c/a\u003e पर जाएँ। 

होस्टनाम असंगतता का समस्या निवारण

\u003cstrong data-start="137" data-end="147"\u003eसमस्या: \u003c/strong\u003eउपयोगकर्ताओं को होस्टनाम असंगतता के कारण प्रमाणपत्र त्रुटियाँ या अवरुद्ध कनेक्शन का सामना करना पड़ता है जब विशेष साइट्स को एक्सेस किया जाता है, विशेष रूप से जब TLS निरीक्षण सक्षम होता है।

\u003cstrong data-start="310" data-end="337"\u003eव्यवहार की अपेक्षा\u003c/strong\u003e:\u003cbr\u003eजब कोई सर्वर प्रमाणपत्र प्रस्तुत करता है जिसका सामान्य नाम (CN) या SAN अनुरोधित होस्टनाम से मेल नहीं खाता है, तो कनेक्शन को अमान्य माना जाता है।

बिना TLS निरीक्षण के, ब्राउज़र सीधे इस असंगतता का पता लगता है और एक प्रमाणपत्र चेतावनी प्रदर्शित करता है।

TLS निरीक्षण सक्षम होने के बाद, ब्राउज़र मूल सर्वर के बजाय Cato PoP के साथ TLS सत्र स्थापित करता है। PoP Cato Root CA का उपयोग करके प्रमाणपत्र को पुनः हस्ताक्षरित करता है, इसे क्लाइंट के लिए वैध बनाता है। परिणामस्वरूप, ब्राउज़र में कोई असंगतता नहीं दिखाई जाती है, भले ही यह समस्या बैकएंड में मौजूद हो।

\u003cstrong data-start="907" data-end="922"\u003eसमाधान:\u003c/strong\u003e\u003cbr\u003eएक विशिष्ट उपयोगकर्ता या स्रोत IP के लिए TLS निरीक्षण को बायपास करके व्यवहार मान्य करें। यदि ब्राउज़र तब होस्टनाम असंगतता त्रुटि दिखाता है, तो यह पुष्टि करता है कि समस्या गंतव्य सर्वर से उत्पन्न होती है।

चूँकि असंगतता सर्वर के प्रमाणपत्र रूपरेखा के कारण होती है, इसे TLS निरीक्षण द्वारा सुधारा नहीं जा सकता। उचित कार्रवाई यह है कि या तो:

• विशिष्ट डोमेन के लिए TLS निरीक्षण को बायपास करते हुए पहुँच की अनुमति दें, या
• यदि असंगतता सुरक्षा जोखिम मानी जाती है तो नीति के आधार पर ट्रैफ़िक को अवरुद्ध करें।

व्यापक बायपास नियमों से बचें और आवश्यकता के अनुसार लक्षित डोमेन/FQDN छूटों का उपयोग करें।

\u003cstrong data-start="1530" data-end="1542"\u003eउदाहरण:\u003c/strong\u003e\u003cbr\u003e\u003ccode data-start="1560" data-end="1597"\u003ehttps://www.testingmcafeesites.com/\u003c/code\u003e तक पहुँचते समय, सर्वर \u003ccode data-start="1637" data-end="1664"\u003eplatformsplat1.mcafee.com\u003c/code\u003e के लिए प्रमाणपत्र प्रस्तुत करता है।

बिना TLS निरीक्षण के, ब्राउज़र तुरंत एक होस्टनाम असंगतता पर ध्यान देता है।

TLS निरीक्षण सक्षम होने पर, ब्राउज़र \u003ccode data-start="1844" data-end="1872"\u003ewww.testingmcafeesites.com\u003c/code\u003e के लिए Cato Root CA द्वारा जारी एक वैध प्रमाणपत्र देखता है, इसलिए कोई त्रुटि प्रदर्शित नहीं होती। हालांकि, Cato PoP बैकग्राउंड में असंगतता का पता लगाता है और रूपरेखा की गई नीति (अवरुद्ध या चेतावनी) को लागू करता है।

वेबसाइट या अनुप्रयोग लोडिंग समस्याओं का समस्या निवारण

\u003cstrong data-start="100" data-end="110"\u003eसमस्या: \u003c/strong\u003eवेबसाइटें लोड करने में विफल होती हैं, आंशिक रूप से रेंडर करती हैं, या TLS निरीक्षण सक्षम होने पर अप्रत्याशित रूप से व्यवहार करती हैं।

व्यवहार की अपेक्षा:

• पृष्ठ लटक सकते हैं, अनिश्चित रूप से लोड हो सकते हैं, या आंशिक रूप से रेंडर कर सकते हैं
• लॉगिन/प्रमाणीकरण प्रवाह विफल हो सकता है या लूप कर सकता है
• कुछ साइटें TLS डिक्रिप्शन/पुनः एनक्रिप्शन ओवरहेड के कारण धीमी दिखाई दे सकती हैं
• व्यवहार असंगत हो सकता है (उदा., एक नेटवर्क पर काम करता है, Cato के माध्यम से विफल)

यह आमतौर पर \u003cstrong data-start="532" data-end="610"\u003eकठोर सुरक्षा नियंत्रण या जटिल TLS निर्भरताएँ का उपयोग करने वाले आधुनिक वेब ऐप्स के\u003c/strong\u003e के साथ देखा जाता है।

समाधान:
एक विशिष्ट उपयोगकर्ता या स्रोत आईपी के लिए TLS निरीक्षण को बायपास करके मान्य करें। अगर साइट बायपास करने पर काम करती है, तो लक्षित डोमेन/FQDN विशिष्ट अपवर्जन बनाएं।

व्यापक बायपास नियमों से बचें — केवल आवश्यक डोमेन्स को स्कोप अपवर्जित करें।

यदि अनुप्रयोग कठोर सुरक्षा तंत्रों (जैसे, पिन किए गए सर्टिफिकेट या उन्नत TLS हैंडलिंग) पर निर्भर करता है, निरीक्षण समर्थित नहीं हो सकता, और बायपास सही दृष्टिकोण है।

परिदृश्य – आधुनिक वेब अनुप्रयोग (SaaS):
कुछ SaaS प्लेटफ़ॉर्म (जैसे, कई बैकएंड डोमेन्स/CDNs वाले ऐप्स) आंशिक रूप से लोड हो सकते हैं (यूआई काम करेगा, APIs विफल होंगे)। इन मामलों में, HAR/DevTools के माध्यम से सभी आवश्यक डोमेन्स की पहचान करें और बायपास नियम में पूर्ण कवरेज सुनिश्चित करें।

Cato प्रमाणपत्र सत्यापन त्रुटि समाधान

समस्या: Cato TLS-संबंधित त्रुटियां ब्राउज़िंग या अनुप्रयोग उपयोग के दौरान दिखाई देती हैं।

व्यवहारिक अपेक्षा:

उपयोगकर्ता सामान्य त्रुटियों का सामना कर सकते हैं जैसे: 

• "सुरक्षित कनेक्शन विफल"
• "प्रमाणपत्र विश्वसनीय नहीं है"
• अनपेक्षित कनेक्शन रीसेट्स या ड्रॉप्स

ये त्रुटियां आमतौर पर गैर-विशिष्ट होती हैं और स्पष्ट रूप से सूचित नहीं करती हैं कि समस्या क्लाइंट, सर्वर, या TLS निरीक्षण प्रक्रिया से उत्पन्न होती है।

समाधान:
एकल उपयोगकर्ता या स्रोत आईपी के लिए अस्थायी रूप से TLS निरीक्षण के बायपास द्वारा व्यवहार को मान्य करें।

• यदि समस्या बायपास में समाधान होती है, तो यह निरीक्षण के दौरान प्रमाणपत्र सत्यापन विफलता की पुष्टि करता है।
• मध्यवर्ती या जारी करने वाले CAs पहचानने में सफल नहीं होने पर, यह संभवतः प्रमाणपत्र के Cato के विश्वसनीय प्रमाणपत्र बंडल में शामिल नहीं होने के कारण है।

एक अस्थायी समाधान के रूप में, प्रभावित डोमेन/अनुप्रयोग के लिए TLS निरीक्षण को बायपास करने और समर्थन मामले खोलने की सिफारिश की जाती है।

Cato उद्योग मानकों के साथ अनुरूप अपने विश्वसनीय प्रमाणपत्र बंडल को लगातार अपडेट करता है और सबसे सामान्य उपयोग की जाने वाली प्रमाणपत्र प्राधिकरणों के साथ। यदि प्रमाणपत्र मान्य और व्यापक रूप से विश्वसनीय है, तो यह भविष्य के अपडेट में जोड़ा जाने की संभावना है।

स्थायी सुधार का ध्यान केंद्रित करें:

• सर्वर द्वारा एक पूर्ण और मान्य प्रमाणपत्र श्रृंखला प्रस्तुत करने की सुनिश्चितता।
• जानी-पहचानी, विश्वसनीय CAs द्वारा जारी किए गए प्रमाणपत्रों का उपयोग करना।

यदि सर्वर एक अस्थायी या अपूर्ण प्रमाणपत्र श्रृंखला प्रस्तुत करता है, तो TLS निरीक्षण सही ढंग से कनेक्शन को अवरुद्ध करेगा। सर्वर साइड पर सुधार किया जाना चाहिए, या आवश्यक हो तो TLS निरीक्षण को बायपास करें।

नए विश्वसनीय / हाल ही में प्रकाशित डोमेन्स

वे डोमेन्स जिन्हें नए प्रकाशित, हाल ही में अपडेट किया गया, या इंटरनेट पर फिर से वर्गीकृत किया गया हो सकता है, सभी प्रतिष्ठा इंजन, प्रमाणपत्र प्राधिकरण, या विश्वास स्टोर के पारंपरिक रूप से असमान रूप से पहचाने नहीं जाते हैं।

यह कुछ मामलों में ट्रैफ़िक को अवरुद्ध करने या फ्लैगित करने की स्थिति में होता है — सिर्फ TLS विफलता की वजह से नहीं, बल्कि इंटरनेट फ़ायरवॉल नीतियों द्वारा सुरक्षा प्रवर्तन या अपूर्ण प्रमाणपत्र विश्वास के परिणामस्वरूप।

व्यवहारिक अपेक्षा:
ऐसे डोमेन्स हो सकते हैं:

• सुरक्षा इंजन के माध्यम से गलत वर्गीकृत या असंगत रूप से वर्गीकृत।
• प्रमाणपत्र प्रस्तुत करना जो वैश्विक रूप से पूरी तरह से प्रसारित या भरोसा नहीं किया जाता।
• अपूर्ण विश्वास श्रृंखलाओं के कारण निरीक्षण के दौरान TLS त्रुटियों को ट्रिगर करना।
• नीति के आधार पर अवरुद्ध किया जाना न कि वास्तविक कनेक्टिविटी समस्या।

यह व्यवहार सामान्य होता है जब एक डोमेन सक्रिय होता है या परिवर्तन से गुजरता है।

समाधान:

• प्रमाणपत्र की अंत बिंदु से सीधे पुष्टि करें ताकि वैधता सुनिश्चित हो सके।
• यदि डोमेन सुरक्षित रूप से सत्यापित होता है:
  • इसे नीति आवश्यकताओं के आधार पर अनुमत श्रेणी में फिर से वर्गीकृत करें, या
  • लक्षित अनुमति/बायपास नियम बनाएं (व्यापक अपवर्जनों से बचें)
• जहां संभव हो, बायपास नियमों का अस्थायी रूप से उपयोग करें।
• कुछ समय बाद डोमेन को पुनःमूल्यांकन करें, एक बार जब इसकी प्रतिष्ठा और प्रमाणपत्र विश्वास वैश्विक रूप से पूरी तरह से स्थापित हो जाए।

मुख्य नोट:
भले ही एक डोमेन वैध हो, अपूर्ण प्रमाणपत्र प्रचार अभी भी TLS-संबंधित त्रुटियों का कारण बन सकता है। इन मामलों में, व्यवहार अपेक्षित होता है और इसे गलत कॉन्फ़िगरेशन मानने के बजाय नियंत्रण नीति समायोजन के माध्यम से संभाला जाना चाहिए।

परिदृश्य – अपूर्ण प्रमाणपत्र श्रृंखला:
एक साइट सीधे ब्राउज़र में काम कर सकती है (कैश्ड इंटरमीडिएट्स के कारण), लेकिन TLS निरीक्षण के तहत विफल हो सकती है। यह संकेत देता है कि सर्वर पूर्ण प्रमाणपत्र श्रृंखला प्रस्तुत नहीं कर रहा है। समाधान है सर्वर कॉन्फ़िगरेशन को ठीक करें या डोमेन को बायपास करें।

असमर्थित प्रोटोकॉल और विरासत प्रणालियाँ

समस्या:
अनुप्रयोगों या प्रणालियों के लिए कनेक्शन विफल होते हैं जो पुराने TLS संस्करणों या कमजोर साइफर सूट का उपयोग कर रहे हैं जो TLS निरीक्षण के तहत समर्थित नहीं हैं।

व्यवहारिक अपेक्षा:
विफलताएँ आमतौर पर TLS हैंडशेक के दौरान होती हैं और ब्राउज़र या क्लाइंट में सीधे दिखाई देती हैं।

सामान्य ब्राउज़र त्रुटियों में शामिल हैं:

• ERR_SSL_PROTOCOL_ERROR
• ERR_EMPTY_RESPONSE
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH
• ERR_CONNECTION_CLOSED

• 400 खराब अनुरोध
  कोई आवश्यक SSL प्रमाणपत्र नहीं भेजा गया

कुछ मामलों में:

• पृष्ठ पूरी तरह से लोड करने में विफल हो सकता है
• कनेक्शन तुरंत रीसेट हो सकता है
• थिक क्लाइंट या विरासत ऐप्स चुपचाप विफल हो सकते हैं या सामान्य कनेक्शन त्रुटियां दिखा सकते हैं

यह इसलिए होता है क्योंकि क्लाइंट या सर्वर MITM के रूप में कार्य कर रहे Cato PoP के साथ संगत TLS संस्करण या साइफर सूट का बातचीत नहीं कर सकते।

घटनाओं में, आप देखेंगे कि TLS त्रुटि विवरण क्षेत्र में विशेष जानकारी भरी हुई है। 

अधिक जानने के लिए त्रुटियों पर Understanding TLS errors विजिट करें। 

समाधान:

• अस्थायी रूप से एक विशिष्ट उपयोगकर्ता या स्रोत आईपी के लिए TLS निरीक्षण को बायपास करें ताकि व्यवहार को मान्य किया जा सके।
• यदि अनुप्रयोग बायपास में काम करता है → निरीक्षण के दौरान TLS बातचीत असंगति की पुष्टि करता है।

अगले चरण में, TLS क्षमताओं को जांचने के लिए बाहरी टूल का उपयोग करें जैसे https://www.ssllabs.com/ssltest/

अपने TLS निरीक्षण नीति के साथ परिणामों की तुलना करें:

• न्यूनतम अनुमत TLS संस्करण
• साइफ़र सूट प्रवर्तन स्तर

यदि पुष्टि की गई:

• आधुनिक TLS संस्करण और मजबूत साइफ़र सूट का समर्थन करने के लिए अनुप्रयोग या सर्वर को अपडेट या अपग्रेड करें।
• यदि अपग्रेड व्यवहार्य नहीं हैं, तो प्रभावित अनुप्रयोग या डोमेन के लिए लक्षित TLS निरीक्षण बायपास को कॉन्फ़िगर करें।

नोट:
डिफ़ॉल्ट रूप से, Cato TLS संस्करण और साइफ़र सूट की विस्तृत सीमा की अनुमति देता है। हालांकि, प्रशासक TLS निरीक्षण नीति में सख्त नियंत्रण लागू कर सकते हैं (जैसे, न्यूनतम TLS संस्करण या साइफ़र ताकत), जो विरासत अनुप्रयोगों को विफल कर सकता है। अधिक जानकारी के लिए यहां पढ़ें

परिदृश्य – विरासत आंतरिक अनुप्रयोग:
एक आंतरिक या थर्ड पार्टी विरासत अनुप्रयोग केवल तब विफल हो सकता है जब Cato के माध्यम से रूट किया जाता है और TLS निरीक्षण सक्षम होता है, लेकिन जब बायपास में काम करता है। यह आम तौर पर अप्रचलित TLS संस्करणों पर निर्भरता को इंगित करता है, जिसके लिए अनुप्रयोग अपग्रेड या स्थायी बायपास की आवश्यकता होती है।

OS-विशिष्ट TLS मुद्दों (अपेक्षित सीमाएं) के निवारण का उपाय

समस्या: कनेक्टिविटी मुद्दे, असंगत व्यवहार, या कुछ ऑपरेटिंग सिस्टम्स और डिवाइस प्रकारों पर TLS निरीक्षण दृश्यता की कमी (जैसे, मोबाइल, BYOD, Linux)।

व्यवहारिक अपेक्षा:

व्यवहार ऑपरेटिंग सिस्टम और अनुप्रयोग डिज़ाइन के आधार पर महत्वपूर्ण रूप से बदलता है।

Android और Linux उपकरणों के लिए, प्रमाणपत्र विश्वास सीमाओं और अनुप्रयोग व्यवहार के कारण डिफ़ॉल्ट रूप से TLS निरीक्षण बायपास किया जाता है। हालांकि, नई कॉन्फ़िगरेशन (CMA में उन्नत सेटिंग्स के माध्यम से) प्रशासकों को इन प्लेटफार्मों पर TLS निरीक्षण लागू करने की अनुमति देती है, बशर्ते प्रमाणपत्र विश्वास सही ढंग से स्थापित हो।

iOS उपकरणों के लिए, TLS निरीक्षण समर्थित है, लेकिन कई अनुप्रयोग (जैसे, सोशल मीडिया प्लेटफ़ॉर्म जैसे Instagram, Facebook और समान ऐप्स) पिनिंग प्रमाणपत्र और ज्ञात असंगताओं के कारण डिफ़ॉल्ट द्वारा बायपास किया जाता है। अन्य अनुप्रयोग जो कठोर सत्यापन लागू करते हैं, विफल हो सकते हैं और मैन्युअल बायपास कॉन्फ़िगरेशन की आवश्यकता हो सकती है।

सामान्य रूप से:

• Cato प्रमाणपत्र इंस्टॉल होने के बाद, ब्राउज़र अपेक्षित रूप से काम कर सकते हैं।
• स्थानीय/मोबाइल अनुप्रयोग तुरंत विफल हो सकते हैं प्रमाणपत्र पिनिंग या प्रतिबंधित विश्वास स्टोर के कारण।
• व्यवहार एक ही उपकरण पर भी अनुप्रयोग दर अनुप्रयोग अलग हो सकता है।

समाधान:

ये व्यवहार सामान्य रूप से अपेक्षित और प्लेटफ़ॉर्म संचालित होते हैं, गलत कॉन्फ़िगरेशन का संकेत नहीं।

• एक्सेल का प्रदर्शन TLS निरीक्षण मुख्य रूप से प्रबंधित उपकरणों पर लागू करें जहां प्रमाणपत्र परिनियोजन नियंत्रित होता है।
• MDM समाधान का उपयोग करके Cato प्रमाणपत्र को सिस्टम स्तर पर इंस्टॉल करें (जहाँ समर्थनित)।
• अच्छी तरह से ज्ञात अनुप्रयोगों और प्लेटफार्मों के लिए डिफ़ॉल्ट बायपास नियमों से अवगत रहें।
• अनुप्रयोग जो प्रमाणपत्र पिनिंग या कठोर सत्यापन के कारण विफल होते हैं, एक लक्षित TLS निरीक्षण बायपास कॉन्फ़िगर करें।
• एंड्रॉयड या लिनक्स जैसे प्लेटफार्मों पर TLS निरीक्षण लागू करते समय, व्यापक रोलआउट से पहले संगतता को सावधानीपूर्वक मान्य करें।

परिदृश्य – मोबाइल अनुप्रयोग विफलता:
एक मोबाइल ऐप (जैसे, बैंकिंग या सुरक्षा ऐप) Cato पर कनेक्ट करने में विफल हो जाता है, जबकि ब्राउज़र काम करता है। ऐप प्रमाणपत्र पिनिंग को लागू करता है और Cato प्रमाणपत्र पर विश्वास नहीं करता। यह अपेक्षित है — उचित कार्रवाई अनुप्रयोग या सेवा के लिए TLS निरीक्षण को बायपास करना है।

Cato समर्थन में मामलों को उठाना

अगर अनुपालन या नियामक कारणों के कारण एक अनुप्रयोग के लिए TLS निरीक्षण अनिवार्य है या यदि आप सोचते हैं कि TLS अवरोध अप्रत्याशित है, तो कृपया इन अनुमानों के परिणामों के साथ समर्थन टिकट सबमिट करें। कृपया टिकट में निम्नलिखित जानकारी शामिल करें:

• अनुभव की गई समस्या और उपयोगकर्ताओं पर समग्र प्रभाव का विवरण। समस्या का अनुभव करने वाले उपयोगकर्ता का समयमुद्रिका/समयक्षेत्र। 
• संबंधित घटनाएँ और फ़ायरवॉल/TLS नियम कॉन्फ़िगरेशन।
• समस्या को पुन: उत्पन्न करें और समर्थन स्वयं सेवा चलाएँ। उपकरण द्वारा उत्पन्न टिकट संख्या शामिल करें।