Google Maps Platform रूट CA माइग्रेशन के बारे में अक्सर पूछे जाने वाले सवाल

इस दस्तावेज़ में नीचे दिए गए सेक्शन शामिल हैं:

Google रूट CA से होने वाले माइग्रेशन की ज़्यादा जानकारी के लिए, क्या हो रहा है? पर जाएं.

शब्दावली

नीचे, हमने उन सबसे महत्वपूर्ण शर्तों की एक सूची दी है, जिन्हें इस दस्तावेज़ के बारे में आपके लिए पता होना चाहिए. मिलती-जुलती शब्दावली की ज़्यादा जानकारी के लिए, कृपया Google Trust Services के बारे में अक्सर पूछे जाने वाले सवाल देखें.

एसएसएल/TLS सर्टिफ़िकेट
सर्टिफ़िकेट, क्रिप्टोग्राफ़िक कुंजी को किसी पहचान से जोड़ता है.
एसएसएल/TLS सर्टिफ़िकेट का इस्तेमाल, वेबसाइटों की पुष्टि करने और उनके साथ सुरक्षित कनेक्शन बनाने के लिए किया जाता है. सर्टिफ़िकेट, सर्टिफ़िकेट देने वाली संस्था या निकाय की ओर से जारी किए जाते हैं और उन पर क्रिप्टोग्राफ़िक तरीके से हस्ताक्षर किए जाते हैं.
ब्राउज़र, यह जानने के लिए भरोसेमंद सर्टिफ़िकेट अथॉरिटी के जारी किए गए सर्टिफ़िकेट का इस्तेमाल करते हैं कि ट्रांसमिट की गई जानकारी सही सर्वर पर भेजी जाती है और ट्रांसफ़र के दौरान उसे एन्क्रिप्ट (सुरक्षित) किया जाता है.
सिक्योर सॉकेट लेयर (एसएसएल)
इंटरनेट कम्यूनिकेशन को एन्क्रिप्ट (सुरक्षित) करने के लिए, सिक्योर सॉकेट लेयर सबसे ज़्यादा इस्तेमाल किया जाने वाला प्रोटोकॉल था. एसएसएल प्रोटोकॉल को अब सुरक्षित नहीं माना जाता है और इसका इस्तेमाल नहीं किया जाना चाहिए.
ट्रांसपोर्ट लेयर सुरक्षा (TLS)
ट्रांसपोर्ट लेयर सिक्योरिटी, एसएसएल की सुविधा है.
सर्टिफ़िकेट देने वाली संस्था (सीए)
सर्टिफ़िकेट अथॉरिटी, डिवाइसों और लोगों के लिए एक डिजिटल पासपोर्ट ऑफ़िस की तरह काम करती है. यह क्रिप्टोग्राफ़िक तरीके से सुरक्षित किए गए दस्तावेज़ (सर्टिफ़िकेट) जारी करके, यह प्रमाणित करता है कि कोई इकाई (जैसे कि वेबसाइट) वह है जो वह होने का दावा करती है.
सर्टिफ़िकेट देने से पहले सीए को इस बात की पुष्टि करनी होती है कि उसमें दिए गए नाम, अनुरोध करने वाले व्यक्ति या इकाई से जुड़े हैं.
सर्टिफ़िकेट अथॉरिटी शब्द का मतलब, Google Trust Services जैसे संगठनों और सर्टिफ़िकेट जारी करने वाले सिस्टम, दोनों से हो सकता है.
रूट सर्टिफ़िकेट स्टोर
रूट सर्टिफ़िकेट स्टोर में, सर्टिफ़िकेट देने वाली संस्थाओं का एक ऐसा सेट शामिल होता है जो ऐप्लिकेशन सॉफ़्टवेयर सप्लायर के भरोसेमंद सर्टिफ़िकेट के लिए काम करता है. ज़्यादातर वेब ब्राउज़र और ऑपरेटिंग सिस्टम का अपना खुद का रूट सर्टिफ़िकेट स्टोर होता है.
रूट सर्टिफ़िकेट स्टोर में शामिल होने के लिए, सर्टिफ़िकेट देने वाली संस्था को ऐप्लिकेशन सॉफ़्टवेयर सप्लायर की तय की गई सख्त शर्तें पूरी करनी होंगी.
आम तौर पर, इनमें इंडस्ट्री स्टैंडर्ड का पालन करना शामिल होता है. जैसे, सीए/ब्राउज़र फ़ोरम की ज़रूरी शर्तें.
रूट सर्टिफ़िकेट अथॉरिटी
सर्टिफ़िकेट चेन में सबसे ऊपर दिया जाने वाला सर्टिफ़िकेट, रूट सर्टिफ़िकेट अथॉरिटी (या इसका सही सर्टिफ़िकेट, उसका सर्टिफ़िकेट) होता है.
आम तौर पर, रूट सीए सर्टिफ़िकेट खुद ही हस्ताक्षर किए जाते हैं. इनसे जुड़ी निजी कुंजियां, बहुत सुरक्षित जगहों पर रखी जाती हैं. साथ ही, इन्हें बिना अनुमति वाले ऐक्सेस से सुरक्षित रखने के लिए, इनका ऑफ़लाइन रखरखाव किया जाता है.
इंटरमीडिएट सर्टिफ़िकेट अथॉरिटी
इंटरमीडिएट सर्टिफ़िकेट अथॉरिटी या इसका सर्टिफ़िकेट एक ऐसा सर्टिफ़िकेट होता है जिसका इस्तेमाल, किसी सर्टिफ़िकेट चेन में दूसरे सर्टिफ़िकेट पर हस्ताक्षर करने के लिए किया जाता है.
इंटरमीडिएट सीए, मुख्य रूप से ऑनलाइन सर्टिफ़िकेट जारी करने की सुविधा चालू करने के लिए मौजूद हैं, जबकि रूट सीए सर्टिफ़िकेट को ऑफ़लाइन रहने में मदद करते हैं.
इंटरमीडिएट सीए को सबऑर्डिनेट सीए भी कहा जाता है.
सर्टिफ़िकेट देने वाली संस्था
सर्टिफ़िकेट देने वाली संस्था या उसका सर्टिफ़िकेट, एक सर्टिफ़िकेट होता है. इसका इस्तेमाल, सर्टिफ़िकेट की चेन में सबसे नीचे मौजूद सर्टिफ़िकेट पर हस्ताक्षर करने के लिए किया जाता है.
सबसे नीचे वाले सर्टिफ़िकेट को आम तौर पर, सदस्यता सर्टिफ़िकेट, एंड-इकाई सर्टिफ़िकेट या लीफ़ सर्टिफ़िकेट कहा जाता है. इस दस्तावेज़ में, हम सर्वर सर्टिफ़िकेट शब्द का भी इस्तेमाल करेंगे.
सर्टिफ़िकेट की चेन
सर्टिफ़िकेट, जारी करने वाले व्यक्ति या कंपनी से लिंक होते हैं. इन्हें एन्क्रिप्ट (सुरक्षित) किया जाता है. सर्टिफ़िकेट की चेन, लीफ़-सर्टिफ़िकेट, उसे जारी करने वाले सभी सर्टिफ़िकेट, और एक रूट सर्टिफ़िकेट से बनी होती है.
क्रॉस-हस्ताक्षरिंग
ऐप्लिकेशन सॉफ़्टवेयर सप्लायर के क्लाइंट को अपना रूट सर्टिफ़िकेट स्टोर अपडेट करना होगा, ताकि नए सीए सर्टिफ़िकेट शामिल किए जा सकें, ताकि उनके प्रॉडक्ट पर भरोसा किया जा सके. नए सीए सर्टिफ़िकेट वाले प्रॉडक्ट, बड़े पैमाने पर इस्तेमाल किए जाने में कुछ समय लग सकता है.
पुराने क्लाइंट के साथ काम करने के लिए, सीए सर्टिफ़िकेट को किसी दूसरे पुराने सीए की मदद से "क्रॉस साइन" किया जा सकता है. इससे एक जैसी पहचान (नाम और कुंजी का जोड़ा) के लिए, असरदार तरीके से एक दूसरा CA सर्टिफ़िकेट बन जाता है.
अपने रूट सर्टिफ़िकेट स्टोर में शामिल सीए के आधार पर, क्लाइंट अपने भरोसेमंद रूट के लिए एक अलग सर्टिफ़िकेट चेन बनाएंगे.

सामान्य जानकारी

क्या हो रहा है?

पूरा देखें

साल 2017 में, Google ने अपने रूट सर्टिफ़िकेट जारी करने और उनका इस्तेमाल करने के लिए कई साल वाला प्रोजेक्ट शुरू किया. ये ऐसे क्रिप्टोग्राफ़िक हस्ताक्षर हैं जो एचटीटीपीएस में इस्तेमाल किए जाने वाले TLS इंटरनेट सुरक्षा के आधार पर काम करते हैं.

पहले चरण के बाद, Google Maps Platform की सेवाओं की TLS सुरक्षा की गारंटी GS Root R2 से मिली है. GS Root R2, एक जाने-माने और बड़े स्तर पर भरोसेमंद रूट सर्टिफ़िकेट अथॉरिटी (CA) है. इसे Google ने GMO GlobalSign से हासिल किया है. इससे, खुद से जारी की जाने वाली Google Trust Services (GTS) के रूट सीए में ट्रांज़िशन की प्रोसेस को आसान बनाने में मदद मिलती है.

आम तौर पर, सभी TLS क्लाइंट (जैसे कि वेब ब्राउज़र, स्मार्टफ़ोन, और ऐप्लिकेशन सर्वर) ने इस रूट सर्टिफ़िकेट पर भरोसा किया है. इसलिए, वे माइग्रेशन के पहले चरण में ही Google Maps Platform के सर्वर से सुरक्षित कनेक्शन बन पाए.

हालांकि, सीए डिज़ाइन के हिसाब से ऐसे सर्टिफ़िकेट जारी नहीं कर सकता जो उसके सर्टिफ़िकेट की समयसीमा खत्म होने के बाद मान्य हों. GS Root R2 की समयसीमा 15 दिसंबर, 2021 को खत्म हो जाएगी. इसलिए, Google अपनी सेवाओं को नए सीए, GTS Root R1 क्रॉस पर माइग्रेट करेगा. इसके लिए, वह Google के रूट सीए GTS Root R1 से जारी किया गया सर्टिफ़िकेट इस्तेमाल करेगा.

ज़्यादातर आधुनिक ऑपरेटिंग सिस्टम और TLS क्लाइंट लाइब्रेरी पहले से ही GTS रूट सीए पर भरोसा करती हैं, ताकि यह भी पक्का किया जा सके कि ज़्यादातर लेगसी सिस्टम पर बिना किसी रुकावट के ट्रांज़िशन हो, Google ने GlobalSign Root CA - R1 का इस्तेमाल करके GMO GlobalSign से क्रॉस-साइन लिया है. यह फ़िलहाल उपलब्ध सबसे पुराने और सबसे भरोसेमंद रूट CA में से एक है.

इसलिए, Google Maps Platform के ज़्यादातर क्लाइंट इन भरोसेमंद रूट सीए में से किसी एक (या दोनों) को पहले से ही पहचान लेंगे और माइग्रेशन के दूसरे चरण का पूरी तरह से कोई असर नहीं पड़ेगा.

यह उन ग्राहकों पर भी लागू होता है जिन्होंने 2018 में माइग्रेशन के पहले चरण के दौरान कार्रवाई की थी, यह मानते हुए कि उस समय उन्होंने हमारे निर्देशों का पालन किया था और Google के भरोसेमंद रूट सीए बंडल से सभी सर्टिफ़िकेट इंस्टॉल किए थे.

अगर नीचे दी गई शर्तें लागू होती हैं, तो आपको अपने सिस्टम की पुष्टि करनी चाहिए:

  • आपकी सेवाएं नॉन-स्टैंडर्ड या लेगसी प्लैटफ़ॉर्म पर चलती हैं और/या जिन पर आपका खुद का रूट सर्टिफ़िकेट स्टोर है
  • आपने 2017-2018 में, Google के रूट CA माइग्रेशन के पहले चरण के दौरान कोई कार्रवाई नहीं की थी या आपने Google के भरोसेमंद रूट सीए बंडल से मिले सर्टिफ़िकेट का पूरा सेट इंस्टॉल नहीं किया था

अगर ऊपर दी गई जानकारी लागू होती है, तो आपके क्लाइंट को सुझाए गए रूट सर्टिफ़िकेट अपडेट करने पड़ सकते हैं. इससे माइग्रेशन के दौरान, Google Maps Platform का इस्तेमाल बिना किसी रुकावट के जारी रहेगा.

ज़्यादा तकनीकी जानकारी के लिए नीचे देखें. सामान्य निर्देशों के लिए, कृपया 'मेरे रूट सर्टिफ़िकेट स्टोर' को अपडेट करने की ज़रूरत है या नहीं, इसकी पुष्टि करने का तरीका सेक्शन देखें.

हमारा यह भी सुझाव है कि आप अपने रूट सर्टिफ़िकेट स्टोर को ऊपर दिए गए क्यूरेट किए गए रूट सीए बंडल के साथ सिंक में रखें, ताकि आपकी सेवाओं को आने वाले समय में रूट सीए में होने वाले बदलावों के मुताबिक तैयार रखा जा सके. हालांकि, इनके बारे में पहले ही सूचना दी जाएगी. सेक्शन देखें मुझे माइग्रेशन के इस चरण से जुड़े अपडेट कैसे मिलेंगे? और मुझे आने वाले माइग्रेशन की पहले से सूचना कैसे मिलेगी? इस बारे में और जानकारी पाने के लिए, आगे के निर्देश देखें.

तकनीकी खास जानकारी

जैसा कि 15 मार्च, 2021 को Google सिक्योरिटी ब्लॉग, GS Root R2 में बताया गया था, रूट CA Google Maps Platform का इस्तेमाल 2018 की शुरुआत से 15 दिसंबर, 2021 को खत्म हो जाएगा. इसलिए, Google इस साल के दौरान, नए जारी किए गए CA GTS Root R1 क्रॉस पर माइग्रेट कर देगा. इसका मतलब है कि हमारी सेवाएं धीरे-धीरे इस नए सीए के जारी किए गए, TLS लीफ़ सर्टिफ़िकेट पर ट्रांसफ़र की जाएंगी.

करीब-करीब सभी आधुनिक TLS क्लाइंट और सिस्टम को GTS Root R1 सर्टिफ़िकेट के साथ पहले से ही कॉन्फ़िगर किया जा चुका है या उन्हें सामान्य सॉफ़्टवेयर अपडेट की मदद से सर्टिफ़िकेट मिलना चाहिए. साथ ही, GlobalSign Root CA - R1 भी पुराने लेगसी सिस्टम पर उपलब्ध होने चाहिए.

हालांकि, अगर नीचे दिए गए दोनों पॉइंट लागू होते हैं, तो आपको कम से कम अपने सिस्टम की पुष्टि करनी चाहिए:

  • आपकी सेवाएं नॉन-स्टैंडर्ड या लेगसी प्लैटफ़ॉर्म पर चलती हैं और/या जिन पर आपका खुद का रूट सर्टिफ़िकेट स्टोर है
  • आपने 2017-2018 में, Google के रूट CA माइग्रेशन के पहले चरण के दौरान कोई कार्रवाई नहीं की थी या आपने Google के भरोसेमंद रूट सीए बंडल से मिले सर्टिफ़िकेट का पूरा सेट इंस्टॉल नहीं किया था

पुष्टि कैसे करें कि मेरे रूट सर्टिफ़िकेट स्टोर को अपडेट करने की ज़रूरत है या नहीं सेक्शन से यह जानने के लिए सामान्य दिशा-निर्देश मिलते हैं कि इससे आपके सिस्टम पर असर होगा या नहीं.

ज़्यादा जानकारी के लिए सवाल देखें मुझे अपने रूट सर्टिफ़िकेट के स्टोर को भरोसेमंद Google रूट CA बंडल के साथ सिंक क्यों रखना चाहिए?

मुझे माइग्रेशन के इस चरण के बारे में अपडेट कैसे मिलेंगे?

अपडेट के लिए, सार्वजनिक समस्या 186840968 पर स्टार का निशान लगाएं. डेटा माइग्रेट करने की पूरी प्रोसेस के दौरान, अक्सर पूछे जाने वाले इस सवाल को तब भी अपडेट किया जाता है, जब हमें आम लोगों की दिलचस्पी वाले विषय मिलते हैं.

मुझे आने वाले समय में माइग्रेशन के बारे में पहले से सूचना कैसे मिल सकती है?

हमारा सुझाव है कि आप Google का सुरक्षा ब्लॉग फ़ॉलो करें. साथ ही, हम ब्लॉग पर सार्वजनिक तौर पर की गई घोषणा के बाद, प्रॉडक्ट के हिसाब से बने दस्तावेज़ को जल्द से जल्द अपडेट करने की कोशिश करेंगे.

कृपया Google Maps Platform से मिलने वाली सूचनाओं की भी सदस्यता लें. हम फ़ोरम पर ऐसे बदलावों से जुड़े अपडेट नियमित रूप से पोस्ट करते रहते हैं जिनका असर बड़ी संख्या में हो सकता है.

हम Google की एक से ज़्यादा सेवाओं का इस्तेमाल करते हैं. क्या रूट सीए माइग्रेशन उन सभी पर असर डालेगा?

हां, सभी Google सेवाओं और एपीआई पर रूट कैलिफ़ोर्निया में माइग्रेशन होगा, लेकिन हर सेवा के लिए टाइमलाइन अलग-अलग हो सकती है. हालांकि, एक बार यह पुष्टि कर लेने के बाद कि आपके Google Maps Platform क्लाइंट ऐप्लिकेशन के ज़रिए इस्तेमाल किए जाने वाले रूट सर्टिफ़िकेट स्टोर में भरोसेमंद Google रूट CA बंडल की सूची में शामिल सभी CA शामिल हैं, आपकी सेवाओं पर मौजूदा माइग्रेशन से कोई असर नहीं होना चाहिए और इन्हें सिंक में रखने से आने वाले रूट CA बदलावों से भी सुरक्षा होगी.

सवाल देखें मुझे अपने रूट सर्टिफ़िकेट को भरोसेमंद Google रूट CA बंडल के साथ सिंक क्यों रखना चाहिए? और किस तरह के ऐप्लिकेशन के खराब होने का जोखिम है? ज़्यादा जानकारी के लिए.

नीचे दिए गए सेक्शन 'पुष्टि कैसे करें कि मेरे रूट सर्टिफ़िकेट के स्टोर को अपडेट की ज़रूरत है या नहीं' सेक्शन में सिस्टम की जांच करने के लिए सामान्य निर्देश भी दिए गए हैं.

कैसे पता करूं कि मेरे रूट सर्टिफ़िकेट के स्टोर को अपडेट की ज़रूरत है या नहीं

नीचे दिए गए टेस्ट एंडपॉइंट के हिसाब से, अपने ऐप्लिकेशन एनवायरमेंट की जांच करें:

  • अगर GTS Root R1 क्रॉस टेस्ट एंडपॉइंट से TLS कनेक्शन बन पा रहा है, तो GS Root R2 की समयसीमा खत्म होने का असर नहीं पड़ेगा.
  • अगर आपका ऐप्लिकेशन GTS Root R1 टेस्ट एंडपॉइंट से TLS कनेक्शन बना लेता है, तो हो सकता है कि आपका ऐप्लिकेशन 2028 में GTS Root R1 Cross और GlobalSign Root CA - R1 के खत्म होने से भी बचाया जाए.

आम तौर पर आपका सिस्टम इस रूट CA बदलाव के साथ काम करेगा, अगर:

  • आपकी सेवा, रखरखाव वाले मेनस्ट्रीम ऑपरेटिंग सिस्टम पर काम करती हो और आपने उस ऑपरेटिंग सिस्टम और लाइब्रेरी, दोनों को रखा हो जिसे आपकी सेवा में पैच किया गया है. साथ ही, आपका अपना रूट सर्टिफ़िकेट स्टोर नहीं है या:
  • आपने हमारे पिछले सुझावों का पालन किया और भरोसेमंद Google रूट CA बंडल से सभी रूट CA इंस्टॉल किए हैं

जिन ग्राहकों पर इस समस्या का असर हुआ हो उन्हें आने वाले समय में सेवा में रुकावट से बचने के लिए, Google के भरोसेमंद रूट CA बंडल से सर्टिफ़िकेट तुरंत इंस्टॉल कर देना चाहिए.

ज़्यादा जानकारी के लिए सवाल देखें मुझे अपने रूट सर्टिफ़िकेट के स्टोर को भरोसेमंद Google रूट CA बंडल के साथ सिंक क्यों रखना चाहिए?

क्या रूट सर्टिफ़िकेट के स्टोर की पुष्टि करने के लिए, कोई आसान टूल है?

आपको अपनी जांच के लिए, दो कमांड लाइन टूल curl और openssl काम के लग सकते हैं. दोनों प्लैटफ़ॉर्म ज़्यादातर प्लैटफ़ॉर्म पर उपलब्ध हैं. साथ ही, इनमें सेटअप की जांच करने के लिए ज़्यादा विकल्प मिलते हैं.

curl पाने के निर्देशों के लिए, नीचे कर्ल पाना सेक्शन देखें.

नीचे दिए गए openssl निर्देश, 1.1.1 या उसके बाद के वर्शन के लिए हैं. वर्शन 1.1.1 से पहले के वर्शन काम नहीं करते हैं. अगर आप पुराने वर्शन का इस्तेमाल कर रहे हैं, तो अपने वर्शन के लिए ज़रूरत के हिसाब से इन कमांड को अपग्रेड करें या इनमें बदलाव करें. openssl पाने के निर्देशों के लिए, नीचे दिया गया OpenOpens का इस्तेमाल करना सेक्शन देखें.

नीचे दिए गए मुझे अपनी ज़रूरत के टूल कहां से मिल सकते हैं? सेक्शन में आपको और काम के टूल भी मिलेंगे.

कंक्रीट की जांच से जुड़े निर्देशों के लिए, कृपया इस बात की पुष्टि करने का तरीका कि मेरे रूट सर्टिफ़िकेट स्टोर को अपडेट की ज़रूरत है या नहीं सेक्शन देखें.

अपने डिफ़ॉल्ट रूट सर्टिफ़िकेट स्टोर की जांच करना

curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demo.pki.goog/; \
openssl s_client -connect good.gtsr1.demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demo.pki.goog/; \
openssl s_client -connect good.gtsr1x.demo.pki.goog:443 -showcerts </dev/null;

भरोसेमंद Google रूट CA बंडल की पुष्टि करना

भरोसेमंद Google रूट CA बंडल डाउनलोड करें और फिर यह तरीका अपनाएं:

curl -vvI --cacert roots.pem https://maps.googleapis.com; \
openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1.demo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demo.pki.goog:443 -showcerts </dev/null;

Google रूट CA माइग्रेशन कब और कैसे जारी रहेगा?

  1. पहला चरण (GS Root R2 पर माइग्रेट किया जा रहा है), जनवरी 2017 में एलान किया गया, 2017 के आखिर में शुरू हुआ और 2018 की पहली छमाही में खत्म हुआ.
  2. दूसरे चरण (GTS Root R1 Cross पर माइग्रेट करने का एलान) मार्च 2021 में किया गया था. यह आने वाले महीनों में, GS Root R2 के खत्म होने से पहले 15 दिसंबर, 2021 को रोल आउट हो जाएगा.

सर्टिफ़िकेट की समयसीमा खत्म होने से पहले, माइग्रेशन के लिए बाद के चरणों का शेड्यूल पहले ही बता दिया जाएगा.

हालांकि, अगर आप अपने रूट सर्टिफ़िकेट स्टोर को भरोसेमंद Google रूट CA बंडल में मौजूद रूट सीए की चुनी गई सूची के साथ सिंक रखते हैं, तो आप आने वाले समय में अपने ऐप्लिकेशन को सबूत दे पाएंगे.

यह भी सवाल देखें मुझे अपने रूट सर्टिफ़िकेट के स्टोर को, भरोसेमंद Google रूट CA बंडल के साथ सिंक क्यों रखना चाहिए? ज़्यादा जानकारी के लिए.

Google की हर सेवा के लिए सामान्य रोल आउट प्लान

  1. कुछ लोगों के लिए रिलीज़ करने की सुविधा, किसी एक डेटा सेंटर में शुरू होती है.
  2. जब तक पूरी दुनिया में कवरेज उपलब्ध नहीं हो जाता, तब तक रोल आउट को धीरे-धीरे कई और डेटा सेंटर तक भी पहुंचाया जाएगा.
  3. अगर किसी भी स्तर पर गंभीर समस्याओं का पता चलता है, तो समस्याओं को ठीक करने तक, जांच को कुछ समय के लिए रोल बैक किया जा सकता है.
  4. पिछली बार किए गए इनपुट के आधार पर, Google की आने वाली सेवाओं को इस रोल आउट में शामिल किया गया है. ऐसा तब तक होगा, जब तक Google की सभी सेवाएं धीरे-धीरे नए सर्टिफ़िकेट पर माइग्रेट नहीं हो जातीं.

किस पर, कब, और कहां असर पड़ेगा?

नए डेटा सेंटर माइग्रेट होने के बाद, Google Maps Platform डेवलपर की संख्या बढ़ने पर नए सर्टिफ़िकेट मिलने लगेंगे. ये बदलाव कुछ हद तक स्थानीय भाषा में किए जाएंगे, क्योंकि क्लाइंट के अनुरोध आम तौर पर आस-पास के डेटा सेंटर में मौजूद सर्वर पर भेजे जाते हैं.

हम पहले से ही यह नहीं बता सकते हैं कि कौन, कब, और कहां पर असर डालेगा. हम सुझाव देते हैं कि हमारे सभी ग्राहक Google रूट सीए के माइग्रेशन के दौरान, अपनी सेवाओं की पुष्टि पहले ही कर लें और आने वाले समय में उन्हें टेस्ट कर लें.

ज़्यादा दिशा-निर्देशों के लिए, कैसे पता करें कि मेरे रूट सर्टिफ़िकेट के स्टोर को अपडेट करने की ज़रूरत है या नहीं सेक्शन देखें.

समीक्षा करते समय क्या देखें

जिन क्लाइंट को ज़रूरी रूट सर्टिफ़िकेट के साथ कॉन्फ़िगर नहीं किया गया है वे Google Maps Platform से अपने TLS कनेक्शन की पुष्टि नहीं कर पाएंगे. ऐसी स्थिति में, क्लाइंट आम तौर पर एक चेतावनी जारी करेंगे कि सर्टिफ़िकेट की पुष्टि नहीं हो सकी.

अपने TLS कॉन्फ़िगरेशन के आधार पर, क्लाइंट Google Maps Platform का अनुरोध जारी कर सकते हैं या वे अनुरोध को जारी रखने से मना भी कर सकते हैं.

TLS क्लाइंट को Google Maps Platform से संपर्क करने की ज़रूरी शर्तें क्या हैं?

Google Maps Platform के सर्टिफ़िकेट में, डीएनएस सब्जेक्ट ऑल्टरनेटिव नेम (एसएएन) का इस्तेमाल किया जाता है. इसलिए, क्लाइंट के सर्टिफ़िकेट को हैंडल करने का काम एसएएन के साथ काम करना ज़रूरी है, जिसमें नाम में सबसे बाईं ओर वाले लेबल के रूप में एक वाइल्डकार्ड शामिल हो सकता है, जैसे कि *.googleapis.com.

अन्य ज़रूरी शर्तों के बारे में जानने के लिए, कृपया GTS से जुड़े अक्सर पूछे जाने वाले सवाल सेक्शन में जाकर, TLS क्लाइंट के लिए, Google से संपर्क करने की सुझाई गई ज़रूरी शर्तें क्या हैं? सेक्शन देखें.

किस तरह के ऐप्लिकेशन के खराब होने का खतरा है?

यह ऐप्लिकेशन, डेवलपर के लगाए गए प्रतिबंधों के बिना, सिस्टम के रूट सर्टिफ़िकेट के स्टोर का इस्तेमाल करता है

Google Maps Platform वेब सेवा ऐप्लिकेशन

अगर मेनस्ट्रीम ओएस का इस्तेमाल किया जा रहा है, जैसे कि Ubuntu, Red Hat, Windows 10 या Server 2019, OS X) का रखरखाव किया जा रहा है और समय-समय पर अपडेट मिलते रहते हैं. आपके डिफ़ॉल्ट रूट सर्टिफ़िकेट स्टोर में पहले से ही GTS Root R1 सर्टिफ़िकेट शामिल होना चाहिए.

अगर आपका पुराना ओएस वर्शन इस्तेमाल किया जा रहा है और अब अपडेट नहीं मिलते, तो हो सकता है कि आपके पास GTS Root R1 सर्टिफ़िकेट हो. हालांकि, आपके रूट सर्टिफ़िकेट स्टोर में GlobalSign Root CA - R1 फ़ॉर्मैट को शामिल किया जाएगा. यह सबसे पुराने और सबसे ज़्यादा भरोसेमंद रूट सीए में से एक है.

असली उपयोगकर्ता के डिवाइस से सीधे Google Maps Platform की वेब सेवाओं को कॉल करने वाले मोबाइल ऐप्लिकेशन के लिए, सवाल के दिशा-निर्देश क्या मोबाइल ऐप्लिकेशन पर असर होने का जोखिम है? लागू होते हैं.

क्लाइंट-साइड Google Maps Platform ऐप्लिकेशन

Maps JavaScript API ऐप्लिकेशन आम तौर पर, ऐप्लिकेशन चलाने वाले वेब ब्राउज़र के रूट सर्टिफ़िकेट पर निर्भर होते हैं. ज़्यादा जानकारी के लिए क्या JavaScript ऐप्लिकेशन में गड़बड़ी होने का खतरा है? सेक्शन देखें.

Android के लिए Maps SDK, iOS के लिए Maps SDK, Android के लिए Places SDK या iOS के लिए Places SDK टूल का इस्तेमाल करने वाले नेटिव मोबाइल ऐप्लिकेशन के लिए, वही नियम लागू होते हैं जो Google Maps Platform की वेब सेवाओं को कॉल करने वाले ऐप्लिकेशन पर लागू होते हैं.

ज़्यादा जानकारी के लिए सवाल देखें क्या मोबाइल ऐप्लिकेशन के काम करने में समस्या हो सकती है?

यह ऐप्लिकेशन अपने सर्टिफ़िकेट बंडल का इस्तेमाल करता है या सुरक्षा से जुड़ी बेहतर सुविधाओं का इस्तेमाल करता है. जैसे- सर्टिफ़िकेट पिन करना

आपको अपना सर्टिफ़िकेट बंडल खुद ही अपडेट करना होगा. जैसा कि सवाल में बताया गया है मुझे अपने रूट सर्टिफ़िकेट के स्टोर को भरोसेमंद Google रूट CA बंडल के साथ सिंक क्यों रखना चाहिए?, हमारा सुझाव है कि आप Google के भरोसेमंद रूट CA बंडल में मौजूद सभी सर्टिफ़िकेट को अपने रूट सर्टिफ़िकेट स्टोर में इंपोर्ट करें.

अगर आपका ऐप्लिकेशन जिन Google डोमेन से कनेक्ट होता है, उनके लिए सर्टिफ़िकेट या सार्वजनिक पासकोड पिन किए जा रहे हैं, तो आपको अपने ऐप्लिकेशन में भरोसेमंद इकाइयों की सूची में सर्टिफ़िकेट और सार्वजनिक पासकोड जोड़ने चाहिए.

सर्टिफ़िकेट या सार्वजनिक पासकोड को पिन करने के बारे में ज़्यादा जानकारी के लिए, ज़्यादा जानकारी चाहिए? सेक्शन में दिए गए उन बाहरी संसाधनों को देखें जिनकी जानकारी समस्या वाले सेक्शन में दी गई है.

मुझे अपने रूट सर्टिफ़िकेट के स्टोर को, भरोसेमंद Google रूट CA बंडल के साथ सिंक क्यों रखना चाहिए?

Google के भरोसेमंद रूट CA बंडल में मौजूद रूट सीए की चुनी गई सूची में, वे सभी सीए शामिल हैं जिनका इस्तेमाल आने वाले समय में Google की सेवाएं कर सकती हैं.

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

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

सवाल देखें आने वाले समय में होने वाले माइग्रेशन की सूचना मुझे पहले से कैसे मिल सकती है? यह जानने के लिए कि आने वाले समय में रूट CA से होने वाले माइग्रेशन के बारे में अपडेट कैसे पाएं. नियमित तौर पर अपने रूट सर्टिफ़िकेट स्टोर को चुनी गई सूची के साथ सिंक रखने से, सीए में हुए बदलावों की वजह से, आने वाली सेवाओं में किसी भी तरह की रुकावट से आपकी सेवाएं सुरक्षित रहेंगी. साथ ही, GTS Root R1 Cross और GlobalSign Root CA - R1, दोनों की समयसीमा खत्म होने के बाद भी आपकी सेवाएं चालू रहेंगी.

साथ ही, कृपया सवाल देखें मुझे एक ऐसा प्रॉडक्ट बनाया जा रहा है जो Google की सेवाओं से जुड़ा है. मुझे किन सीए सर्टिफ़िकेट पर भरोसा करना चाहिए? ज़्यादा सुझावों के लिए, GTS के बारे में अक्सर पूछे जाने वाले सवाल देखें.

मुझे किसी लीफ़ या इंटरमीडिएट CA सर्टिफ़िकेट को क्यों इंस्टॉल नहीं करना चाहिए?

ऐसा करने से किसी भी समय नया सर्टिफ़िकेट रजिस्टर करने या इंटरमीडिएट सीए को स्विच करने पर, आपका आवेदन खराब हो सकता है. इनमें से कोई भी स्थिति किसी भी समय हो सकती है और इसके लिए पहले से किसी सूचना के बिना भी ऐसा किया जा सकता है. यह अलग-अलग सर्वर के सर्टिफ़िकेट पर समान रूप से लागू होता है. जैसे, maps.googleapis.com के दिए गए सर्टिफ़िकेट और हमारे सभी इंटरमीडिएट सीए, जैसे कि GTS Root R1 Cross.

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

जब तक रूट सर्टिफ़िकेट देने वाली संस्था पर भरोसा होता है, तब तक टीएलएस की कोई भी आधुनिक लाइब्रेरी, ट्रस्ट की ऐसी चेन की पुष्टि अपने-आप कर सकती है.

क्या JavaScript ऐप्लिकेशन के खराब होने का खतरा है?

ज़्यादातर आधुनिक ब्राउज़र GTS रूट सर्टिफ़िकेट को पहले से ही अच्छी तरह से एम्बेड कर देते हैं और उन पर भरोसा करते हैं. GMO GlobalSign के क्रॉस-साइन से, यह पक्का करना चाहिए कि लेगसी ब्राउज़र का इस्तेमाल करने वाले ज़्यादातर असली उपयोगकर्ताओं के लिए भी, माइग्रेट करने में आसानी हो. इसमें Maps JavaScript API के लिए आधिकारिक तौर पर काम करने वाले सभी ब्राउज़र शामिल हैं.

हर मॉडर्न ब्राउज़र पर असली उपयोगकर्ताओं को यह पुष्टि करने की सुविधा देनी चाहिए कि वे ब्राउज़र के भरोसेमंद सर्टिफ़िकेट की पुष्टि कर सकें और आम तौर पर उसमें बदलाव कर सकें. हालांकि, हर ब्राउज़र के हिसाब से इनकी सटीक जगह अलग-अलग होती है, लेकिन आम तौर पर सर्टिफ़िकेट की सूची, सेटिंग में कहीं भी मिल सकती है.

क्या मोबाइल ऐप्लिकेशन खराब हो सकते हैं?

उम्मीद है कि आने वाले समय में, Android और Apple iOS डिवाइसों को डिवाइस बनाने वाली कंपनी से नियमित अपडेट मिल रहे होंगे. ज़्यादातर पुराने Android फ़ोन मॉडल में कम से कम GlobalSign Root CA - R1 सर्टिफ़िकेट शामिल होते हैं. हालांकि, भरोसेमंद सर्टिफ़िकेट की सूची, हर हैंडसेट मैन्युफ़ैक्चरर, डिवाइस मॉडल, और Android वर्शन के हिसाब से अलग-अलग हो सकती है.

हालांकि, मुमकिन है कि Android 10 से पहले के वर्शन में GTS Root R1 के साथ-साथ, GTS रूट CA के साथ काम करने की सुविधा अब भी सीमित हो.

iOS डिवाइसों के लिए, Apple अपने सहायता पेज पर हाल ही के हर iOS वर्शन के लिए, भरोसेमंद रूट CA की सूची बनाता है. हालांकि, iOS के 5 और इसके बाद के वर्शन के सभी वर्शन में, GlobalSign Root CA - R1 की भी सुविधा काम करती है.

iOS के 12.1.3 वर्शन से, GTS रूट CAs (जैसे कि GTS Root R1) काम कर रहा है.

सवाल देखें मैं अपने मोबाइल फ़ोन पर भरोसेमंद रूट सर्टिफ़िकेट की जांच कैसे करूं? ज़्यादा जानकारी के लिए.

मेरे ब्राउज़र या ऑपरेटिंग सिस्टम में, Google Trust Services के रूट सर्टिफ़िकेट कब शामिल किए जाएंगे?

पिछले कुछ सालों में Google ने बड़े पैमाने पर इस्तेमाल होने वाले और भरोसेमंद रूट सर्टिफ़िकेट बंडल बनाए रखने वाले सभी बड़े तीसरे पक्षों के साथ काफ़ी काम किया है. उदाहरण के लिए, ऑपरेटिंग सिस्टम मैन्युफ़ैक्चरर, जैसे कि Apple और Microsoft. इसके अलावा, Google की Android और Chrome OS टीम भी शामिल है. इसके अलावा, Mozilla, Apple, Microsoft जैसे ब्राउज़र डेवलपर के साथ-साथ Google की Chrome टीम भी बनाई जाती है. साथ ही, हार्डवेयर बनाने वाली कंपनियां, जैसे कि फ़ोन, सेट-टॉप बॉक्स, टीवी, गेम कंसोल, प्रिंटर वगैरह भी शामिल हैं.

इसलिए, इस बात की काफ़ी संभावना है कि रखरखाव किया गया कोई भी सिस्टम पहले से ही Google के नए GTS Root CAs के साथ काम करता हो, जिनमें GTS Root R1 शामिल है. साथ ही, कुछ पुराने सिस्टम भी GlobalSign Root CA - R1 के साथ काम करते हैं. इनका इस्तेमाल अगले सालों तक, Google से जारी किए गए क्रॉस-हस्ताक्षर वाले सर्टिफ़िकेट के लिए किया जाएगा.

हालांकि, तीसरे पक्ष से सर्टिफ़िकेट शामिल करने की टाइमलाइन Google के कंट्रोल से बाहर है. इसलिए, हमारी सलाह है कि आप नियमित तौर पर सिस्टम अपडेट लागू करें.

ऐसा हो सकता है कि Mozilla दोस्तों के CA Certificate Program जैसे तीसरे पक्षों ने अपने सर्टिफ़िकेट शामिल किए जाने की टाइमलाइन का दस्तावेज़ तैयार किया हो.

समस्या हल करना

मुझे जिन टूल की ज़रूरत है वे कहां से मिल सकते हैं?

कर्ल हासिल किया जा रहा है

अगर आपके ओएस डिस्ट्रिब्यूशन में curl की सुविधा नहीं है, तो इसे https://curl.haxx.se/ से डाउनलोड करें. सोर्स को डाउनलोड करके खुद कंपाइल किया जा सकता है. अगर आपके प्लैटफ़ॉर्म के लिए पहले से कंपाइल किया गया बाइनरी उपलब्ध है, तो उसे भी डाउनलोड किया जा सकता है.

खोलने का तरीका

अगर आपके ओएस डिस्ट्रिब्यूशन में openssl की सुविधा उपलब्ध नहीं है, तो https://www.openssl.org/ से सोर्स डाउनलोड करके टूल को कंपाइल किया जा सकता है. तीसरे पक्ष की बनाई गई बाइनरी की सूची, https://www.openssl.org/community/binaries.html पर देखी जा सकती है. हालांकि, इनमें से कोई भी बिल्ड काम नहीं करता या किसी भी तरह से उसका प्रमोशन करने के लिए किया जा सकता है.

वायर शार्क, Tshark या Tcpdump पाना

ज़्यादातर Linux डिस्ट्रिब्यूशन wireshark की सुविधा देते हैं. हालांकि, इसके कमांड-लाइन टूल tshark और tcpdump, अन्य ओएस के लिए पहले दो के पहले से कंपाइल किए गए वर्शन https://www.wireshark.org पर देखे जा सकते हैं.

Tcpdump और LibPCAP का सोर्स कोड https://www.tcpdump.org पर देखा जा सकता है.

इन काम के टूल के दस्तावेज़, Wireshark के उपयोगकर्ता के लिए गाइड, शार्क के मैन पेज, और Tcpdump मैन पेज पर मिल सकते हैं.

Java कीटूल लोड किया जा रहा है

keytool कमांड लाइन टूल को हर Java डेवलपमेंट किट (JDK) या Java रनटाइम एनवायरमेंट (JRE) वर्शन के साथ भेजा जाना चाहिए. keytool. पाने के लिए इन्हें इंस्टॉल करें. हालांकि, रूट सर्टिफ़िकेट की पुष्टि करने के लिए, keytool का इस्तेमाल करना ज़रूरी नहीं है. हालांकि, जब तक आपका ऐप्लिकेशन Java का इस्तेमाल करके नहीं बनाया गया है, तब तक ऐसा करना ज़रूरी नहीं है.

प्रोडक्शन में कुछ समय के लिए उपलब्ध न होने पर क्या करें

आपके लिए मुख्य कार्रवाई यह है कि भरोसेमंद Google रूट CA बंडल से ज़रूरी रूट सर्टिफ़िकेट को आपके ऐप्लिकेशन के इस्तेमाल किए जाने वाले रूट सर्टिफ़िकेट में इंस्टॉल किया जाए.

  1. अपने लोकल रूट सर्टिफ़िकेट स्टोर को अपग्रेड करने के लिए, अपने सिस्टम एडमिन के साथ मिलकर काम करें.
  2. अपने सिस्टम पर लागू होने वाले पॉइंटर के लिए, अक्सर पूछे जाने वाले ये सवाल देखें.
  3. अगर आपको किसी और प्लैटफ़ॉर्म या सिस्टम से जुड़ी मदद चाहिए, तो सिस्टम की सेवा देने वाली कंपनी के तकनीकी सहायता तरीकों से संपर्क करें.
  4. सामान्य सहायता के लिए, Google Maps Platform की सहायता टीम से संपर्क करना सेक्शन में बताए गए तरीके के हिसाब से, हमारी सहायता टीम से संपर्क करें. ध्यान दें: किसी प्लैटफ़ॉर्म से जुड़ी समस्याओं के लिए, सिर्फ़ बेहतर कोशिश के आधार पर ही दिशा-निर्देश दिए जाते हैं.
  5. माइग्रेशन से जुड़े अपडेट के लिए, स्टार का सार्वजनिक अंक 186840968.

Google Maps Platform की सहायता टीम से संपर्क किया जा रहा है

समस्या हल करने के शुरुआती तरीके

समस्या हल करने के सामान्य निर्देशों के लिए पुष्टि कैसे करें कि मेरे रूट सर्टिफ़िकेट के स्टोर को अपडेट की ज़रूरत है या नहीं सेक्शन देखें.

अगर आपको रूट सर्टिफ़िकेट को इंपोर्ट या एक्सपोर्ट करना है, तो भरोसेमंद सर्टिफ़िकेट को मैनेज करना सेक्शन में आपको काम की जानकारी मिल सकती है.

अगर समस्या हल नहीं होती है और आपने Google Maps Platform की सहायता टीम से संपर्क करने का फ़ैसला किया है, तो नीचे दी गई जानकारी दें:

  1. आपके जिन सर्वर पर असर हुआ है वे कहां मौजूद हैं?
  2. आपकी सेवा किन Google आईपी पतों को कॉल कर रही है?
  3. इस समस्या(एपीआई) पर इस समस्या का असर पड़ा है?
  4. असल में समस्या कब शुरू हुई?

  5. इन निर्देशों के आउटपुट:

    curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demo.pki.goog/; \
openssl s_client -connect good.gtsr1.demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demo.pki.goog/; \
openssl s_client -connect good.gtsr1x.demo.pki.goog:443 -showcerts </dev/null;

ज़रूरी टूल पाने के निर्देशों के लिए, यह सवाल देखें मुझे ज़रूरी टूल कहां से मिल सकते हैं?.

सहायता अनुरोध दर्ज करना

कृपया Google Maps Platform की सहायता और संसाधन में सहायता अनुरोध बनाने के निर्देशों का पालन करें.

समस्या हल करने की शुरुआती प्रक्रिया सेक्शन में दिए गए डेटा के अलावा, सहायता अनुरोध सबमिट करते समय, कृपया यह जानकारी भी दें:

  • आपके सार्वजनिक आईपी पते क्या हैं?
  • आपके डीएनएस सर्वर का सार्वजनिक आईपी पता क्या है?
  • अगर मुमकिन हो, तो एक tcpdump या वायर शार्क पैकेट, PCAP फ़ॉर्मैट में https://maps.googleapis.com/ के ख़िलाफ़ फ़ेल हुई TLS नेगोशिएशन को कैप्चर करता है. साथ ही, पूरे पैकेट को छोटा किए बिना उसे कैप्चर करने के लिए, ज़रूरत के मुताबिक बड़ी स्नैपशॉट का इस्तेमाल करता है (उदाहरण के लिए, tcpdump के पुराने वर्शन पर -s0 का इस्तेमाल करना).
  • अगर हो सके, तो आपकी सेवा के कुछ हिस्सों को लॉग करता है. इनमें TLS कनेक्शन के काम न करने की सटीक वजह दिखती है. खास तौर पर, इसमें पूरे सर्वर सर्टिफ़िकेट की चेन की जानकारी शामिल की जाती है.

ज़रूरी टूल पाने के निर्देशों के लिए, यह सवाल देखें मुझे ज़रूरी टूल कहां से मिल सकते हैं?.

सार्वजनिक समस्या (186840968) पर पोस्ट किया जा रहा है

सार्वजनिक समस्या 186840968 पर टिप्पणी करते समय, कृपया शुरुआती समस्या का हल सेक्शन में दी गई जानकारी शामिल करें.

मैं अपने डीएनएस का सार्वजनिक पता कैसे पता करूं?

Linux पर, इस कमांड को चलाया जा सकता है:

dig -t txt o-o.myaddr.l.google.com

Windows पर इंटरैक्टिव मोड में nslookup का इस्तेमाल किया जा सकता है:

C:\> nslookup -
set type=TXT
o-o.myaddr.l.google.com

कर्ल आउटपुट को समझने का तरीका

-vvI फ़्लैग के साथ curl चलाने से ज़्यादा काम की जानकारी मिलती है. आउटपुट को समझने के लिए, यहां कुछ निर्देश दिए गए हैं:

  • '*' से शुरू होने वाली लाइनें, TLS नेगोशिएशन के आउटपुट के आउटपुट के साथ-साथ कनेक्शन खत्म करने की जानकारी भी दिखाती हैं.
  • '>' से शुरू होने वाली लाइन, उस आउटगोइंग एचटीटीपी अनुरोध को दिखाती हैं जिसे curl भेजता है.
  • '<' से शुरू होने वाली लाइनें, सर्वर से मिलने वाला एचटीटीपी रिस्पॉन्स दिखाती हैं.
  • अगर प्रोटोकॉल एचटीटीपीएस था, तो '>' या '<' लाइनों की मौजूदगी का मतलब है कि सही TLS हैंडशेक हुआ है.

इस्तेमाल की गई TLS लाइब्रेरी और रूट सर्टिफ़िकेट का बंडल

curl को -vvI फ़्लैग के साथ चलाने से, इस्तेमाल किए गए रूट सर्टिफ़िकेट के स्टोर का प्रिंट भी प्रिंट हो जाता है. हालांकि, जैसा कि यहां दिखाया गया है, हर सिस्टम के हिसाब से सटीक आउटपुट अलग हो सकता है.

NSS से लिंक किए गए curl वाली Red Hat Linux मशीन से मिलने वाले आउटपुट में ये लाइनें हो सकती हैं:

* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none

Ubuntu या Debian Linux मशीन से आउटपुट में ये लाइनें हो सकती हैं:

* successfully set certificate verify locations:
* CAfile: none
  CApath: /etc/ssl/certs

--cacert फ़्लैग का इस्तेमाल करके दिए गए Google रूट सर्टिफ़िकेट PEM फ़ाइल का इस्तेमाल करके, Ubuntu या Debian Linux मशीन से आउटपुट होने पर, इनमें ये लाइनें हो सकती हैं:

* successfully set certificate verify locations:
* CAfile: /home/<user>/Downloads/roots.pem
  CApath: /etc/ssl/certs

उपयोगकर्ता एजेंट

आउटगोइंग अनुरोधों में User-Agent हेडर होता है, जिससे curl और आपके सिस्टम के बारे में काम की जानकारी मिल सकती है.

Red Hat Linux मशीन से एक उदाहरण:

> HEAD / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh1/1.4.2
> Host: maps.googleapis.com
> Accept: */*
>

TLS हैंडशेक पूरा नहीं हो सका

कोड सैंपल की लाइन जैसी लाइनें बताती हैं कि किसी गैर-भरोसेमंद सर्वर सर्टिफ़िकेट की वजह से कनेक्शन को बीच में TLS-हैंडशेक खत्म किया गया. > या < से शुरू होने वाले डीबग आउटपुट के उपलब्ध न होने से भी पता चलता है कि कनेक्ट करने की कोशिश नहीं की जा रही है:

*** SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0**

TLS हैंडशेक पूरा हुआ

एक सफल TLS हैंडशेक, इस कोड सैंपल में मौजूद लाइनों से मिलती-जुलती लाइनों की मौजूदगी से पता चलता है. एन्क्रिप्ट (सुरक्षित) किए गए कनेक्शन के लिए इस्तेमाल किए गए साइफ़र सुइट को सूची में शामिल किया जाना चाहिए. साथ ही, स्वीकार किए गए सर्वर के सर्टिफ़िकेट की जानकारी भी दी जानी चाहिए. इसके अलावा, > या < से शुरू होने वाली लाइनों से पता चलता है कि पेलोड एचटीटीपी ट्रैफ़िक को TLS से एन्क्रिप्ट (सुरक्षित) किए गए कनेक्शन पर ट्रांसमिट किया जा रहा है:

*   Trying 108.177.15.95:443...
* Connected to maps.googleapis.com (108.177.15.95) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=upload.video.google.com
*  start date: Mar 23 08:24:47 2021 GMT
*  expire date: Jun 15 08:24:46 2021 GMT
*  subjectAltName: host "maps.googleapis.com" matched cert's "*.googleapis.com"
*  issuer: C=US; O=Google Trust Services; CN=GTS CA 1O1
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55c4acf0c560)
> HEAD / HTTP/2
> Host: maps.googleapis.com
> user-agent: curl/7.74.0
> accept: */*
>
> HTTP/2 302
…

सर्वर के मिले सर्टिफ़िकेट को ऐसे फ़ॉर्म में प्रिंट करने का तरीका जिसे कोई भी व्यक्ति आसानी से पढ़ सके

यह मानते हुए कि आउटपुट को PEM फ़ॉर्मैट किया गया है, उदाहरण के लिए, openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null से आउटपुट, दिखाए गए सर्टिफ़िकेट को प्रिंट करने के लिए, यह तरीका अपनाएं:

  • हेडर और फ़ुटर के साथ-साथ, Base 64 कोड में बदले गए पूरे सर्टिफ़िकेट को कॉपी करें:

    -----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

  • इसके बाद, ऐसा करें:

    openssl x509 -inform pem -noout -text
````

  • इसके बाद, कॉपी बफ़र के कॉन्टेंट को टर्मिनल में चिपकाएं.

  • Return बटन दबाएं.

इनपुट और आउटपुट के उदाहरण के लिए, किसी व्यक्ति के पढ़ने लायक फ़ॉर्मैट में PEM सर्टिफ़िकेट को प्रिंट करने का तरीका सेक्शन देखें.

क्रॉस-साइन किए गए Google सर्टिफ़िकेट, OpenGL में कैसे दिखते हैं?

…
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demo.pki.goog
   i:C = US, O = Google Trust Services LLC, CN = GTS Y1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services LLC, CN = GTS Y1
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demo.pki.goog

issuer=C = US, O = Google Trust Services LLC, CN = GTS Y1

---
…

अपने भरोसेमंद सर्टिफ़िकेट को मैनेज करना

मैं अपने मोबाइल फ़ोन पर भरोसेमंद रूट सर्टिफ़िकेट की जांच कैसे करूं?

Android के भरोसेमंद सर्टिफ़िकेट

जैसा कि सवाल में बताया गया है क्या मोबाइल ऐप्लिकेशन के काम करने में समस्या हो सकती है?, Android के 4.0 वर्शन के बाद से ही हैंडसेट उपयोगकर्ताओं को सेटिंग में, भरोसेमंद सर्टिफ़िकेट की सूची की पुष्टि करने की सुविधा मिली हुई है. इस टेबल में, सेटिंग मेन्यू का सटीक पाथ दिखाया गया है:

Android वर्शन मेन्यू पाथ
1.x, 2.x, 3.x लागू नहीं
4.x, 5.x, 6.x, 7.x सेटिंग > सुरक्षा > भरोसेमंद क्रेडेंशियल
8.x, 9 सेटिंग > सुरक्षा और जगह > एन्क्रिप्ट (सुरक्षित) करने का तरीका और क्रेडेंशियल > भरोसेमंद क्रेडेंशियल
10+ सेटिंग > सुरक्षा > बेहतर > एन्क्रिप्ट (सुरक्षित) करने का तरीका और क्रेडेंशियल > भरोसेमंद क्रेडेंशियल

इस टेबल में, हर Android वर्शन के लिए सबसे ज़रूरी रूट सर्टिफ़िकेट मिलने की संभावना है. यह Android के वर्चुअल डिवाइस (एवीडी) सिस्टम की इमेज का इस्तेमाल करके, मैन्युअल तरीके से पुष्टि के आधार पर बनाई गई है. यह एओएसपी सीए-सर्टिफ़िकेट के गिट का डेटा स्टोर करने की जगह के वर्शन इतिहास में मिलेगी, जहां सिस्टम इमेज अब उपलब्ध नहीं थीं:

Android वर्शन GTS रूट R1 GlobalSign Root CA - R1 GlobalSign Root R2 (15 दिसंबर, 2021 तक मान्य)
2.3, 3.2, 4.x, 5.x, 6.x, 7.x, 8.x, 9
10+

आम तौर पर, फ़र्मवेयर अपडेट या डिवाइस को रूट किए बिना Android सिस्टम के रूट सर्टिफ़िकेट स्टोर को अपडेट नहीं किया जा सकता. हालांकि, Android के ऐसे ज़्यादातर वर्शन जिनका अब भी इस्तेमाल किया जा रहा है उनमें भरोसेमंद रूट सर्टिफ़िकेट के मौजूदा सेट से, कई सालों तक बिना किसी रुकावट के सेवा दी जा सकती है.

वर्शन 7.0 से, Android ऐप्लिकेशन डेवलपर को ऐसे भरोसेमंद सर्टिफ़िकेट जोड़ने का एक सुरक्षित तरीका उपलब्ध कराता है जिन पर सिर्फ़ उनके ऐप्लिकेशन भरोसा करते हैं. इसके लिए, सर्टिफ़िकेट को ऐप्लिकेशन के साथ बंडल किया जाता है और एक कस्टम नेटवर्क सुरक्षा कॉन्फ़िगरेशन बनाया जाता है. सुरक्षा और निजता के लिए Android के सबसे सही तरीके नेटवर्क सुरक्षा कॉन्फ़िगरेशन ट्रेनिंग दस्तावेज़ में बताए गए तरीके के मुताबिक ऐसा किया जाता है.

हालांकि, तीसरे पक्ष के ऐप्लिकेशन डेवलपर, Google Play Services APK से मिलने वाले ट्रैफ़िक के नेटवर्क सुरक्षा कॉन्फ़िगरेशन पर असर नहीं डाल पाएंगे. इसलिए, ऐसी कोशिशों से कुछ हद तक ही समाधान मिलेगा.

पुराने लेगसी डिवाइसों पर, आपके लिए सिर्फ़ उपयोगकर्ता के जोड़े गए CA पर भरोसा करना ही उपलब्ध होगा. इसके लिए, उन्हें असली उपयोगकर्ता के डिवाइस पर लागू कॉर्पोरेट ग्रुप की नीति के ज़रिए इंस्टॉल किया गया हो या खुद असली उपयोगकर्ता.

iOS ट्रस्ट स्टोर

Apple अपने हैंडसेट उपयोगकर्ता को सीधे तौर पर भरोसेमंद रूट सर्टिफ़िकेट का डिफ़ॉल्ट सेट नहीं दिखाता है. हालांकि, कंपनी के पास Apple के सहायता लेखों में दिए गए iOS वर्शन 5 और उसके बाद के वर्शन के लिए, भरोसेमंद रूट CA के सेट के लिंक होते हैं:

हालांकि, iOS डिवाइस पर इंस्टॉल किए गए किसी भी अतिरिक्त सर्टिफ़िकेट को सेटिंग > सामान्य > प्रोफ़ाइल में देखा जा सकता है. अगर कोई भी अतिरिक्त सर्टिफ़िकेट इंस्टॉल नहीं किया गया है, तो हो सकता है कि प्रोफ़ाइल मेन्यू आइटम न दिखे.

इस टेबल में, ऊपर दिए गए सोर्स के आधार पर iOS वर्शन के हिसाब से सबसे ज़रूरी रूट सर्टिफ़िकेट की उपलब्धता की जानकारी दी गई है:

iOS वर्शन GTS रूट R1 GlobalSign Root CA - R1 GlobalSign Root R2 (15 दिसंबर, 2021 तक मान्य)
5, 6, 7, 8, 9, 10, 11, 12.0
12.1.3+

मेरे सिस्टम के रूट सर्टिफ़िकेट कहां सेव होते हैं और इसे कैसे अपडेट किया जा सकता है?

डिफ़ॉल्ट रूट सर्टिफ़िकेट के स्टोर की जगह, ऑपरेटिंग सिस्टम और एसएसएल/TLS लाइब्रेरी के इस्तेमाल के हिसाब से अलग-अलग होती है. हालांकि, ज़्यादातर Linux डिस्ट्रिब्यूशन पर डिफ़ॉल्ट रूट सर्टिफ़िकेट, इनमें से किसी एक पाथ में मिल सकते हैं:

  • /usr/local/share/ca-certificates: Debian, Ubuntu, पुराना RHEL, और CentOS वर्शन
  • /etc/pki/ca-trust/source/anchors और /usr/share/pki/ca-trust-source: Fedora, RHEL और CentOS के नए वर्शन
  • /var/lib/ca-certificates: OpenSUSE

अन्य सर्टिफ़िकेट पाथ में ये शामिल हो सकते हैं:

  • /etc/ssl/certs: Debian, Ubuntu
  • /etc/pki/tls/certs: RHEL, CentOS

इन डायरेक्ट्री में कुछ सर्टिफ़िकेट, दूसरी डायरेक्ट्री में मौजूद फ़ाइलों के सांकेतिक लिंक होते हैं.

OpenGL रूट सर्टिफ़िकेट स्टोर

OpenSSL का इस्तेमाल करने वाले ऐप्लिकेशन के लिए, आप नीचे दिए गए निर्देश का इस्तेमाल करके डिफ़ॉल्ट रूट सर्टिफ़िकेट स्टोर के साथ-साथ इसके इंस्टॉल किए गए कॉम्पोनेंट के कॉन्फ़िगर किए गए जगह की जांच कर सकते हैं:

openssl version -d

कमांड, OPENSSLDIR को प्रिंट करता है, जो लाइब्रेरी की टॉप लेवल डायरेक्ट्री से मेल खाता है. साथ ही, उसके कॉन्फ़िगरेशन नीचे देखे जा सकते हैं:

OPENSSLDIR: "/usr/lib/ssl"

रूट सर्टिफ़िकेट स्टोर, certs सबडायरेक्ट्री में मौजूद होता है.

ls -l /usr/lib/ssl/certs

lrwxrwxrwx 1 root root 14 Apr 21  2020 /usr/lib/ssl/certs -> /etc/ssl/certs

ls -l /etc/ssl/certs

…
-rw-r--r-- 1 root root 214904 Apr 15 17:01  ca-certificates.crt
…
lrwxrwxrwx 1 root root     50 Apr 15 16:57  GTS_Root_R1.pem -> /usr/share/ca-certificates/mozilla/GTS_Root_R1.crt
…

अगर{9/} ऊपर दिए गए उदाहरण की तरह, डिफ़ॉल्ट सिस्टम रूट सर्टिफ़िकेट स्टोर पर निर्भर करता है, तो टॉप लेवल सेक्शन देखें मेरे सिस्टम रूट सर्टिफ़िकेट कहां स्टोर हैं और इसे कैसे अपडेट किया जा सकता है? यह पक्का करने के लिए कि सिस्टम रूट सर्टिफ़िकेट का बंडल अप-टू-डेट है.

openssl पाने के निर्देशों के लिए, OpenSSL का इस्तेमाल करना सेक्शन देखें.

Java रूट सर्टिफ़िकेट स्टोर

Java ऐप्लिकेशन अपने खुद के रूट सर्टिफ़िकेट स्टोर का इस्तेमाल कर सकते हैं, जो Linux सिस्टम पर आम तौर पर /etc/pki/java/cacerts या /usr/share/ca-certificates-java में होता है, जिसे Java keytool कमांड-लाइन टूल का इस्तेमाल करके मैनेज किया जा सकता है.

अपने Java सर्टिफ़िकेट स्टोर में, किसी एक सर्टिफ़िकेट को इंपोर्ट करने के लिए, यह कमांड जारी करें:

keytool -import -trustcacerts -file cert.pem -alias alias -keystore certs.jks

बस cert.pem को सुझाए गए हर रूट सर्टिफ़िकेट से जुड़ी सर्टिफ़िकेट फ़ाइल से बदलें. साथ ही, alias को यूनीक और काम के सर्टिफ़िकेट वाले उपनाम से बदलें. साथ ही, certs.jks को अपने एनवायरमेंट में इस्तेमाल की गई सर्टिफ़िकेट डेटाबेस फ़ाइल से बदलें.

ज़्यादा जानकारी के लिए, कृपया Oracle और Stack Overflow पर मौजूद ये लेख देखें:

Mozilla NSS रूट सर्टिफ़िकेट स्टोर

Mozilla NSS का इस्तेमाल करने वाले ऐप्लिकेशन, डिफ़ॉल्ट रूप से पूरे सिस्टम के सर्टिफ़िकेट डेटाबेस का भी इस्तेमाल कर सकते हैं. यह डेटाबेस आम तौर पर /etc/pki/nssdb में या किसी खास उपयोगकर्ता के लिए ${HOME}/.pki/nssdb में मौजूद डिफ़ॉल्ट स्टोर पर मौजूद होता है.

अपना एनएसएस डेटाबेस अपडेट करने के लिए, certutil टूल का इस्तेमाल करें.

अपने NSS डेटाबेस में किसी एक सर्टिफ़िकेट की फ़ाइल इंपोर्ट करने के लिए, यह कमांड जारी करें:

certutil -A -t "C,," -i cert.pem -n cert-name -d certdir

बस cert.pem को सुझाए गए हर रूट सर्टिफ़िकेट से जुड़ी सर्टिफ़िकेट फ़ाइल से, cert-name को काम के सर्टिफ़िकेट के निकनेम से और certdir को अपने एनवायरमेंट में इस्तेमाल किए गए सर्टिफ़िकेट के डेटाबेस पाथ से बदलें.

ज़्यादा जानकारी के लिए, कृपया आधिकारिक NSS टूल सर्टिफ़िकेट मैन्युअल और साथ ही, ऑपरेटिंग सिस्टम से जुड़े दस्तावेज़ देखें.

Microsoft .NET रूट सर्टिफ़िकेट का स्टोर

Windows .NET डेवलपर को अपने रूट सर्टिफ़िकेट स्टोर को अपडेट करने के लिए, Microsoft के कम से कम ये लेख काम के लग सकते हैं:

सर्टिफ़िकेट वाली फ़ाइल का फ़ॉर्मैट

PEM फ़ाइल क्या होती है?

निजता से बेहतर बनाई गई मेल (पीईएम), क्रिप्टोग्राफ़िक सर्टिफ़िकेट, कुंजियों वगैरह को सेव करने और भेजने के लिए, एक ऐसा स्टैंडर्ड टेक्स्ट फ़ाइल फ़ॉर्मैट है जो आरएफ़सी 7468 में डी-जूर स्टैंडर्ड के तौर पर फ़ॉर्मैट किया गया है.

फ़ाइल फ़ॉर्मैट को इंसान पढ़ सकते हैं, लेकिन Base64 कोड में बदले गए बाइनरी सर्टिफ़िकेट के डेटा की जानकारी नहीं है. हालांकि, PEM स्पेसिफ़िकेशन में टेक्स्ट एन्कोड किए गए सर्टिफ़िकेट के मुख्य हिस्से के पहले या बाद में, एक्सप्लेनेशंस का टेक्स्ट भेजने की अनुमति मिलती है. साथ ही, कई टूल इस सुविधा का इस्तेमाल, सर्टिफ़िकेट के सबसे काम के डेटा एलिमेंट की खास जानकारी देने के लिए भी करते हैं.

openssl जैसे टूल का इस्तेमाल, पूरे सर्टिफ़िकेट को डिकोड करने के लिए भी किया जा सकता है. यह ऐसे फ़ॉर्मैट में होना चाहिए जिसे कोई भी पढ़ सके. ज़्यादा जानकारी के लिए, किसी व्यक्ति के पढ़ने लायक फ़ॉर्म में PEM सर्टिफ़िकेट प्रिंट करने का तरीका सेक्शन देखें.

".crt" फ़ाइल क्या होती है?

PEM फ़ॉर्मैट में सर्टिफ़िकेट को एक्सपोर्ट करने की अनुमति देने वाले टूल आम तौर पर, फ़ाइल एक्सटेंशन ".crt" का इस्तेमाल करके यह बताते हैं कि फ़ाइल में टेक्स्ट वाली एन्कोडिंग का इस्तेमाल किया गया है.

DER फ़ाइल क्या होती है?

कोड में बदलने के खास नियम (DER), सर्टिफ़िकेट को कोड में बदलने के लिए इस्तेमाल होने वाला एक स्टैंडर्ड बाइनरी फ़ॉर्मैट है. PEM फ़ाइलों के सर्टिफ़िकेट आम तौर पर Base64 एन्कोड किए गए DER सर्टिफ़िकेट होते हैं.

".cer" फ़ाइल क्या होती है?

".cer" सफ़िक्स वाली एक्सपोर्ट की गई फ़ाइल में PEM-कोड में बदला गया सर्टिफ़िकेट हो सकता है, लेकिन ज़्यादातर मामलों में बाइनरी वाला सर्टिफ़िकेट हो, आम तौर पर DER कोड में बदला गया सर्टिफ़िकेट. परंपरागत के मुताबिक, ".cer" फ़ाइलों में आम तौर पर सिर्फ़ एक सर्टिफ़िकेट होता है.

मेरा सिस्टम roots.pem से सभी सर्टिफ़िकेट इंपोर्ट करने से मना करता है

कुछ सिस्टम, जैसे कि Java keytool, किसी PEM फ़ाइल से सिर्फ़ एक सर्टिफ़िकेट इंपोर्ट कर सकता है, भले ही उसमें कई सर्टिफ़िकेट हों. सवाल देखें मैं roots.pem से अलग-अलग सर्टिफ़िकेट कैसे निकालूं? यह देखने के लिए कि फ़ाइल को पहले कैसे बांटा जा सकता है.

मैंroos.pem से अलग-अलग सर्टिफ़िकेट कैसे निकालूं?

नीचे दी गई आसान बैश स्क्रिप्ट का इस्तेमाल करके, roots.pem को इसके कॉम्पोनेंट सर्टिफ़िकेट में बांटा जा सकता है:

csplit -z -f roots.pem. roots.pem '/-----END CERTIFICATE-----/+1' '{*}' &>/dev/null && \
for f in roots.pem.*; \
  do mv "${f}" $(openssl x509 -in "${f}" -noout -issuer_hash).pem; \
done

इससे यहां दी गई सूची से मिलती-जुलती कई अलग-अलग PEM फ़ाइलें बननी चाहिए:

ls -l *.pem

-rw-r----- 1 <user> <group>  2217 Apr 28 11:04 02265526.pem
-rw-r----- 1 <user> <group>  1722 Apr 28 11:04 062cdee6.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 0a775a30.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 1001acf7.pem
-rw-r----- 1 <user> <group>  1796 Apr 28 11:04 106f3e4d.pem
-rw-r----- 1 <user> <group>  1315 Apr 28 11:04 1d3472b9.pem
-rw-r----- 1 <user> <group>  1919 Apr 28 11:04 244b5494.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 2b349938.pem
-rw-r----- 1 <user> <group>  1651 Apr 28 11:04 2c543cd1.pem
-rw-r----- 1 <user> <group>  1858 Apr 28 11:04 3513523f.pem
-rw-r----- 1 <user> <group>  2000 Apr 28 11:04 40547a79.pem
-rw-r----- 1 <user> <group>  1862 Apr 28 11:04 4a6481c9.pem
-rw-r----- 1 <user> <group>  1927 Apr 28 11:04 4bfab552.pem
-rw-r----- 1 <user> <group>  1745 Apr 28 11:04 5ad8a5d6.pem
-rw-r----- 1 <user> <group>  1813 Apr 28 11:04 607986c7.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 626dceaf.pem
-rw-r----- 1 <user> <group>  1738 Apr 28 11:04 653b494a.pem
-rw-r----- 1 <user> <group>  2294 Apr 28 11:04 6b99d060.pem
-rw-r----- 1 <user> <group>  2510 Apr 28 11:04 75d1b2ed.pem
-rw-r----- 1 <user> <group>  1788 Apr 28 11:04 76cb8f92.pem
-rw-r----- 1 <user> <group>  1383 Apr 28 11:04 7f3d5d1d.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 93bc0acc.pem
-rw-r----- 1 <user> <group>  1220 Apr 28 11:04 9c8dfbd4.pem
-rw-r----- 1 <user> <group>  1838 Apr 28 11:04 9d04f354.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 a3418fda.pem
-rw-r----- 1 <user> <group>  2194 Apr 28 11:04 aee5f10d.pem
-rw-r----- 1 <user> <group>  1249 Apr 28 11:04 b0e59380.pem
-rw-r----- 1 <user> <group>  1882 Apr 28 11:04 b1159c4c.pem
-rw-r----- 1 <user> <group>  2346 Apr 28 11:04 b727005e.pem
-rw-r----- 1 <user> <group>  1940 Apr 28 11:04 cbf06781.pem
-rw-r----- 1 <user> <group>  2609 Apr 28 11:04 d6325660.pem
-rw-r----- 1 <user> <group>  2474 Apr 28 11:04 dc4d6a89.pem
-rw-r----- 1 <user> <group>  1358 Apr 28 11:04 dd8e9d41.pem
-rw-r----- 1 <user> <group>  1972 Apr 28 11:04 ee64a828.pem
-rw-r----- 1 <user> <group>  1462 Apr 28 11:04 eed8c118.pem
-rw-r----- 1 <user> <group>  1944 Apr 28 11:04 f081611a.pem
-rw-r----- 1 <user> <group>  1488 Apr 28 11:04 f30dd6ad.pem
-rw-r----- 1 <user> <group>  1975 Apr 28 11:04 f387163d.pem
-rw-r----- 1 <user> <group>  2632 Apr 28 11:04 fc5a8f99.pem
-rw-r----- 1 <user> <group> 72865 Apr 20 12:44 roots.pem

इसके बाद, अलग-अलग PEM फ़ाइलों, जैसे कि 02265526.pem को अलग से इंपोर्ट किया जा सकता है या उन्हें ऐसे फ़ाइल फ़ॉर्मैट में बदला जा सकता है जो आपके सर्टिफ़िकेट स्टोर में स्वीकार किया जा सकता है.

मेरे सिस्टम पर काम करने वाले फ़ॉर्मैट और PEM फ़ाइल को आपस में कैसे बदलें

OpenSSL टूलकिट कमांड-लाइन टूल openssl का इस्तेमाल, आम तौर पर इस्तेमाल किए जाने वाले सभी सर्टिफ़िकेट फ़ाइल फ़ॉर्मैट में फ़ाइल बदलने के लिए किया जा सकता है. PEM फ़ाइल को सबसे ज़्यादा इस्तेमाल किए जाने वाले सर्टिफ़िकेट फ़ाइल फ़ॉर्मैट में बदलने के निर्देश नीचे दिए गए हैं.

उपलब्ध विकल्पों की पूरी सूची देखने के लिए, आधिकारिक OpenSSL Command Line Utilities दस्तावेज़ देखें.

openssl पाने के निर्देशों के लिए, OpenSSL का इस्तेमाल करना सेक्शन देखें.

मैं PEM फ़ाइल को DER फ़ॉर्मैट में कैसे बदलूं?

openssl का इस्तेमाल करके, फ़ाइल को PEM से DER में बदलने के लिए यह कमांड जारी किया जा सकता है:

openssl x509 -in roots.pem -outform der -out roots.der
मैं PEM फ़ाइल को PKCS #7 में कैसे बदलूं?

openssl का इस्तेमाल करके, फ़ाइल को PEM से PKCS #7 में बदलने के लिए नीचे दिया गया कमांड जारी किया जा सकता है:

openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b
मैं किसी PEM फ़ाइल को PKCS #12 (PFX) में कैसे बदलूं?

openssl का इस्तेमाल करके, किसी फ़ाइल को PEM से PKCS #12 में बदलने के लिए यह कमांड जारी किया जा सकता है:

openssl pkcs12 -export -info -in roots.pem -out roots.p12 -nokeys

PKCS #12 संग्रह बनाते समय आपको फ़ाइल पासवर्ड देना होगा. अगर आपने PKCS #12 फ़ाइल को अपने सिस्टम में तुरंत इंपोर्ट नहीं किया है, तो पासवर्ड को किसी सुरक्षित जगह पर सेव करना न भूलें.

अपने रूट सर्टिफ़िकेट स्टोर से सर्टिफ़िकेट की सूची बनाना, उसे प्रिंट करना, और उसे एक्सपोर्ट करना

मैं Java की स्टोर से किसी सर्टिफ़िकेट को PEM फ़ाइल के तौर पर कैसे एक्सपोर्ट करूं?

keytool का इस्तेमाल करके, अपने सर्टिफ़िकेट स्टोर में सभी सर्टिफ़िकेट की सूची बनाने के लिए, यह कमांड जारी किया जा सकता है. साथ ही, हर सर्टिफ़िकेट को एक्सपोर्ट करने के लिए इस्तेमाल किए जा सकने वाले उपनाम का इस्तेमाल भी किया जा सकता है:

keytool -v -list -keystore certs.jks

बस certs.jks को अपने एनवायरमेंट में इस्तेमाल की जाने वाली सर्टिफ़िकेट डेटाबेस फ़ाइल से बदलें. यह आदेश हर प्रमाणपत्र का उपनाम भी दिखाएगा, जिसकी आपको ज़रूरत तब होगी, जब आप उसे निर्यात कर रहे हों.

किसी एक सर्टिफ़िकेट को PEM फ़ॉर्मैट में एक्सपोर्ट करने के लिए, यह निर्देश दें:

keytool -exportcert -rfc -keystore certs.jks -alias alias > alias.pem

बस certs.jks को अपने एनवायरमेंट में इस्तेमाल की जाने वाली सर्टिफ़िकेट की डेटाबेस फ़ाइल से बदलें. साथ ही, जिस सर्टिफ़िकेट को एक्सपोर्ट करना है उसके लिए alias और alias.pem दें.

ज़्यादा जानकारी के लिए, कृपया Java प्लैटफ़ॉर्म, स्टैंडर्ड वर्शन टूल रेफ़रंस: keytool मैन्युअल देखें.

मैं NSS रूट सर्टिफ़िकेट स्टोर से सर्टिफ़िकेट को PEM फ़ाइल के रूप में कैसे एक्सपोर्ट करूं?

certutil का इस्तेमाल करके, अपने सर्टिफ़िकेट स्टोर में मौजूद सभी सर्टिफ़िकेट की सूची बनाने के लिए, यह कमांड जारी किया जा सकता है. साथ ही, एक निकनेम भी एक्सपोर्ट किया जा सकता है, जिसका इस्तेमाल सर्टिफ़िकेट को एक्सपोर्ट करने के लिए किया जा सकता है:

certutil -L -d certdir

बस certdir को अपने एनवायरमेंट में इस्तेमाल किए जाने वाले सर्टिफ़िकेट के डेटाबेस पाथ से बदलें. यह निर्देश हर उस सर्टिफ़िकेट का निकनेम भी दिखाएगा जिसकी ज़रूरत आपको तब होगी, जब उसे सर्टिफ़िकेट एक्सपोर्ट करना हो.

किसी एक सर्टिफ़िकेट को PEM फ़ॉर्मैट में एक्सपोर्ट करने के लिए, यह निर्देश दें:

certutil -L -n cert-name -a -d certdir > cert.pem

बस certdir को अपने एनवायरमेंट में इस्तेमाल किए जाने वाले सर्टिफ़िकेट के डेटाबेस पाथ से बदलें. साथ ही, जिस सर्टिफ़िकेट को एक्सपोर्ट करना है उसके लिए cert-name और cert.pem दें.

ज़्यादा जानकारी के लिए, कृपया आधिकारिक NSS टूल सर्टिफ़िकेट मैन्युअल और साथ ही, ऑपरेटिंग सिस्टम से जुड़े दस्तावेज़ देखें.

PEM सर्टिफ़िकेट को ऐसे फ़ॉर्मैट में प्रिंट करने का तरीका जिसे कोई भी व्यक्ति आसानी से पढ़ सके

यहां दिए गए उदाहरणों में, हम मानते हैं कि आपके पास GTS_Root_R1.pem फ़ाइल में यह कॉन्टेंट है:

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
MIIFWjCCA0KgAwIBAgIQbkepxUtHDA3sM9CJuRz04TANBgkqhkiG9w0BAQwFADBH
MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM
QzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwHhcNMTYwNjIyMDAwMDAwWhcNMzYwNjIy
MDAwMDAwWjBHMQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNl
cnZpY2VzIExMQzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQC2EQKLHuOhd5s73L+UPreVp0A8of2C+X0yBoJx9vaM
f/vo27xqLpeXo4xL+Sv2sfnOhB2x+cWX3u+58qPpvBKJXqeqUqv4IyfLpLGcY9vX
mX7wCl7raKb0xlpHDU0QM+NOsROjyBhsS+z8CZDfnWQpJSMHobTSPS5g4M/SCYe7
zUjwTcLCeoiKu7rPWRnWr4+wB7CeMfGCwcDfLqZtbBkOtdh+JhpFAz2weaSUKK0P
fyblqAj+lug8aJRT7oM6iCsVlgmy4HqMLnXWnOunVmSPlk9orj2XwoSPwLxAwAtc
vfaHszVsrBhQf4TgTM2S0yDpM7xSma8ytSmzJSq0SPly4cpk9+aCEI3oncKKiPo4
Zor8Y/kB+Xj9e1x3+naH+uzfsQ55lVe0vSbv1gHR6xYKu44LtcXFilWr06zqkUsp
zBmkMiVOKvFlRNACzqrOSbTqn3yDsEB750Orp2yjj32JgfpMpf/VjsPOS+C12LOO
Rc92wO1AK/1TD7Cn1TsNsYqiA94xrcx36m97PtbfkSIS5r762DL8EGMUUXLeXdYW
k70paDPvOmbsB4om3xPXV2V4J95eSRQAogB/mqghtqmxlbCluQ0WEdrHbEg8QOB+
DVrNVjzRlwW5y0vtOUucxD/SVRNuJLDWcfr0wbrM7Rv1/oFB2ACYPTrIrnqYNxgF
lQIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV
HQ4EFgQU5K8rJnEaK0gnhS9SZizv8IkTcT4wDQYJKoZIhvcNAQEMBQADggIBADiW
Cu49tJYeX++dnAsznyvgyv3SjgofQXSlfKqE1OXyHuY3UjKcC9FhHb8owbZEKTV1
d5iyfNm9dKyKaOOpMQkpAWBz40d8U6iQSifvS9efk+eCNs6aaAyC58/UEBZvXw6Z
XPYfcX3v73svfuo21pdwCxXu11xWajOl40k4DLh9+42FpLFZXvRq4d2h9mREruZR
gyFmxhE+885H7pwoHyXa/6xmld01D1zvICxi/ZG6qcz8WpyTgYMpl0p8WnK0OdC3
d8t5/Wk6kjftbjhlRn7pYL15iJdfOBL07q9bgsiG1eGZbYwE8na6SfZu6W0eX6Dv
J4J2QPim01hcDyxC2kLGe4g0x8HYRZvBPsVhHdljUEn2NIVq4BjFbkerQUIpm/Zg
DdIx02OYI5NaAIFItO/Nis3Jz5nu2Z6qNuFoS3FJFDYoOj0dzpqPJeaAcWErtXvM
+SUWgeExX6GjfhaknBZqlxi9dnKlC54dNuYvoS++cJEPqOba+MSSQGwlfnuzCdyy
F62ARPBopY+Udf90WuioAnwMCeKpSwughQtiue+hMZL77/ZRBIls6Kl0obsXs7X9
SQ98POyDGCBDTtWTurQ0sR8WNh8M5mQ5Fkzc4P4dyKliPUDqysU0ArSuiYgzNdws
E3PYJ/HQcu51OyLemGhmW/HGY0dVHLqlCFF1pkgl
-----END CERTIFICATE-----
OpenGL का इस्तेमाल करके सर्टिफ़िकेट फ़ाइलें प्रिंट करना

निर्देश देना

openssl x509 -in GTS_Root_R1.pem -text

इसका आउटपुट होना चाहिए:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Validity
            Not Before: Jun 22 00:00:00 2016 GMT
            Not After : Jun 22 00:00:00 2036 GMT
        Subject: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    …
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                E4:AF:2B:26:71:1A:2B:48:27:85:2F:52:66:2C:EF:F0:89:13:71:3E
    Signature Algorithm: sha384WithRSAEncryption
        …

openssl पाने के निर्देशों के लिए, OpenSSL का इस्तेमाल करना सेक्शन देखें.

Java कीटूल का इस्तेमाल करके सर्टिफ़िकेट प्रिंट करना

यह निर्देश जारी कर रहा है

keytool -printcert -file GTS_Root_R1.pem

इसका आउटपुट होना चाहिए:

Owner: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Issuer: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Serial number: 6e47a9c54b470c0dec33d089b91cf4e1
Valid from: Wed Jun 22 02:00:00 CEST 2016 until: Sun Jun 22 02:00:00 CEST 2036
Certificate fingerprints:
   SHA1: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
   SHA256: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: E4 AF 2B 26 71 1A 2B 48   27 85 2F 52 66 2C EF F0  ..+&q.+H'./Rf,..
0010: 89 13 71 3E                                        ..q>
]
]

keytool पाने के निर्देशों के लिए, Java कीटूल पाना सेक्शन देखें.

मैं कैसे देखूं कि मेरे रूट सर्टिफ़िकेट स्टोर में कौनसे सर्टिफ़िकेट इंस्टॉल किए गए हैं?

यह हर ऑपरेटिंग सिस्टम और एसएसएल/TLS लाइब्रेरी के हिसाब से अलग-अलग होता है. हालांकि, रूट सर्टिफ़िकेट स्टोर में सर्टिफ़िकेट को इंपोर्ट और एक्सपोर्ट करने की अनुमति देने वाले टूल में, इंस्टॉल किए गए सर्टिफ़िकेट की सूची बनाने का विकल्प भी होता है.

साथ ही, अगर आपने भरोसेमंद रूट सर्टिफ़िकेट को PEM फ़ाइलों में एक्सपोर्ट कर लिया है या आपके रूट सर्टिफ़िकेट स्टोर में, पहले से सेव की गई PEM फ़ाइलें मौजूद हैं, तो फ़ाइलों को किसी भी टेक्स्ट एडिटर में खोला जा सकता है. ऐसा इसलिए, क्योंकि यह एक सामान्य टेक्स्ट फ़ाइल फ़ॉर्मैट है.

PEM फ़ाइल को सही तरीके से लेबल किया जा सकता है, जिसमें संबंधित प्रमाणपत्र प्राधिकरण की मानवीय पठनीय जानकारी दी गई हो (भरोसेमंद Google रूट CA बंडल से उदाहरण):

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1"
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

फ़ाइल में सिर्फ़ सर्टिफ़िकेट वाला हिस्सा भी हो सकता है. ऐसे मामलों में, फ़ाइल के नाम, जैसे कि GTS_Root_R1.pem से यह पता चल सकता है कि सर्टिफ़िकेट किस CA से जुड़ा है. हर CA के लिए -----BEGIN CERTIFICATE----- और -----END CERTIFICATE----- टोकन के बीच मौजूद सर्टिफ़िकेट स्ट्रिंग भी यूनीक होती है.

हालांकि, भले ही ऊपर दिए गए टूल मौजूद न हों, क्योंकि भरोसेमंद Google रूट CA बंडल में मौजूद हर सर्टिफ़िकेट को सही तरीके से लेबल किया गया है. फिर भी, आपके पास रूट सर्टिफ़िकेट के रूट CA को Issuer तक या PEM फ़ाइल सर्टिफ़िकेट स्ट्रिंग की तुलना करके मैच करने का विकल्प है.

वेब ब्राउज़र अपने खुद के रूट सर्टिफ़िकेट स्टोर का इस्तेमाल कर सकते हैं या ऑपरेशन की ओर से उपलब्ध कराए गए डिफ़ॉल्ट सर्टिफ़िकेट पर निर्भर हो सकते हैं. हालांकि, सभी मॉडर्न ब्राउज़र पर आपको उन रूट सीए के सेट को मैनेज करने या कम से कम देखने की सुविधा देनी चाहिए जिन पर उन्हें भरोसा है. ज़्यादा जानकारी के लिए सवाल देखें क्या JavaScript ऐप्लिकेशन में गड़बड़ी होने का खतरा है?

मोबाइल फ़ोन पर खास निर्देशों के लिए, दूसरा सवाल देखें मैं अपने मोबाइल फ़ोन पर भरोसेमंद रूट सर्टिफ़िकेट की जांच कैसे करूं?.

अन्य जानकारी

क्या आपको इस बारे में ज़्यादा जानकारी चाहिए?

हमेशा मुख्य रूप से अपने ऑपरेटिंग सिस्टम के दस्तावेज़, अपने ऐप्लिकेशन प्रोग्रामिंग भाषा(भाषाओं) के दस्तावेज़, और आपका ऐप्लिकेशन इस्तेमाल की जा रही किसी भी बाहरी लाइब्रेरी के दस्तावेज़ पर भरोसा करें.

अक्सर पूछे जाने वाले सवालों के साथ जानकारी का कोई भी अन्य सोर्स पुराना हो सकता है या गलत हो सकता है. इसे आधिकारिक नहीं माना जाना चाहिए. हालांकि, आपको अब भी कई Stack Exchange सवाल और जवाब की कम्यूनिटी के साथ-साथ Linux पर AdamW और अन्य प्लैटफ़ॉर्म और ब्लॉग की पुष्टि करें जैसी साइटों के बारे में काम की जानकारी मिल सकती है.

कृपया Google Trust Services के बारे में अक्सर पूछे जाने वाले सवाल भी देखें.

सर्टिफ़िकेट पिन करने जैसे बेहतर विषयों के बारे में ज़्यादा जानकारी के लिए, Open Web Application Security Project (OWASP) सर्टिफ़िकेट और पब्लिक की पिनिंग लेख और पिनिंग चीट शीट पर जाएं. Android से जुड़े खास निर्देशों के लिए, कृपया सुरक्षा और निजता के लिए Android के सबसे सही तरीके एचटीटीपीएस और एसएसएल की सुरक्षा ट्रेनिंग से जुड़ा आधिकारिक दस्तावेज़ देखें. Android पर सर्टिफ़िकेट बनाम सार्वजनिक पासकोड को पिन करने के बारे में चर्चा के लिए, मैथ्यू डोलन का ब्लॉग पोस्ट Android सिक्योरिटी: एसएसएल पिनिंग काम का हो सकता है.

सुरक्षा और निजता के लिए Android के सबसे सही तरीके नेटवर्क सिक्योरिटी कॉन्फ़िगरेशन से जुड़ी ट्रेनिंग का दस्तावेज़ और JeroenHD की ब्लॉग पोस्ट Android 7 Nougat और सर्टिफ़िकेट देने वाली संस्थाएं Android पर दूसरे भरोसेमंद सर्टिफ़िकेट को मैनेज करने के बारे में ज़्यादा जानकारी दें.

एओएसपी के भरोसेमंद रूट CA की पूरी सूची देखने के लिए, ca-certificates Git रिपॉज़िटरी देखें. गैर-आधिकारिक Android फ़ोर्क पर आधारित किसी भी वर्शन के लिए, जैसे LineageOS, ओएस वेंडर की ओर से उपलब्ध कराए गए डेटा स्टोर करने की सही जगह देखें.