Import Key

What this screen is for

Import Key brings key material that already exists somewhere else — a partner's public key, a keystore from a system you are migrating off — under this tenant's control. It has two tabs: Import from JSON and Import from Keystore.

They are two different operations, not two file formats for the same one. Import from JSON accepts public key material only; a private key is never accepted there. Import from Keystore is the only way a private key enters this tenant, and it is the consequential one: the key's private half crosses into the platform, and once it is in, it cannot be taken back out.

An imported key is an ordinary key from then on. It appears in the key inventory with its origin recorded as imported, and every lifecycle decision — rotate, suspend, revoke, archive, destroy — is taken there, not here.

What must exist first

The screen is offered when you hold the permission to import a public key or the permission to import a keystore. Each tab follows its own permission: a tab whose permission you do not hold stays visible but disabled, with the tooltip Your role does not include this import, and the screen opens on a tab you can use.

The permission to import a public key, for the Import from JSON tab.
The permission to import a keystore, for the Import from Keystore tab. The read-only analysis in that tab requires the same permission as the import itself.
A key protection backend bound for your tenant, for the keystore tab only: every private key is sealed under a key-encryption key before it is stored, so with no backend bound the import is refused. The JSON tab stores no private material and needs no backend.
A tenant whose lifecycle state still permits key lifecycle operations. Both imports check this; the read-only keystore analysis does not.
A deployment licence in effect. Both imports are refused without one, and so is the keystore analysis.

Neither import is available to a platform operator working inside a support-access impersonation session. That refusal is raised before anything is read, so nothing changes.

Decisions you make here

Import from JSON — a public key

Upload a .json file describing one key. The console checks only that the file parses and carries kid, kty and alg; every other decision belongs to the server.

kid is the identifier the key will hold for life. An existing key with the same identifier but different public material is a conflict, not an overwrite.
Key operations: only public ones are accepted — encrypt, verify, wrapKey, deriveKey — and only those the algorithm supports. Asking for decrypt, sign or unwrapKey is refused, because there is no private key here to perform them.
Algorithm: it must be one your tenant's algorithm policy admits. A simple key carries publicKey as Base64; a composite key names a pairing this deployment's catalogue carries and supplies a public key per component.
The key is created active, with its origin recorded as imported.

Import from Keystore — private keys and certificates

Upload a PKCS#12 (.p12, .pfx) or JKS (.jks) file. The format is detected from the file's own bytes, not from its extension. The default size limit is 20 MB and an operator can change it; the password is limited to 4 KB.

Key ID Prefix is required and becomes the base identifier. It accepts letters, digits and the characters . _ -, up to 255 characters, and may not be dots alone (., ..).
A keystore holding one private key stores it under that prefix unchanged. With several, each key is stored as the prefix followed by its alias. A trusted certificate carrying no private key is stored as the prefix, then -trust-, then its alias.
Keystore Password is required by this screen before it will analyse the file.
Analyze Keystore is a read-only preview: it opens the keystore, reports one row per alias, and imports, wraps, audits and persists nothing.

A PKCS#7 file converts only when every signer and every recipient in it is a key of this tenant imported here with its private half. A certificate imported alone only verifies: it never signs and is never encrypted to. So a third party known only by its certificate — a co-signer, an external addressee — makes the file not convertible, because the conversion needs the private key of every signer and of every recipient, so a file addressed only to others is not convertible either. Importing the certificate does not change that.

Find out before converting: the migration analysis lists every actor of the file with its purpose in recommendations.requiredKeys, and a conversion attempted anyway is refused naming every missing actor in unresolvedActors. When the file is not convertible, keep the original PKCS#7: it remains the evidence of what the third party signed and to whom the content was addressed.

Choosing a purpose for each alias

Step 2 asks what each key will be used for. A purpose is fixed for the life of the key, which is why the wizard makes you take this decision before it commits anything.

The platform derives a purpose from each certificate's X.509 KeyUsage and pre-selects it. An alias marked Choice required has none that can be derived, and the import will not start until you set it.
Dual (two identities) does not create a dual-purpose key. It projects one keypair onto two single-purpose keys, <kid>-enc and <kid>-sig, minted together.
Certificates are validated in the mode the deployment is configured with, which this screen never chooses. Under the strict mode — the default, and the one any failure to read that setting falls back to — an alias with an expired or invalid certificate fails while the rest continue.
The import is one commit. If the key protection backend refuses part-way through, the whole bundle is rolled back rather than leaving some keys stored and others not.

What an import commits you to

An import is a custody event. What follows is what the platform does with the material, and what it will not do afterwards.

The keystore and its password travel as separate parts of one upload. The password is handled as bytes throughout: it is not written to any log, error body or audit record, and it is not stored.
Each private key is sealed with AES-256-GCM under your tenant's key-encryption key before anything is written, and the plaintext bytes are wiped from memory immediately afterwards. No private key is written in the clear at any point.
The private half never comes back out. Export returns the public key and metadata only, for every key, whatever its origin. Keep your own copy of the keystore until you are certain the import is what you intended.
An imported key expires at the end of the maximum cryptoperiod of its kind, counted from the import (24 months for an encryption key, 36 months for a signing key, as NIST SP 800-57 recommends), or on its certificate's expiry date when that comes first. A trusted certificate keeps its own expiry date. You can change it afterwards from the key inventory.
Importing does not authorize anyone to use the key. Use is authorized separately, and the key is unusable until it is.

What the platform refuses

Each refusal names its own cause, and the pages under Where to read more explain them one at a time.

A wrong password, a corrupt file, or a format that is neither PKCS#12 nor JKS.
A keystore over the size limit, or a password part over 4 KB.
An alias whose purpose cannot be derived and has not been declared; and Dual declared on an alias that carries a certificate but no private key.
An identifier already held by a live key. In a keystore import that alias is reported as skipped and the rest proceed; in a JSON import with different public material it is a conflict.

How it relates to other screens

The imported key lands in the key inventory, which is where its whole life is managed and where its conformance to your tenant's algorithm policy is shown:

Key Inventory

Nobody can use an imported key until an authorization names it. On a STANDARD tenant that is a capability grant:

Capability Grants

Every import, and every refused import, is recorded against your account. The read-only analysis records nothing:

Audit Log