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

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

ज़्यादा जानकारी के लिए, यह किस बारे में है? लेख पढ़ें.

शब्दावली

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

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

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

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

खास जानकारी: अगर आपने https://pki.goog/faq/#connecting-to-google पर दिए गए दिशा-निर्देशों का पालन नहीं किया, तो आने वाले समय में आपको सर्टिफ़िकेट से जुड़ी समस्याएं हो सकती हैं.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नए रूट सर्टिफ़िकेट के बारे में https://pki.goog/updates/ पर सूचना दी जाएगी. यहां एक आरएसएस फ़ीड भी उपलब्ध है. अपडेट की सूचनाएं पाने के लिए, इसकी सदस्यता ली जा सकती है. हम सिर्फ़ नए रूट के बारे में सूचना देते हैं. सर्टिफ़िकेट चेन में बदलाव होने पर, लंबे समय तक इस्तेमाल किए जाने वाले रूट के बीच में बदलाव की सूचना नहीं दी जाती. ऐसा कभी भी हो सकता है. आपको किसी एक रूट या इंटरमीडिएट को पिन नहीं करना चाहिए. साथ ही, अगर आपको Google से भरोसेमंद कनेक्शन चाहिए, तो आपको Google के उन सभी रूट पर भरोसा करना होगा जिनके बारे में https://pki.goog/faq/#connecting-to-google पर बताया गया है.

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

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

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

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

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

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

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

अपने ऐप्लिकेशन एनवायरमेंट की जांच करें. इसके लिए, https://pki.goog/repository/ के 'Root CAs' सेक्शन में दिए गए सभी रूट का इस्तेमाल करें

आपका सिस्टम, रूट CA में किए गए बदलावों के साथ आम तौर पर तब काम करेगा, जब:

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

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

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

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

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

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

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

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

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

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

यह उदाहरण GTS R1 के लिए है. टेस्टिंग, सभी GTS रूट के हिसाब से की जानी चाहिए.

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; \

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Google, आपके ऐप्लिकेशन से कनेक्ट होने वाले Google डोमेन के लिए, सर्टिफ़िकेट या सार्वजनिक कुंजियों को पिन करने से रोकता है. पिन करने पर, उसके टूटने का खतरा बढ़ जाता है.

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

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

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

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

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

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

इसके अलावा, सवाल I'm building a product that connects to Google services. मुझे किन CA सर्टिफ़िकेट पर भरोसा करना चाहिए? ज़्यादा सुझाव पाने के लिए, GTS के बारे में अक्सर पूछे जाने वाले सवाल पढ़ें.

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

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

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

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

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

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

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

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

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

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

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

GTS रूट CA, iOS के 12.1.3 वर्शन से काम कर रहे हैं. इनमें GTS Root R1 भी शामिल है.

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

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

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

इसलिए, यह मुमकिन है कि चालू हालत में मौजूद कोई भी सिस्टम, GTS के रूट CA के साथ काम करता हो. साथ ही, लेगसी सिस्टम भी GlobalSign Root CA - R1 के साथ काम कर सकते हैं. इसका इस्तेमाल, Google की ओर से जारी किए गए कई सर्टिफ़िकेट को क्रॉस-साइन करने के लिए किया जाएगा.

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

Mozillaʼs CA Certificate Program जैसे तीसरे पक्ष की कुछ कंपनियां, सर्टिफ़िकेट शामिल करने की टाइमलाइन के बारे में जानकारी दे सकती हैं.

समस्या का हल

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

कर्ल करना

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

OpenSSL पाना

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

Wireshark, Tshark या Tcpdump पाना

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

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

इन उपयोगी टूल के बारे में ज़्यादा जानकारी, Wireshark User's Guide, 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;
curl -vvI https://good.gtsr2.demosite.pki.goog/; \
openssl s_client -connect good.gtsr2.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr3.demosite.pki.goog/; \
openssl s_client -connect good.gtsr3.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr4.demosite.pki.goog/; \
openssl s_client -connect good.gtsr4.demosite.pki.goog:443 -showcerts </dev/null; \

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

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

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

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

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

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

सार्वजनिक समस्या 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 चलाने पर, काम की कई जानकारी मिलती है. आउटपुट को समझने के लिए, यहां कुछ निर्देश दिए गए हैं:

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

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

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

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

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

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

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

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

* successfully set certificate verify locations:
* CAfile: /home/<user>/Downloads/roots.pem
  CApath: /etc/ssl/certs
सेक्शन देखें.

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

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

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

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

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

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

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

TLS हैंडशेक पूरा हो गया

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

*   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 के सर्टिफ़िकेट कैसे दिखते हैं?

{# disableFinding(LINE_OVER_80)}

…
---
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 और इसके बाद के वर्शन के लिए, भरोसेमंद रूट CA के सेट के लिंक हैं:

हालांकि, 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 Tools certutil के आधिकारिक मैन्युअल के साथ-साथ अपने ऑपरेटिंग सिस्टम का दस्तावेज़ देखें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इसके बाद, अलग-अलग पीईएम फ़ाइलों, जैसे कि 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 संग्रह बनाते समय, आपको फ़ाइल का पासवर्ड देना होगा. अगर आपको पीकेसीएस #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{: .external} मैनुअल देखें.

मैं 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 का इस्तेमाल करके सर्टिफ़िकेट प्रिंट करना

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

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 रूट CA बंडल से लिया गया यह उदाहरण देखें:

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

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

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

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

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

अन्य जानकारी

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

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

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

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

क्रिप्टोग्राफ़ी, पीकेआई, सर्टिफ़िकेट, और सर्टिफ़िकेट चेन के बारे में कम शब्दों में जानकारी पाने के लिए, पॉल टर्नर की पीकेआई बूटकैंप YouTube प्लेलिस्ट देखें.

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

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

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