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

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

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

शब्दावली

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

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

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

यह किस बारे में है?

पूरा डेटा

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

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

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

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

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

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

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

अगर आपको Google Maps Platform की सेवाओं से कनेक्ट करने में समस्याएं आ रही हैं, तो आपको अपने सिस्टम की पुष्टि करनी चाहिए. ऐसा तब करें, जब आपके सिस्टम पर ये शर्तें लागू हों:

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

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

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

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

तकनीकी जानकारी

Google Security Blog पर 15 मार्च, 2021 को एलान किया गया था कि GS Root R2, Google Maps Platform का रूट सीए, 15 दिसंबर, 2021 को एक्सपायर हो जाएगा. इसका इस्तेमाल 2018 की शुरुआत से किया जा रहा था. इसलिए, Google को नए जारी किए गए CA GTS Root R1 Cross पर माइग्रेट कर दिया जाएगा.

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

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

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

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

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

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

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

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

हमारा सुझाव है कि आप Google Security Blog को फ़ॉलो करें. हम ब्लॉग पर किए गए एलान के बाद, प्रॉडक्ट से जुड़े दस्तावेज़ों को जल्द से जल्द अपडेट करने की कोशिश करेंगे.

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

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

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

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

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

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

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

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

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

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

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

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

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

आपको अपनी जांच में, दो कमांड लाइन टूल 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.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

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

भरोसेमंद Google रूट सीए बंडल डाउनलोड करें. इसके बाद, यह तरीका अपनाएं:

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.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

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

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

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

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

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

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

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

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

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

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

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

किन बातों का ध्यान रखना चाहिए

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

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

Google Maps Platform के साथ कम्यूनिकेट करने के लिए, TLS क्लाइंट की ज़रूरी शर्तें क्या हैं?

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

हालांकि, TLS के लेगसी वर्शन 1.0 और 1.1 अब भी काम करते हैं, लेकिन हमारा सुझाव है कि इनका इस्तेमाल न करें. अगर हो सके, तो TLS 1.3 का इस्तेमाल करें.

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

किस तरह के ऐप्लिकेशन काम नहीं कर सकते?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

क्या JavaScript ऐप्लिकेशन काम नहीं कर सकते?

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

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

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

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

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

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

iOS के 12.1.3 वर्शन से, GTS Root R1 के साथ-साथ GTS रूट सीए काम करते हैं.

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

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

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

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

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

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

समस्या का हल

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

कर्ल

अगर आपके ओएस डिस्ट्रिब्यूशन में 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 पाना

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

प्रोडक्शन में आने वाली रुकावट के दौरान क्या करना चाहिए

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

  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.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

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

सहायता अनुरोध सबमिट करना

Google Maps Platform की सहायता और संसाधन में जाकर, सहायता केस बनाने के लिए दिए गए निर्देशों का पालन करें.

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

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

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

सार्वजनिक समस्या 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

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

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

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

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

बाहर भेजे जाने वाले अनुरोधों में 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 हैंडशेक पूरा नहीं हो सका

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

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

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 सर्टिफ़िकेट को प्रिंट करने का तरीका सेक्शन देखें.

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

…
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.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.demosite.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 वर्चुअल डिवाइस (एवीडी) सिस्टम इमेज का इस्तेमाल करके, मैन्युअल तरीके से की गई पुष्टि के आधार पर तय की गई है. अगर सिस्टम इमेज उपलब्ध नहीं हैं, तो AOSP ca-certificates Git रिपॉज़िटरी के वर्शन के इतिहास का इस्तेमाल किया जाता है:

Android वर्शन GTS Root 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 वर्शन पर, आने वाले कई सालों तक बिना किसी रुकावट के सेवा मिलती रहेगी. यह सेवा, मौजूदा ज़्यादातर डिवाइसों के लाइफ़टाइम के बाद भी मिलती रहेगी.

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

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

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

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

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

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

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

iOS वर्शन GTS Root 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 टूल का इस्तेमाल करें.

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

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

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

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

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

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

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

पीईएम फ़ाइल क्या है?

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

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

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

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

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

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

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

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

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

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

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

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

यहां दी गई आसान bash स्क्रिप्ट का इस्तेमाल करके, 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 फ़ाइलों की तरह कई अलग-अलग 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

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

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

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

उपलब्ध विकल्पों की पूरी सूची के लिए, OpenSSL कमांड लाइन यूटिलिटी का आधिकारिक दस्तावेज़ देखें.

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

पीकेसीएस #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, Standard Edition Tools Reference: 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 टूल्स certutil का आधिकारिक मैन्युअल और अपने ऑपरेटिंग सिस्टम का दस्तावेज़ देखें.

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

नीचे दिए गए उदाहरणों में, हम मानते हैं कि आपके पास 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 का इस्तेमाल करके सर्टिफ़िकेट प्रिंट करना

यह कमांड जारी करना

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 keytool पाने का तरीका सेक्शन देखें.

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

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

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

PEM फ़ाइल को सही तरीके से लेबल किया जा सकता है, ताकि उससे जुड़ी सर्टिफ़िकेट देने वाली संस्था के बारे में जानकारी आसानी से पढ़ी जा सके. उदाहरण के लिए, भरोसेमंद Google रूट सीए बंडल:

# 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. यह भी ज़रूरी है कि -----BEGIN CERTIFICATE----- और -----END CERTIFICATE----- टोकन के बीच मौजूद सर्टिफ़िकेट स्ट्रिंग, हर सीए के लिए यूनीक हो.

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

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

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

अन्य जानकारी

क्या आपको और जानकारी चाहिए?

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

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

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

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

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

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