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

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

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

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

शब्दावली

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

एसएसएल/टीएलएस सर्टिफ़िकेट

सर्टिफ़िकेट किसी पहचान से क्रिप्टोग्राफ़िक कुंजी को बाइंड करता है.

एसएसएल/टीएलएस सर्टिफ़िकेट का इस्तेमाल, वेबसाइटों की पुष्टि करने और उन्हें सुरक्षित तरीके से कनेक्ट करने के लिए किया जाता है. सर्टिफ़िकेट जारी करने वाली और क्रिप्टोग्राफ़िक तौर पर उन इकाइयों पर हस्ताक्षर किए जाते हैं जिन्हें सर्टिफ़िकेट देने वाली संस्था कहा जाता है.

ब्राउज़र, सर्टिफ़िकेट देने वाली किसी भरोसेमंद संस्था के जारी किए गए सर्टिफ़िकेट पर भरोसा करते हैं. इससे उन्हें पता चलता है कि ट्रांसफ़र की गई जानकारी सही सर्वर पर भेजी गई है और ट्रांसफ़र के दौरान उसे एन्क्रिप्ट (सुरक्षित) किया गया है.

सिक्योर सॉकेट लेयर (एसएसएल)

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

ट्रांसपोर्ट लेयर सुरक्षा (TLS)

ट्रांसपोर्ट लेयर सिक्योरिटी, एसएसएल का बाद वाला विकल्प है.

सर्टिफ़िकेट देने वाली संस्था (सीए)

सर्टिफ़िकेट अथॉरिटी, डिवाइसों और लोगों के लिए डिजिटल पासपोर्ट ऑफ़िस की तरह होती है. किसी इकाई (जैसे कि वेबसाइट) की पहचान होने की पुष्टि करने के लिए, वह क्रिप्टोग्राफ़िक तौर पर सुरक्षित दस्तावेज़ (सर्टिफ़िकेट) जारी करती है.

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

सर्टिफ़िकेट अथॉरिटी का मतलब Google Trust Services जैसे संगठनों और सर्टिफ़िकेट देने वाले सिस्टम, दोनों के लिए हो सकता है.

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

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

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

आम तौर पर, इंडस्ट्री स्टैंडर्ड का पालन करना ज़रूरी है, जैसे कि कैलिफ़ोर्निया/ब्राउज़र फ़ोरम की ज़रूरी शर्तें.

रूट सर्टिफ़िकेट अथॉरिटी

रूट सर्टिफ़िकेट देने वाली संस्था (या बेहतर तरीके से, उसका सर्टिफ़िकेट), सर्टिफ़िकेट चेन में सबसे ऊपर मौजूद सर्टिफ़िकेट होता है.

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

इंटरमीडिएट सर्टिफ़िकेट अथॉरिटी

इंटरमीडिएट सर्टिफ़िकेट देने वाली संस्था (या बेहतर ढंग से, उसका सर्टिफ़िकेट), एक ऐसा सर्टिफ़िकेट होता है जिसका इस्तेमाल किसी सर्टिफ़िकेट चेन में अन्य सर्टिफ़िकेट पर हस्ताक्षर करने के लिए किया जाता है.

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

इंटरमीडिएट सीए को सबऑर्डिनेटर सीए भी कहा जाता है.

जारी करने वाला सर्टिफ़िकेट देने वाली संस्था

जारी करने वाली सर्टिफ़िकेट देने वाली संस्था या इसका सर्टिफ़िकेट, एक ऐसा सर्टिफ़िकेट होता है जिसका इस्तेमाल, सर्टिफ़िकेट चेन में सबसे नीचे वाले सर्टिफ़िकेट पर हस्ताक्षर करने के लिए किया जाता है.

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

सर्टिफ़िकेट चेन

सर्टिफ़िकेट, उन्हें जारी करने वाले से लिंक (क्रिप्टोग्राफ़िक तरीके से हस्ताक्षर किए गए) होते हैं. सर्टिफ़िकेट चेन, लीफ़-सर्टिफ़िकेट, जारी करने वाले सभी सर्टिफ़िकेट, और रूट सर्टिफ़िकेट से बनी होती है.

क्रॉस-हस्ताक्षर

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

पुराने क्लाइंट के साथ काम करने की क्षमता बढ़ाने के लिए, सीए सर्टिफ़िकेट, दूसरे पुराने सीए सर्टिफ़िकेट "क्रॉस-साइन किए गए" के तौर पर इस्तेमाल किए जा सकते हैं. इससे एक ही पहचान (नाम और कुंजी का जोड़ा) के लिए, असरदार ढंग से दूसरा CA सर्टिफ़िकेट बन जाता है.

रूट सर्टिफ़िकेट स्टोर में मौजूद सीए सर्टिफ़िकेट के आधार पर, क्लाइंट एक भरोसेमंद रूट के हिसाब से सर्टिफ़िकेट की एक अलग चेन बनाएंगे.

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

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

पूरा नज़रिया

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

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

आम तौर पर, सभी TLS क्लाइंट (जैसे कि वेब ब्राउज़र, स्मार्टफ़ोन, और ऐप्लिकेशन सर्वर) ने इस रूट सर्टिफ़िकेट पर भरोसा किया है. इसलिए, माइग्रेट करने के पहले चरण में 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 से क्रॉस-साइन हासिल किया है. यह मौजूदा समय में उपलब्ध सबसे पुराने और सबसे भरोसेमंद रूट CA में से एक है.

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

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

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

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

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

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

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

तकनीकी सारांश

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

आम तौर पर, आपका सिस्टम रूट सीए (सर्टिफ़िकेट देने वाली संस्था) के इस बदलाव के साथ काम करेगा, अगर:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इन बातों का ध्यान रखें

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

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

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

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

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

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

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

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

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

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

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

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

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

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

और विवरण के लिए क्या मोबाइल ऐप्लिकेशन के टूट जाने का खतरा है? देखें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

कर्ल पाना

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

OpenSSL को इंस्टॉल किया जा रहा है

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

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

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

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

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

Java कीटूल पाएं

keytool कमांड लाइन टूल को हर Java डेवलपमेंट किट (जेडीके) या Java रनटाइम एनवायरमेंट (जेआरई) वर्शन के साथ भेजना चाहिए. 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.demo.pki.goog/; \
   openssl s_client -connect good.gtsr1.demo.pki.goog:443 -showcerts </dev/null; \
   curl -vvI https://good.gtsr1x.demo.pki.goog/; \
   openssl s_client -connect good.gtsr1x.demo.pki.goog:443 -showcerts </dev/null;
   

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

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

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

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

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

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

सार्वजनिक अंक 186840968 पर पोस्ट किया जा रहा है

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

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

Linux पर, यहां दिया गया कमांड चलाया जा सकता है:

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

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

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

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

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

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

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

-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 और आपके सिस्टम के बारे में काम की जानकारी मिल सकती है.

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 से एन्क्रिप्ट (सुरक्षित) किए गए कनेक्शन पर भेजा जा रहा है:

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

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

---
…

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

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

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

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

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

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

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

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

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

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

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

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

• iOS 12.1.3, macOS 10.14.3, watchOS 5.1.3, और tvOS 12.1.2 में उपलब्ध भरोसेमंद रूट सर्टिफ़िकेट की सूची
• iOS 5 और iOS 6: उपलब्ध भरोसेमंद रूट सर्टिफ़िकेट की सूची.

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

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

iOS वर्शन	जीटीएस रूट R1	ग्लोबलसाइन रूट सीए - R1	GlobalSign Root R2 (15 दिसंबर, 2021 तक मान्य)
5, 6, 7, 8, 9, 10, 11, 12.0 के बराबर
12.1.3+

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

डिफ़ॉल्ट रूट सर्टिफ़िकेट के स्टोर की जगह, ऑपरेटिंग सिस्टम और इस्तेमाल की गई एसएसएल/टीएलएस लाइब्रेरी के हिसाब से अलग-अलग होती है. हालांकि, ज़्यादातर 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: आरएचईएल, सेंटओएस

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

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

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 के लेख देखें:

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

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 फ़ाइल क्या है?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ls -l *.pem

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

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

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

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

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

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

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

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

openssl x509 -in roots.pem -outform der -out roots.der

मैं PEM फ़ाइल को PKCS #7 में कैसे बदलूं?

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

openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b

मैं किसी PEM फ़ाइल को PKCS #12 (PFX) में कैसे बदलूं?

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

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

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

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

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

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

keytool -v -list -keystore certs.jks

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

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

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

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

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

मैं 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 के लिए मैन्युअल और अपने ऑपरेटिंग सिस्टम से जुड़े दस्तावेज़ देखें.

PEM सर्टिफ़िकेट ऐसे फ़ॉर्मैट में प्रिंट करें जिसे आसानी से पढ़ा जा सके

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

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

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

निर्देश देना

openssl x509 -in GTS_Root_R1.pem -text

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

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

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

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

यह निर्देश देना

keytool -printcert -file GTS_Root_R1.pem

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

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

Extensions:

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

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

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

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

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

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

साथ ही, अगर आपने भरोसेमंद रूट सर्टिफ़िकेट को PEM फ़ाइलों में एक्सपोर्ट कर लिया है या आपके रूट सर्टिफ़िकेट के स्टोर में पहले से ही सेव की गई 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 के बारे में अक्सर पूछे जाने वाले सवाल भी देखें.

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

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

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