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

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

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

शब्दावली

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

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

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

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

पूरा मामला

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

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

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

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

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

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

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

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

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

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

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

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

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

Google के सुरक्षा ब्लॉग पर 15 मार्च, 2021 को दी गई जानकारी के मुताबिक, GS Root R2 रूट का इस्तेमाल किया जा रहा है. कैलिफ़ोर्निया 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 शामिल हैं, तो मौजूदा माइग्रेशन का असर आपकी सेवाओं पर नहीं पड़ेगा. साथ ही, इन्हें सिंक में रखने से, आने वाले दिनों में होने वाले रूट सर्टिफ़िकेट के बदलावों से भी आपकी सुरक्षा होगी.

सवाल देखें मुझे अपने रूट सर्टिफ़िकेट को भरोसेमंद 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 पाने के निर्देशों के लिए, नीचे OpenSSL इंस्टॉल करना सेक्शन देखें.

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

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

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

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 में की गई थी. यह आने वाले महीनों में रोल आउट होगा. इसकी समयसीमा 15 दिसंबर, 2021 को GS Root R2 खत्म हो जाएगी.

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

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

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

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

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

कौन प्रभावित होगा, कब और कहां?

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

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

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

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

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

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

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

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

अन्य ज़रूरी शर्तों के बारे में जानने के लिए, जीटीएस के बारे में अक्सर पूछे जाने वाले सवाल सेक्शन में, 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 बंडल में मौजूद रूट CA की चुनी गई सूची में वे सभी CA शामिल हैं जिनका इस्तेमाल आने वाले समय में Google की सेवाएं शायद कर पाएं.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GTS Root R1 जैसे GTS रूट CA को iOS वर्शन 12.1.3 के बाद से इस्तेमाल किया जा रहा है.

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

मेरे ब्राउज़र या ऑपरेटिंग सिस्टम में 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ʼs CA Certificate Program ने सर्टिफ़िकेट शामिल करने की टाइमलाइन का दस्तावेज़ खुद ही तैयार किया हो.

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

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

कर्ल पाना

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

OpenSSL इंस्टॉल करना

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

Wireshark, Tshark या Tcpdump पाएं

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

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

इन उपयोगी टूल के दस्तावेज़, Wireshark के उपयोगकर्ता की गाइड, Tshark मैन पेज पर, और 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 के लिए सहायता और संसाधन सेक्शन में सहायता अनुरोध बनाने के लिए दिए गए निर्देशों का पालन करें.

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

  • आपके सार्वजनिक आईपी पते क्या हैं?
  • आपके डीएनएस सर्वर का सार्वजनिक आईपी पता क्या है?
  • अगर हो सके, तो PCAP फ़ॉर्मैट में https://maps.googleapis.com/ से फ़ेल हो चुके TLS नेगोशिएशन को tcpdump या Wireshark पैकेट कैप्चर करता है.साथ ही, पूरे पैकेट को छोटा किए बिना, उसे कैप्चर करने के लिए, बहुत बड़े स्नैपशॉट का इस्तेमाल करता है. उदाहरण के लिए, 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 लाइब्रेरी और रूट सर्टिफ़िकेट का बंडल

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

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

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

आउटगोइंग अनुरोधों में उपयोगकर्ता-एजेंट हेडर होता है, जिससे 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 से मिला आउटपुट, यहां दिया गया तरीका अपनाकर, दिखाया गया सर्टिफ़िकेट प्रिंट किया जा सकता है:

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

    -----BEGIN CERTIFICATE-----
    …
    -----END CERTIFICATE-----
    
  • इसके बाद:

    openssl x509 -inform pem -noout -text
    ````
    
  • फिर, अपने कॉपी बफ़र के कॉन्टेंट को टर्मिनल में चिपकाएं.

  • Return बटन दबाएं.

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

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

…
---
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 वर्चुअल डिवाइस (एवीडी) सिस्टम इमेज का इस्तेमाल करके मैन्युअल तरीके से पुष्टि करने के आधार पर, AOSP ca-certificates गिट रिपॉज़िटरी के वर्शन इतिहास पर वापस जाता है, जहां सिस्टम इमेज अब उपलब्ध नहीं थीं:

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

हालांकि, 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

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

OpenSSL रूट सर्टिफ़िकेट का स्टोर

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
…

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

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 से अलग-अलग सर्टिफ़िकेट कैसे निकालूं? देखें.

मैं origins.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 Platform, स्टैंडर्ड वर्शन टूल के रेफ़रंस: 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-----
OpenSSL का इस्तेमाल करके सर्टिफ़िकेट फ़ाइलें प्रिंट करना

निर्देश देना

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 फ़ाइल सर्टिफ़िकेट स्ट्रिंग की तुलना करके, अपने रूट सर्टिफ़िकेट स्टोर में मौजूद रूट CA से मिलान करने का विकल्प होता है.

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

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

Appendix

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

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

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

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

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

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

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