TLS को कॉन्फ़िगर करने के विकल्प

Apigee Edge के दस्तावेज़ देखे जा रहे हैं.
Apigee X के दस्तावेज़. जानकारी पर जाएं

इस दस्तावेज़ में, दो फ़ंक्शन वाले एरिया के लिए, Edge पर TLS को कॉन्फ़िगर करने के तरीके की खास जानकारी दी गई है:

1. एपीआई क्लाइंट से अपनी एपीआई प्रॉक्सी को ऐक्सेस करना. TLS को कॉन्फ़िगर करने के लिए, Edge राऊटर पर वर्चुअल होस्ट इस्तेमाल करें.
2. Edge से आपकी बैकएंड सेवाओं को ऐक्सेस किया जा सकता है. TLS को कॉन्फ़िगर करने के लिए, Edge Message प्रोसेसर पर टारगेट एंडपॉइंट और टारगेट सर्वर का इस्तेमाल करें.

ये दोनों ऐक्सेस टाइप नीचे दिए गए हैं:

वर्चुअल होस्ट या टारगेट एंडपॉइंट/टारगेट सर्वर में TLS के विकल्पों को सेट करने के बारे में जानकारी

वर्चुअल होस्ट को एक्सएमएल ऑब्जेक्ट के ज़रिए इस रूप में दिखाया जा सकता है:

<VirtualHost name="secure">
    ...
    <SSLInfo> 
        <Enabled>true</Enabled> 
        <ClientAuthEnabled>true</ClientAuthEnabled> 
        <KeyStore>ref://myKeystoreRef</KeyStore> 
        <KeyAlias>myKeyAlias</KeyAlias> 
        <TrustStore>ref://myTruststoreRef</TrustStore> 
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
    </SSLInfo>
</VirtualHost>

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

नीचे दी गई टेबल में, उन TLS कॉन्फ़िगरेशन एलिमेंट के बारे में बताया गया है जिनका इस्तेमाल <SSLInfo> टैग में किया जाता है:

<CommonName wildcardMatch="true">*.myhost.com</CommonName>

<KeyStore> और <TrustStore> एलिमेंट को सेट करने के बारे में जानकारी

ऊपर दिए गए वर्चुअल होस्ट के उदाहरण में, कीस्टोर और ट्रस्टस्टोर के बारे में जानकारी देने के लिए, references का इस्तेमाल किया गया है. यह जानकारी इस फ़ॉर्म में दी गई है:

<KeyStore>ref://myKeystoreRef</KeyStore>
<TrustStore>ref://myTruststoreRef</TrustStore>

Apigee का सुझाव है कि आप हमेशा कीस्टोर और ट्रस्टस्टोर के रेफ़रंस इस्तेमाल करें. रेफ़रंस एक ऐसा वैरिएबल होता है जिसमें कीस्टोर या ट्रस्टस्टोर का नाम होता है. इसमें सीधे कीस्टोर का नाम बताने के बजाय, कीस्टोर का नाम शामिल होता है. इस उदाहरण में:

• myKeystoreRef एक ऐसी पहचान फ़ाइल है जिसमें कीस्टोर का नाम होता है. इस उदाहरण में, कीस्टोर का नाम myKeystore है.
• myTruststoreRef एक ऐसी पहचान फ़ाइल है जिसमें ट्रस्टस्टोर का नाम शामिल होता है. इस उदाहरण में, ट्रस्टस्टोर का नाम myTruststore है.

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

• Cloud के ग्राहकों के लिए: पहचान फ़ाइल की वैल्यू बदलने के लिए, आपको Apigee Edge की सहायता टीम से संपर्क करने की ज़रूरत नहीं होगी.
• निजी क्लाउड का इस्तेमाल करने वाले ग्राहकों के लिए: पहचान फ़ाइल की वैल्यू बदलने के लिए, आपको राऊटर और मैसेज प्रोसेसर जैसे Edge कॉम्पोनेंट को फिर से चालू करने की ज़रूरत नहीं होती.

इसके अलावा, कीस्टोर का नाम और ट्रस्टस्टोर का नाम सीधे तौर पर तय किया जा सकता है:

<KeyStore>myKeystore</KeyStore>
<TrustStore>myTruststore</TrustStore> 

अगर कीस्टोर या ट्रस्टस्टोर का नाम सीधे तौर पर बताया जाता है, तो Cloud के ग्राहकों को Apigee Edge की सहायता टीम से संपर्क करना होगा. साथ ही, Private Cloud के ग्राहकों को सर्टिफ़िकेट को अपडेट करने के लिए, कुछ Edge कॉम्पोनेंट को रीस्टार्ट करना होगा.

तीसरा विकल्प, सिर्फ़ टारगेट एंडपॉइंट/टारगेट सर्वर के लिए, फ़्लो वैरिएबल का इस्तेमाल करना है:

<KeyStore>{ssl.keystore}</KeyStore>
<TrustStore>{ssl.truststore}</TrustStore> 

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

कीस्टोर और ट्रस्टस्टोर के रेफ़रंस इस्तेमाल करने से जुड़ी पाबंदियां

कीस्टोर और ट्रस्टस्टोर के रेफ़रंस का इस्तेमाल करते समय, पेड क्लाउड के ग्राहकों और TLS को कॉन्फ़िगर करने वाले सभी Private Cloud ग्राहकों को इस पाबंदी को ध्यान में रखना होगा:

• Apigee Routers पर TLS को बंद करने पर, वर्चुअल होस्ट में सिर्फ़ कीस्टोर और ट्रस्टस्टोर रेफ़रंस का इस्तेमाल किया जा सकता है.

• अगर आपके पास Apigee Routers के सामने लोड बैलेंसर है और लोड बैलेंसर पर TLS को खत्म कर दिया जाता है, तो वर्चुअल होस्ट में कीस्टोर और ट्रस्टस्टोर रेफ़रंस का इस्तेमाल नहीं किया जा सकता.

अगर आपका मौजूदा वर्चुअल होस्ट, लिटरल कीस्टोर या ट्रस्टस्टोर नाम का इस्तेमाल करता है

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

1. मेघ

   कीस्टोर के रेफ़रंस का इस्तेमाल करने के लिए, वर्चुअल होस्ट को बदलने के लिए, आपको Apigee Edge की सहायता टीम की मदद लेनी होगी.

2. प्राइवेट क्लाउड के लिए एज

   वर्चुअल होस्ट को रेफ़रंस का इस्तेमाल करने के लिए बदलने के लिए:

   1. रेफ़रंस का इस्तेमाल करने के लिए, वर्चुअल होस्ट को अपडेट करें.
   2. राऊटर को रीस्टार्ट करें.
   ज़्यादा जानकारी के लिए निजी क्लाउड के लिए किसी एपीआई के लिए TLS का ऐक्सेस कॉन्फ़िगर करना में जाकर, " कीस्टोर और ट्रस्टस्टोर के लिए रेफ़रंस इस्तेमाल करने के लिए, वर्चुअल होस्ट में बदलाव करना" देखें.

Apigee के मुफ़्त में आज़माने वाले सर्टिफ़िकेट और कुंजी के इस्तेमाल के बारे में जानकारी

अगर आपके पास Cloud खाते के लिए पैसे चुकाकर इस्तेमाल किया जाने वाला Edge है और आपके पास TLS सर्टिफ़िकेट और कुंजी नहीं है, तो आपके पास एक वर्चुअल होस्ट बनाने का विकल्प होता है. यह होस्ट, Apigee के मुफ़्त में आज़माने की अवधि वाले सर्टिफ़िकेट और कुंजी का इस्तेमाल करता है. इसका मतलब है कि कीस्टोर बनाए बिना ही वर्चुअल होस्ट बनाया जा सकता है.

Apigee के मुफ़्त में आज़माने की सुविधा और कुंजी का इस्तेमाल करके वर्चुअल होस्ट के बारे में बताने वाला एक्सएमएल ऑब्जेक्ट, <KeyStore> और <KeyAlias> एलिमेंट को हटा देता है और उन्हें <UseBuiltInFreeTrialCert> एलिमेंट से बदल देता है, जैसा कि यहां दिखाया गया है:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>myapi.apigee.net</HostAlias>
    </HostAliases>
    <Port>443</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
    </SSLInfo>
    <UseBuiltInFreeTrialCert>true</UseBuiltInFreeTrialCert>
</VirtualHost>

अगर दो-तरफ़ा TLS किया जा रहा है, तो भी आपको <ClientAuthEnabled> एलिमेंट को true पर सेट करना होगा. साथ ही, <TrustStore> एलिमेंट के साथ रेफ़रंस का इस्तेमाल करके ट्रस्टस्टोर बताना होगा.

ज़्यादा जानकारी के लिए, क्लाउड के लिए वर्चुअल होस्ट कॉन्फ़िगर करना देखें.

TLS को कॉन्फ़िगर करने के बारे में जानकारी

दो मुख्य बातों से यह तय होता है कि TLS कॉन्फ़िगरेशन कैसे किया जाएगा:

• क्या आप Edge क्लाउड या Private Cloud के ग्राहक हैं?
• ऐसे सर्टिफ़िकेट को कैसे अपडेट किया जाएगा जिसकी समयसीमा खत्म हो चुकी है या होने वाली है?

क्लाउड और Private Cloud कॉन्फ़िगरेशन के विकल्प

इस टेबल में, Cloud और Private Cloud के ग्राहकों के लिए, कॉन्फ़िगरेशन के अलग-अलग विकल्प दिखाए गए हैं:

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

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

जिन सर्टिफ़िकेट की समयसीमा खत्म हो चुकी है उन्हें मैनेज करना

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

सर्टिफ़िकेट की समयसीमा खत्म होने की तारीख

Edge पर, सर्टिफ़िकेट को इन दो में से किसी एक जगह पर सेव किया जाता है:

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

जब किसी कीस्टोर के सर्टिफ़िकेट की समयसीमा खत्म हो जाती है और कीस्टोर के रेफ़रंस का इस्तेमाल किया जाता है, तब कीस्टोर में नया सर्टिफ़िकेट अपलोड नहीं किया जा सकता. इसके बजाय, आप:

1. कोई नया कीस्टोर बनाएं.
2. नए कीस्टोर में उसी उपनाम का इस्तेमाल करके नए सर्टिफ़िकेट को अपलोड करें, जिसका इस्तेमाल पुराने कीस्टोर में किया था.
3. नए कीस्टोर का इस्तेमाल करने के लिए, अपने वर्चुअल होस्ट या टारगेट सर्वर/टारगेट एंडपॉइंट में रेफ़रंस अपडेट करें.

जब किसी ट्रस्टस्टोर में मौजूद सर्टिफ़िकेट की समयसीमा खत्म हो जाती है और अगर आपने ट्रस्टस्टोर के रेफ़रंस का इस्तेमाल किया है, तो:

1. नया ट्रस्टस्टोर बनाएं.
2. नए सर्टिफ़िकेट को नए ट्रस्टस्टोर पर अपलोड करें. उपनाम का नाम ट्रस्टस्टोर के लिए मायने नहीं रखता है. ध्यान दें: अगर कोई सर्टिफ़िकेट किसी चेन का हिस्सा है, तो आपको या तो सभी सर्टिफ़िकेट वाली एक फ़ाइल बनानी होगी और उस फ़ाइल को एक उपनाम पर अपलोड करना होगा. इसके अलावा, चेन के सभी सर्टिफ़िकेट को हर सर्टिफ़िकेट के लिए, एक अलग उपनाम का इस्तेमाल करके ट्रस्टस्टोर में अलग-अलग अपलोड करना होगा.
3. नए ट्रस्टस्टोर का इस्तेमाल करने के लिए, अपने वर्चुअल होस्ट या टारगेट सर्वर/टारगेट एंडपॉइंट में रेफ़रंस अपडेट करें.

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

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

• References
• सीधे नाम
• फ़्लो वैरिएबल

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