chrome.enterprise.platformKeys

ब्यौरा

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

अनुमतियां

enterprise.platformKeys

उपलब्धता

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

कॉन्सेप्ट और इस्तेमाल

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

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

  • वह टोकन ढूंढें जिसका id, "user" के बराबर हो. इसके बाद, इस टोकन का इस्तेमाल करें.

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

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

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

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

  • अगर आपको सर्टिफ़िकेट मिलता है, तो [enterprise.platformKeys.importCertificate()`[3] का इस्तेमाल करके उसे इंपोर्ट करें

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

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

    Verified Access 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 शामिल हैं. साथ ही, modulusLength की वैल्यू 2048 तक हो सकती है. RSASSA-PKCS1-V1_5 की हर कुंजी का इस्तेमाल, डेटा पर हस्ताक्षर करने के लिए ज़्यादा से ज़्यादा एक बार किया जा सकता है. हालांकि, अगर एक्सटेंशन को KeyPermissions नीति की मदद से अनुमति वाली सूची में शामिल किया गया है, तो कुंजी का इस्तेमाल अनलिमिटेड तौर पर किया जा सकता है. RSA-OAEP पासकोड का इस्तेमाल, अन्य पासकोड को अनलॉक करने के लिए, उसी नीति में शामिल एक्सटेंशन कर सकते हैं.

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

  • subtleCrypto

    SubtleCrypto

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

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

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

तरीके

challengeKey()

Promise Chrome 110 और उसके बाद के वर्शन के लिए 
chrome.enterprise.platformKeys.challengeKey(
  options: ChallengeKeyOptions,
  callback?: function,
)

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

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

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

पैरामीटर

  • विकल्प

    ChallengeKeyOptions

    ChallengeKeyOptions में तय किए गए फ़ील्ड वाला ऑब्जेक्ट.

  • कॉलबैक

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

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

    (response: ArrayBuffer) => void

    • जवाब

      ArrayBuffer

      चैलेंज का जवाब.

रिटर्न

  • Promise<ArrayBuffer>

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

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

challengeMachineKey()

Promise Chrome 50 और उसके बाद के वर्शन के लिए Chrome 110 से काम नहीं करता
chrome.enterprise.platformKeys.challengeMachineKey(
  challenge: ArrayBuffer,
  registerKey?: boolean,
  callback?: function,
)

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

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

पैरामीटर

  • चैलेंज

    ArrayBuffer

    Verified Access Web API से मिलने वाला चैलेंज.

  • registerKey

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

    Chrome 59 और उसके बाद के वर्शन

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

  • कॉलबैक

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

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

    (response: ArrayBuffer) => void

    • जवाब

      ArrayBuffer

      चैलेंज का जवाब.

रिटर्न

  • Promise<ArrayBuffer>

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

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

challengeUserKey()

Promise Chrome 50 और उसके बाद के वर्शन के लिए Chrome 110 से काम नहीं करता
chrome.enterprise.platformKeys.challengeUserKey(
  challenge: ArrayBuffer,
  registerKey: boolean,
  callback?: function,
)

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

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

पैरामीटर

  • चैलेंज

    ArrayBuffer

    Verified Access Web API से मिलने वाला चैलेंज.

  • registerKey

    बूलियन

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

  • कॉलबैक

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

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

    (response: ArrayBuffer) => void

    • जवाब

      ArrayBuffer

      चैलेंज का जवाब.

रिटर्न

  • Promise<ArrayBuffer>

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

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

getCertificates()

वादा करना 
chrome.enterprise.platformKeys.getCertificates(
  tokenId: string,
  callback?: function,
)

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

पैरामीटर

  • tokenId

    स्ट्रिंग

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

  • कॉलबैक

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

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

    (certificates: ArrayBuffer[]) => void

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

      ArrayBuffer[]

      सर्टिफ़िकेट की सूची, जिसमें हर सर्टिफ़िकेट को X.509 सर्टिफ़िकेट के DER कोड में बदला गया हो.

रिटर्न

  • Promise<ArrayBuffer[]>

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

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

getTokens()

वादा करना 
chrome.enterprise.platformKeys.getTokens(
  callback?: function,
)

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

पैरामीटर

  • कॉलबैक

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

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

    (tokens: Token[]) => void

    • टोकन

      टोकन[]

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

रिटर्न

  • Promise<Token[]>

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

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

importCertificate()

वादा करना 
chrome.enterprise.platformKeys.importCertificate(
  tokenId: string,
  certificate: ArrayBuffer,
  callback?: function,
)

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

पैरामीटर

  • tokenId

    स्ट्रिंग

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

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

    ArrayBuffer

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

  • कॉलबैक

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

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

    () => void

रिटर्न

  • Promise<void>

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

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

removeCertificate()

वादा करना 
chrome.enterprise.platformKeys.removeCertificate(
  tokenId: string,
  certificate: ArrayBuffer,
  callback?: function,
)

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

पैरामीटर

  • tokenId

    स्ट्रिंग

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

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

    ArrayBuffer

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

  • कॉलबैक

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

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

    () => void

रिटर्न

  • Promise<void>

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

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