इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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

शब्दावली
सामान्य जानकारी
समस्या हल करने से जुड़ी जानकारी
अपने भरोसेमंद सर्टिफ़िकेट मैनेज करना
अनुबंध

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

शब्दावली

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

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

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

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

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

पूरा नज़रिया

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 के रूट CA GTS Root R1 के सर्टिफ़िकेट का इस्तेमाल करना होगा.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

पूरी जानकारी के लिए, मुझे अपने रूट सर्टिफ़िकेट के स्टोर को, भरोसेमंद 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 Maps Platform की सेवाओं को कॉल करने वाले, एम्बेड किए गए डिवाइस, एंटरप्राइज़ ऐप्लिकेशन और इंटिग्रेशन मिडलवेयर या रिलेशनल डेटाबेस जैसे खास सिस्टम का इस्तेमाल करने वाले ग्राहकों या जो पुराने लेगसी ब्राउज़र या ऑपरेटिंग सिस्टम अब नहीं चल रहे हैं उनका दूसरे चरण से बुरा असर पड़ सकता है. खास तौर पर, अगर उन्होंने पहले माइग्रेशन में कोई कार्रवाई नहीं की.

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

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

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

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

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

ध्यान दें: 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 रूट CA बंडल की पुष्टि की जा रही है

भरोसेमंद 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 रूट CA माइग्रेशन कब और कैसे जारी रहेगा?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

क्लाइंट-साइड 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 Root 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 से पहले के वर्शन में अब भी सीमित सहायता उपलब्ध हो.

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

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

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

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

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

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

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

इसलिए, इस बात की काफ़ी संभावना है कि फ़िलहाल इस्तेमाल किया जा रहा कोई भी सिस्टम, Google के नए GTS रूट सीए के साथ काम कर रहा हो. इनमें GTS रूट R1 भी शामिल है. साथ ही, यह भी मुमकिन है कि लेगसी सिस्टम, GlobalSign रूट सीए - 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 टीम ने इनका समर्थन नहीं किया है.

वायर शार्क, शार्क या टीसीपीडंप पाना

ज़्यादातर 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 रूट सीए बंडल से ज़रूरी रूट सर्टिफ़िकेट इंस्टॉल करें. इसके बाद, उन्हें रूट सर्टिफ़िकेट के स्टोर में डालें, जिनका इस्तेमाल आपके ऐप्लिकेशन में किया जाता है.

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

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

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

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

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

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

जिन सर्वर पर असर पड़ा है वे कहां हैं?
आपकी सेवा किन Google आईपी पतों पर कॉल कर रही है?
इस समस्या का असर किन एपीआई पर पड़ा है?
यह समस्या कब शुरू हुई?

नीचे दिए गए निर्देशों के आउटपुट:

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/ के लिए, फ़ेल हो चुके TLS नेगोशिएशन का tcpdump या Wireshark पैकेट कैप्चर किया जा सकता है.इसमें, पैकेट को छोटा किए बिना उसे कैप्चर करने के लिए, ज़रूरत के मुताबिक बड़े स्नैपशॉट का इस्तेमाल किया जाता है. जैसे, 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

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

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

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

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

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

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 साइट पर तुलना की टेबल देखें). इन सभी को अलग-अलग रूट सर्टिफ़िकेट बंडल/स्टोर का इस्तेमाल करने के लिए कॉन्फ़िगर किया जा सकता है. अगर curl को आपके ऐप्लिकेशन के बजाय किसी दूसरी एसएसएल/TLS लाइब्रेरी से लिंक किया गया है, तो आपको यह पक्का करना होगा कि दोनों एक ही रूट सर्टिफ़िकेट स्टोर पर ले जाएं, ताकि जांच के नतीजे पूरी तरह भरोसेमंद हों.

ध्यान दें: अगर आपने अपने ऐप्लिकेशन के लिए खुद का सर्टिफ़िकेट बंडल मैनेज किया है या ऐप्लिकेशन सिर्फ़ curl से अलग स्टोर का इस्तेमाल करता है और आपको अपने ऐप्लिकेशन के इस्तेमाल किए गए सर्टिफ़िकेट की पुष्टि करनी है, तो उस स्टोर से सर्टिफ़िकेट को पीईएम फ़ाइल में एक्सपोर्ट किया जा सकता है. इस फ़ाइल को --cacert फ़्लैग का इस्तेमाल करके curl पर पास किया जा सकता है. अपने भरोसेमंद सर्टिफ़िकेट मैनेज करना सेक्शन देखें.

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

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

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

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

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

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

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

iOS वर्शन	जीटीएस रूट R1	ग्लोबलसाइन रूट सीए - 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 कोड में बदले गए सर्टिफ़िकेट के डेटा की जानकारी को नहीं पढ़ा जा सकता. हालांकि, पीईएम स्पेसिफ़िकेशन में, कोड में बदले गए सर्टिफ़िकेट के मुख्य हिस्से से पहले या बाद में, पूरी जानकारी देने की अनुमति होती है. कई टूल इस सुविधा का इस्तेमाल करके, सर्टिफ़िकेट में सबसे काम के डेटा एलिमेंट की साफ़ तौर पर जानकारी देते हैं.

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

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

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

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

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

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

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

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

कुछ सिस्टम, जैसे कि Java keytool, किसी PEM फ़ाइल से सिर्फ़ एक सर्टिफ़िकेट इंपोर्ट कर सकता है, भले ही उसमें कई सर्टिफ़िकेट शामिल हों. फ़ाइल को अलग-अलग हिस्सों में बांटने का तरीका जानने के लिए, मैं 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 फ़ाइलें बननी चाहिए, जो यहां दी गई फ़ाइलों से मिलती-जुलती होंगी:

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 फ़ाइलों को अलग से इंपोर्ट किया जा सकता है या ऐसे फ़ाइल फ़ॉर्मैट में बदला जा सकता है जिसे आपका सर्टिफ़िकेट स्टोर स्वीकार करता है.

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

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 प्लैटफ़ॉर्म, स्टैंडर्ड वर्शन टूल का संदर्भ: कीटूल गाइड देखें.

मैं 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 Tools 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 -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 कीटूल पाना सेक्शन देखें.

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

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

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

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 वगैरह और पुष्टि ब्लॉग जैसी साइटों के बारे में काम की जानकारी मिल सकती है.

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

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

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

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