chrome.enterprise.platformKeys

ब्यौरा

इन कुंजियों के लिए, कुंजियां जनरेट करने और सर्टिफ़िकेट इंस्टॉल करने के लिए, chrome.enterprise.platformKeys एपीआई का इस्तेमाल करें. सर्टिफ़िकेट को प्लैटफ़ॉर्म मैनेज करेगा. इनका इस्तेमाल टीएलएस की पुष्टि करने, नेटवर्क ऐक्सेस करने या chrome.platformKeys के ज़रिए अन्य एक्सटेंशन के लिए किया जा सकता है.

अनुमतियां

enterprise.platformKeys

उपलब्धता

सिर्फ़ ChromeOS के लिए नीति की ज़रूरत है

इस्तेमाल

क्लाइंट सर्टिफ़िकेट रजिस्टर करने के लिए, इस एपीआई का इस्तेमाल आम तौर पर इन चरणों में किया जाता है:

  • enterprise.platformKeys.getTokens का इस्तेमाल करके, सभी उपलब्ध टोकन पाएं.

  • id की वैल्यू "user" वाला टोकन ढूंढें. इस टोकन का इस्तेमाल बाद में करें.

  • generateKey टोकन तरीके (SubtleCrypto में तय किया गया) का इस्तेमाल करके, कुंजी का जोड़ा जनरेट करें. इससे हैंडल, कुंजी पर वापस आ जाएगा.

  • exportKey टोकन के तरीके (SubtleCrypto में तय किया गया) का इस्तेमाल करके, सार्वजनिक पासकोड एक्सपोर्ट करें.

  • sign टोकन तरीके (SubtleCrypto में तय किया गया) का इस्तेमाल करके, सर्टिफ़िकेट के अनुरोध के डेटा का हस्ताक्षर बनाएं.

  • सर्टिफ़िकेट पाने का अनुरोध पूरा करें और उसे सर्टिफ़िकेट देने वाली संस्था या निकाय को भेजें.

  • अगर कोई सर्टिफ़िकेट मिलता है, तो उसे enterprise.platformKeys.importCertificate का इस्तेमाल करके इंपोर्ट करें

यहां एक उदाहरण दिया गया है, जिसमें सर्टिफ़िकेट के अनुरोध को बनाने और भेजने के अलावा, एपीआई के साथ होने वाले मुख्य इंटरैक्शन को दिखाया गया है:

function getUserToken(callback) {
  chrome.enterprise.platformKeys.getTokens(function(tokens) {
    for (var i = 0; i < tokens.length; i++) {
      if (tokens[i].id == "user") {
        callback(tokens[i]);
        return;
      }
    }
    callback(undefined);
  });
}

function generateAndSign(userToken) {
  var data = new Uint8Array([0, 5, 1, 2, 3, 4, 5, 6]);
  var algorithm = {
    name: "RSASSA-PKCS1-v1_5",
    // RsaHashedKeyGenParams
    modulusLength: 2048,
    publicExponent:
        new Uint8Array([0x01, 0x00, 0x01]),  // Equivalent to 65537
    hash: {
      name: "SHA-256",
    }
  };
  var cachedKeyPair;
  userToken.subtleCrypto.generateKey(algorithm, false, ["sign"])
    .then(function(keyPair) {
            cachedKeyPair = keyPair;
            return userToken.subtleCrypto.exportKey("spki", keyPair.publicKey);
          },
          console.log.bind(console))
    .then(function(publicKeySpki) {
            // Build the Certification Request using the public key.
            return userToken.subtleCrypto.sign(
                {name : "RSASSA-PKCS1-v1_5"}, cachedKeyPair.privateKey, data);
          },
          console.log.bind(console))
    .then(function(signature) {
              // Complete the Certification Request with |signature|.
              // Send out the request to the CA, calling back
              // onClientCertificateReceived.
          },
          console.log.bind(console));
}

function onClientCertificateReceived(userToken, certificate) {
  chrome.enterprise.platformKeys.importCertificate(userToken.id, certificate);
}

getUserToken(generateAndSign);

टाइप

Algorithm

Chrome 110 या इसके बाद का वर्शन

जनरेट की जाने वाली कुंजी का टाइप.

Enum

"RSA"

"ECDSA"

ChallengeKeyOptions

Chrome 110 या इसके बाद का वर्शन

प्रॉपर्टी

  • चैलेंज

    ArrayBuffer

    पुष्टि किए गए ऐक्सेस वाले Web API से जनरेट की गई चुनौती.

  • registerKey

    RegisterKeyOptions ज़रूरी नहीं है

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

  • दायरा

    स्कोप

    चुनौती देने के लिए, कौनसी एंटरप्राइज़ कुंजी.

RegisterKeyOptions

Chrome 110 या इसके बाद का वर्शन

प्रॉपर्टी

  • एल्‍गोरि‍दम

    एल्गोरिदम

    रजिस्टर की गई कुंजी को किस एल्गोरिदम का इस्तेमाल करना चाहिए.

Scope

Chrome 110 या इसके बाद का वर्शन

एंटरप्राइज़ उपयोगकर्ता की कुंजी या एंटरप्राइज़ मशीन की कुंजी का इस्तेमाल करना है या नहीं.

Enum

"USER"

"MACHINE"

Token

प्रॉपर्टी

  • आईडी

    स्ट्रिंग

    यह Token की यूनीक तरीके से पहचान करता है.

    स्टैटिक आईडी "user" और "system" होते हैं. ये क्रमशः प्लैटफ़ॉर्म के उपयोगकर्ता के हिसाब से और सिस्टम-वाइड हार्डवेयर टोकन को दिखाते हैं. enterprise.platformKeys.getTokens, अन्य आइडेंटिफ़ायर वाले कोई अन्य टोकन भी दिखा सकता है.

  • softwareBackedSubtleCrypto

    SubtleCrypto

    Chrome 97 या इसके बाद के वर्शन

    यह WebCrypto के SubtleCrypto इंटरफ़ेस को लागू करता है. क्रिप्टोग्राफ़िक ऑपरेशन, सॉफ़्टवेयर की मदद से किए जाते हैं. इनमें कुंजी जनरेट करना भी शामिल है. कुंजियों की सुरक्षा और इस तरह से न निकाली जा सकने वाली प्रॉपर्टी को सॉफ़्टवेयर में लागू किया जाता है. इसलिए, ये कुंजियां हार्डवेयर पर सेव की जाने वाली कुंजियों की तुलना में कम सुरक्षित होती हैं.

    सिर्फ़ ऐसी कुंजियां जनरेट की जा सकती हैं जिन्हें एक्सट्रैक्ट नहीं किया जा सकता. RSASSA-PKCS1-V1_5 और RSA-OAEP (Chrome के 135 और इसके बाद के वर्शन पर) के साथ modulusLength तक की कुंजियों का इस्तेमाल किया जा सकता है. हर RSASSA-PKCS1-V1_5 कुंजी का इस्तेमाल, डेटा को ज़्यादा से ज़्यादा एक बार साइन करने के लिए किया जा सकता है. हालांकि, अगर एक्सटेंशन को KeyPermissions नीति के तहत अनुमति वाली सूची में शामिल किया गया है, तो कुंजी का इस्तेमाल अनिश्चित काल तक किया जा सकता है. RSA-OAEP कुंजियां, Chrome के वर्शन 135 से काम करती हैं. इनका इस्तेमाल उन एक्सटेंशन के लिए किया जा सकता है जिन्हें इस नीति के तहत अनुमति दी गई है. इससे अन्य कुंजियों को अनरैप किया जा सकता है.

    किसी खास Token पर जनरेट की गई कुंजियों का इस्तेमाल, किसी अन्य टोकन के साथ नहीं किया जा सकता. साथ ही, इनका इस्तेमाल window.crypto.subtle के साथ भी नहीं किया जा सकता. इसी तरह, window.crypto.subtle का इस्तेमाल करके बनाए गए Key ऑब्जेक्ट को इस इंटरफ़ेस के साथ इस्तेमाल नहीं किया जा सकता.

  • subtleCrypto

    SubtleCrypto

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

    सिर्फ़ ऐसी कुंजियां जनरेट की जा सकती हैं जिन्हें एक्सट्रैक्ट नहीं किया जा सकता. RSASSA-PKCS1-V1_5 और RSA-OAEP (Chrome के 135 और इसके बाद के वर्शन पर) के साथ modulusLength 2048 तक और ECDSA के साथ namedCurve P-256, इस्तेमाल किए जा सकने वाले कुंजी टाइप हैं. हर RSASSA-PKCS1-V1_5 और ECDSA कुंजी का इस्तेमाल, डेटा को ज़्यादा से ज़्यादा एक बार साइन करने के लिए किया जा सकता है. हालांकि, अगर एक्सटेंशन को KeyPermissions नीति के तहत अनुमति वाली सूची में शामिल किया गया है, तो कुंजी का इस्तेमाल अनिश्चित काल तक किया जा सकता है. RSA-OAEP कुंजियां, Chrome के वर्शन 135 से काम करती हैं. इनका इस्तेमाल उन एक्सटेंशन के लिए किया जा सकता है जिन्हें इस नीति के तहत अनुमति दी गई है. इससे अन्य कुंजियों को अनरैप किया जा सकता है.

    किसी खास Token पर जनरेट की गई कुंजियों का इस्तेमाल, किसी अन्य टोकन के साथ नहीं किया जा सकता. साथ ही, इनका इस्तेमाल window.crypto.subtle के साथ भी नहीं किया जा सकता. इसी तरह, window.crypto.subtle का इस्तेमाल करके बनाए गए Key ऑब्जेक्ट को इस इंटरफ़ेस के साथ इस्तेमाल नहीं किया जा सकता.

तरीके

challengeKey()

Promise Chrome 110 या इसके बाद के वर्शन 
chrome.enterprise.platformKeys.challengeKey(
  options: ChallengeKeyOptions,
  callback?: function,
): Promise<ArrayBuffer>

यह challengeMachineKey और challengeUserKey की तरह ही होता है. हालांकि, इसमें रजिस्टर की गई कुंजी का एल्गोरिदम तय किया जा सकता है. यह हार्डवेयर की मदद से सुरक्षित की गई एंटरप्राइज़ मशीन की कुंजी को चुनौती देता है और रिमोट अटेंशन प्रोटोकॉल के तहत जवाब देता है. यह सिर्फ़ ChromeOS पर काम करता है. साथ ही, इसका इस्तेमाल सिर्फ़ Verified Access Web API के साथ किया जा सकता है. यह एपीआई, चैलेंज जारी करता है और जवाबों की पुष्टि करता है.

पुष्टि किए गए ऐक्सेस वाले Web API से पुष्टि हो जाने का मतलब है कि मौजूदा डिवाइस, ChromeOS का असली डिवाइस है. साथ ही, मौजूदा डिवाइस को पुष्टि के दौरान बताए गए डोमेन से मैनेज किया जाता है. इसके अलावा, मौजूदा डिवाइस में साइन इन किए गए उपयोगकर्ता को पुष्टि के दौरान बताए गए डोमेन से मैनेज किया जाता है. साथ ही, मौजूदा डिवाइस की स्थिति, एंटरप्राइज़ डिवाइस की नीति के मुताबिक है. उदाहरण के लिए, किसी नीति में यह बताया जा सकता है कि डिवाइस डेवलपर मोड में नहीं होना चाहिए. पुष्टि करने की प्रोसेस के दौरान जनरेट की गई डिवाइस की पहचान, मौजूदा डिवाइस के हार्डवेयर से जुड़ी होती है. अगर "user" स्कोप तय किया गया है, तो आइडेंटिटी को साइन इन किए हुए मौजूदा उपयोगकर्ता से भी जोड़ा जाता है.

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

पैरामीटर

  • विकल्प

    ChallengeKeyOptions

    यह एक ऑब्जेक्ट है, जिसमें ChallengeKeyOptions में तय किए गए फ़ील्ड शामिल होते हैं.

  • कॉलबैक

    फ़ंक्शन ज़रूरी नहीं

    callback पैरामीटर ऐसा दिखता है: 

    (response: ArrayBuffer) => void

    • जवाब

      ArrayBuffer

      सवाल का जवाब देकर अनलॉक करें.

रिटर्न

  • Promise<ArrayBuffer>

    Chrome 131 और इसके बाद के वर्शन

    यह एक प्रॉमिस दिखाता है, जो चैलेंज के जवाब के साथ रिज़ॉल्व होता है.

    प्रॉमिस सिर्फ़ मेनिफ़ेस्ट V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.

challengeMachineKey()

Promise Chrome 50+ Chrome 110 से बंद कर दिया गया है
chrome.enterprise.platformKeys.challengeMachineKey(
  challenge: ArrayBuffer,
  registerKey?: boolean,
  callback?: function,
): Promise<ArrayBuffer>

इसके बजाय, challengeKey का इस्तेमाल करें.

यह हार्डवेयर की मदद से सुरक्षित की गई एंटरप्राइज़ मशीन की कुंजी को चुनौती देता है और रिमोट अटेंशन प्रोटोकॉल के तहत जवाब देता है. यह सिर्फ़ ChromeOS पर काम करता है. साथ ही, इसका इस्तेमाल सिर्फ़ Verified Access Web API के साथ किया जा सकता है. यह एपीआई, चैलेंज जारी करता है और जवाबों की पुष्टि करता है. Verified Access Web API से पुष्टि हो जाने का मतलब है कि: * मौजूदा डिवाइस, ChromeOS वाला असली डिवाइस है. * मौजूदा डिवाइस को पुष्टि के दौरान बताए गए डोमेन से मैनेज किया जाता है. * फ़िलहाल, साइन इन किए हुए उपयोगकर्ता को पुष्टि के दौरान बताए गए डोमेन से मैनेज किया जाता है. * डिवाइस की मौजूदा स्थिति, एंटरप्राइज़ डिवाइस की नीति के मुताबिक हो. उदाहरण के लिए, किसी नीति में यह बताया जा सकता है कि डिवाइस डेवलपर मोड में नहीं होना चाहिए. * पुष्टि करने की प्रोसेस के दौरान जनरेट की गई डिवाइस की पहचान, मौजूदा डिवाइस के हार्डवेयर से जुड़ी होती है. इस फ़ंक्शन के इस्तेमाल पर कई पाबंदियां हैं. अगर मौजूदा डिवाइस या उपयोगकर्ता को मैनेज नहीं किया जा रहा है या एंटरप्राइज़ डिवाइस की नीति के तहत, इस ऑपरेशन को कॉलर के लिए साफ़ तौर पर चालू नहीं किया गया है, तो यह फ़ंक्शन काम नहीं करेगा. एंटरप्राइज़ मशीन की, "system" टोकन में मौजूद नहीं होती है. साथ ही, इसे किसी अन्य एपीआई से ऐक्सेस नहीं किया जा सकता.

पैरामीटर

  • चैलेंज

    ArrayBuffer

    पुष्टि किए गए ऐक्सेस वाले Web API से जनरेट की गई चुनौती.

  • registerKey

    बूलियन ज़रूरी नहीं है

    Chrome 59 या इसके बाद का वर्शन

    अगर यह सेट है, तो मौजूदा Enterprise Machine Key, "system" टोकन के साथ रजिस्टर हो जाती है और Enterprise Machine Key की भूमिका छोड़ देती है. इसके बाद, कुंजी को किसी सर्टिफ़िकेट से जोड़ा जा सकता है और इसका इस्तेमाल किसी अन्य साइनिंग कुंजी की तरह किया जा सकता है. यह कुंजी 2048-बिट आरएसए है. इसके बाद, इस फ़ंक्शन को कॉल करने पर एक नई Enterprise Machine Key जनरेट होगी.

  • कॉलबैक

    फ़ंक्शन ज़रूरी नहीं

    callback पैरामीटर ऐसा दिखता है: 

    (response: ArrayBuffer) => void

    • जवाब

      ArrayBuffer

      सवाल का जवाब देकर अनलॉक करें.

रिटर्न

  • Promise<ArrayBuffer>

    Chrome 131 और इसके बाद के वर्शन

    यह एक प्रॉमिस दिखाता है, जो चैलेंज के जवाब के साथ रिज़ॉल्व होता है.

    प्रॉमिस सिर्फ़ मेनिफ़ेस्ट V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.

challengeUserKey()

Promise Chrome 50+ Chrome 110 से बंद कर दिया गया है
chrome.enterprise.platformKeys.challengeUserKey(
  challenge: ArrayBuffer,
  registerKey: boolean,
  callback?: function,
): Promise<ArrayBuffer>

इसके बजाय, challengeKey का इस्तेमाल करें.

यह हार्डवेयर की मदद से सुरक्षित की गई Enterprise User Key को चुनौती देता है और रिमोट अटेस्टेशन प्रोटोकॉल के तहत जवाब देता है. यह सिर्फ़ ChromeOS पर काम करता है. साथ ही, इसका इस्तेमाल सिर्फ़ Verified Access Web API के साथ किया जा सकता है. यह एपीआई, चैलेंज जारी करता है और जवाबों की पुष्टि करता है. Verified Access Web API से पुष्टि हो जाने का मतलब है कि: * मौजूदा डिवाइस, ChromeOS वाला असली डिवाइस है. * मौजूदा डिवाइस को पुष्टि के दौरान बताए गए डोमेन से मैनेज किया जाता है. * फ़िलहाल, साइन इन किए हुए उपयोगकर्ता को पुष्टि के दौरान बताए गए डोमेन से मैनेज किया जाता है. * डिवाइस की मौजूदा स्थिति, एंटरप्राइज़ उपयोगकर्ता की नीति के मुताबिक हो. उदाहरण के लिए, किसी नीति में यह बताया जा सकता है कि डिवाइस डेवलपर मोड में नहीं होना चाहिए. * पुष्टि करने की प्रोसेस से जनरेट की गई सार्वजनिक कुंजी, मौजूदा डिवाइस के हार्डवेयर और मौजूदा समय में साइन इन किए गए उपयोगकर्ता से जुड़ी होती है. इस फ़ंक्शन पर कई पाबंदियां हैं. अगर मौजूदा डिवाइस या उपयोगकर्ता को मैनेज नहीं किया जा रहा है या एंटरप्राइज़ उपयोगकर्ता की नीति के तहत, इस ऑपरेशन को कॉलर के लिए साफ़ तौर पर चालू नहीं किया गया है, तो यह फ़ंक्शन काम नहीं करेगा. Enterprise User Key, "user" टोकन में मौजूद नहीं होती है. साथ ही, इसे किसी अन्य एपीआई से ऐक्सेस नहीं किया जा सकता.

पैरामीटर

  • चैलेंज

    ArrayBuffer

    पुष्टि किए गए ऐक्सेस वाले Web API से जनरेट की गई चुनौती.

  • registerKey

    बूलियन

    अगर यह सेट है, तो मौजूदा एंटरप्राइज़ उपयोगकर्ता की कुंजी, "user" टोकन के साथ रजिस्टर की जाती है. साथ ही, एंटरप्राइज़ उपयोगकर्ता की कुंजी की भूमिका को छोड़ दिया जाता है. इसके बाद, कुंजी को किसी सर्टिफ़िकेट से जोड़ा जा सकता है और इसका इस्तेमाल किसी अन्य साइनिंग कुंजी की तरह किया जा सकता है. यह कुंजी 2048-बिट आरएसए है. इसके बाद, इस फ़ंक्शन को कॉल करने पर नई Enterprise User Key जनरेट होगी.

  • कॉलबैक

    फ़ंक्शन ज़रूरी नहीं

    callback पैरामीटर ऐसा दिखता है: 

    (response: ArrayBuffer) => void

    • जवाब

      ArrayBuffer

      सवाल का जवाब देकर अनलॉक करें.

रिटर्न

  • Promise<ArrayBuffer>

    Chrome 131 और इसके बाद के वर्शन

    यह एक प्रॉमिस दिखाता है, जो चैलेंज के जवाब के साथ रिज़ॉल्व होता है.

    प्रॉमिस सिर्फ़ मेनिफ़ेस्ट V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.

getCertificates()

Promise 
chrome.enterprise.platformKeys.getCertificates(
  tokenId: string,
  callback?: function,
): Promise<ArrayBuffer[]>

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

पैरामीटर

  • tokenId

    स्ट्रिंग

    getTokens से मिले टोकन का आईडी.

  • कॉलबैक

    फ़ंक्शन ज़रूरी नहीं

    callback पैरामीटर ऐसा दिखता है: 

    (certificates: ArrayBuffer[]) => void

    • सर्टिफ़िकेट

      ArrayBuffer[]

      सर्टिफ़िकेट की सूची. इसमें हर सर्टिफ़िकेट, X.509 सर्टिफ़िकेट के DER एन्कोडिंग में होता है.

रिटर्न

  • Promise<ArrayBuffer[]>

    Chrome 131 और इसके बाद के वर्शन

    यह एक प्रॉमिस दिखाता है. यह प्रॉमिस, उपलब्ध सर्टिफ़िकेट की सूची के साथ रिज़ॉल्व होता है.

    प्रॉमिस सिर्फ़ मेनिफ़ेस्ट V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.

getTokens()

Promise 
chrome.enterprise.platformKeys.getTokens(
  callback?: function,
): Promise<Token[]>

उपलब्ध टोकन दिखाता है. सामान्य उपयोगकर्ता के सेशन में, सूची में हमेशा उपयोगकर्ता का टोकन id "user" के साथ शामिल होगा. अगर सिस्टम-वाइड टीपीएम टोकन उपलब्ध है, तो दिखाई गई सूची में सिस्टम-वाइड टोकन भी शामिल होगा. इसके साथ id "system" होगा. सिस्टम-वाइड टोकन, इस डिवाइस पर मौजूद सभी सेशन के लिए एक जैसा होगा. डिवाइस का मतलब, जैसे कि Chromebook.

पैरामीटर

  • कॉलबैक

    फ़ंक्शन ज़रूरी नहीं

    callback पैरामीटर ऐसा दिखता है: 

    (tokens: Token[]) => void

    • टोकन

      टोकन[]

      उपलब्ध टोकन की सूची.

रिटर्न

  • Promise<Token[]>

    Chrome 131 और इसके बाद के वर्शन

    इस फ़ंक्शन को getTokens ने उपलब्ध टोकन की सूची के साथ शुरू किया है.

    प्रॉमिस सिर्फ़ मेनिफ़ेस्ट V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.

importCertificate()

Promise 
chrome.enterprise.platformKeys.importCertificate(
  tokenId: string,
  certificate: ArrayBuffer,
  callback?: function,
): Promise<void>

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

पैरामीटर

  • tokenId

    स्ट्रिंग

    getTokens से मिले टोकन का आईडी.

  • सर्टिफ़िकेट

    ArrayBuffer

    X.509 सर्टिफ़िकेट का DER एन्कोडिंग.

  • कॉलबैक

    फ़ंक्शन ज़रूरी नहीं

    callback पैरामीटर ऐसा दिखता है: 

    () => void

रिटर्न

  • Promise<void>

    Chrome 131 और इसके बाद के वर्शन

    यह एक प्रॉमिस दिखाता है. यह प्रॉमिस तब रिज़ॉल्व होता है, जब यह कार्रवाई पूरी हो जाती है.

    प्रॉमिस सिर्फ़ मेनिफ़ेस्ट V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.

removeCertificate()

Promise 
chrome.enterprise.platformKeys.removeCertificate(
  tokenId: string,
  certificate: ArrayBuffer,
  callback?: function,
): Promise<void>

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

पैरामीटर

  • tokenId

    स्ट्रिंग

    getTokens से मिले टोकन का आईडी.

  • सर्टिफ़िकेट

    ArrayBuffer

    X.509 सर्टिफ़िकेट का DER एन्कोडिंग.

  • कॉलबैक

    फ़ंक्शन ज़रूरी नहीं

    callback पैरामीटर ऐसा दिखता है: 

    () => void

रिटर्न

  • Promise<void>

    Chrome 131 और इसके बाद के वर्शन

    यह एक प्रॉमिस दिखाता है. यह प्रॉमिस तब रिज़ॉल्व होता है, जब यह कार्रवाई पूरी हो जाती है.

    प्रॉमिस सिर्फ़ मेनिफ़ेस्ट V3 और इसके बाद के वर्शन के लिए काम करते हैं. अन्य प्लैटफ़ॉर्म को कॉलबैक का इस्तेमाल करना होगा.