Key Export in Standard Formats
Reversibility by design: a key you create as exportable can leave the Cockpit in a format any other KMS, HSM or crypto library imports, under permission, quorum and audit controls.
Keys are not exportable by default. When you need an exit path - migrating to another KMS, keeping an escrow copy, or importing a copy into a cloud KMS (BYOK) - create the key with the Exportable key option. Such a key can then be taken out of the platform in one of four standard channels.
Export formats
| Format | Key types | What you get |
|---|---|---|
| PKCS#8 | RSA, EC, ML-DSA, ML-KEM, SLH-DSA (private keys) | Encrypted private key in PEM (EncryptedPrivateKeyInfo, RFC 5958). Password-based encryption with PBES2, PBKDF2-HMAC-SHA-256 (600,000 iterations) and AES-256-CBC. Readable by OpenSSL, Java and most KMS. |
| PKCS#12 | RSA, EC, ML-DSA, ML-KEM, SLH-DSA (private keys) | Password-protected .p12 file (RFC 7292) with AES-256 encrypted bags and an HMAC-SHA-256 integrity MAC. When the key has a certificate, the most recent unrevoked certificate and its chain are included; otherwise the file holds the key alone. |
| Wrapped (RSA-AES) | All key types, including AES and HMAC | The key encrypted under your RSA public key: RSA-OAEP-SHA-256(one-time AES-256 key) followed by AES-KWP (RFC 5649) of the key. Symmetric keys are wrapped raw, private keys as PKCS#8 DER. |
| KMIP | All key types | The key is published on one of your KMIP endpoints and a KMIP client retrieves it with Get: private keys as PKCS#8, symmetric keys as Raw, optionally wrapped with a KMIP Key Wrapping Specification. |
Symmetric keys (AES, HMAC) leave only wrapped or over KMIP: PKCS#8 and PKCS#12 are containers for private keys.
BYOK import into another KMS or HSM
The wrapped layout is the standard RSA-AES key-wrap import format, so the file can be imported as is:
| Target | Import mechanism |
|---|---|
| Any PKCS#11 HSM | CKM_RSA_AES_KEY_WRAP |
| AWS KMS (import key material) | RSA_AES_KEY_WRAP_SHA_256 |
| Google Cloud KMS (import job) | RSA_OAEP_*_SHA256_AES_256 |
Paste the wrapping public key that the target KMS gives you for the import (RSA, 2048 bits or more, as SPKI or PKCS#1 PEM), download the wrapped file, and import it on the target side.
ML-DSA, ML-KEM and SLH-DSA private keys use the IETF LAMPS encodings, as OpenSSL 3.5 writes them: ML-DSA and ML-KEM in the expandedKey form, SLH-DSA as the raw private key. OpenSSL 3.5 reads every exported file.
Which vaults can export
Whether a key can leave depends on where its material lives. The Cockpit only offers the formats the key's vault allows.
| Vault | Formats | How |
|---|---|---|
| Software Vault | PKCS#8, PKCS#12, wrapped, KMIP | The Cockpit holds the material and builds the file. |
| Securosys Primus HSM | Wrapped only | The wrapping is done inside the HSM: your RSA public key is imported, a one-time AES-256 key is generated, the key is wrapped under it and the one-time key under your RSA key; both temporary objects are then deleted. The key never exists in the clear outside the HSM, not even towards the Cockpit, which is why PKCS#8, PKCS#12 and KMIP are not offered. RSA, EC, AES and HMAC keys; post-quantum keys cannot be exported from the HSM. |
| Cloud KMS (AWS KMS, Google Cloud KMS, Azure Key Vault, Alibaba KMS) | None | These providers do not let key material leave. Azure Secure Key Release only releases a key to an attested confidential environment, not to an arbitrary target. |
| DuoKey MPC KMS | None | An MPC key never exists in one piece, so there is nothing to export. |
| HSM Agent (on-premises PKCS#11) | None | The agent creates every key non-extractable by design. |
If a key must be usable in a cloud KMS and still stay reversible, create it exportable in the Software Vault or the Securosys HSM, and import a wrapped copy into the cloud KMS (BYOK).
Creating an exportable key in a vault that cannot export it is refused, rather than storing a promise the vault cannot honour.
Conditions
An export runs only when all of the following hold:
| Condition | Details |
|---|---|
| Permission | The user holds Keys > Export Key Material (Operations.Keys.Export). It is granted to no role by default except Admin. Without it the Export key button is hidden and the API refuses the call. |
| Key created exportable | The Exportable key switch was on when the key was created (off by default). The flag is one-way, like PKCS#11 CKA_EXTRACTABLE: it can be withdrawn later but never granted, so a key created non-exportable can never be opened up, even by a user allowed to edit keys. On the Securosys HSM the flag sets the HSM's own extractable attribute at generation. |
| Vault supports it | The key lives in a vault that can export it, in a format that vault allows (see the table above). |
| Valid protection | A password of at least 12 characters (PKCS#8, PKCS#12), or an RSA wrapping key of 2048 bits or more (wrapped). |
| Rate limit | At most 10 exports per key per hour. |
| Quorum approval | When a quorum policy bound to the key or its vault gates export (export is part of the default gated set, with delete and rotate), the first request opens an M-of-N approval request instead of exporting. Repeat the export once the request is approved. |
KMIP cannot carry an approval. A key whose export is under quorum therefore cannot be published on a KMIP endpoint, and a KMIP Get of an already published key is refused as soon as such a policy applies.
Export a key from the Cockpit
Open the key
Go to Keys and open the key. The Export key button appears only if you hold the export permission, the key is exportable and its vault allows extraction.
Choose the format
Select PKCS#8, PKCS#12, Wrapped (RSA-AES) or KMIP. Formats the key or its vault cannot use are disabled.
Protect the export
Enter the export password twice (PKCS#8, PKCS#12), paste the RSA public key of the target (wrapped), or pick a KMIP endpoint (KMIP).
Download or publish
Click Download (or Publish for KMIP). The file is generated on demand and never stored on the server. If a quorum applies, the Cockpit tells you which approval request was opened.
Export through the API
Passwords and wrapping keys travel in the request body, never in the URL.
# PKCS#8
curl -X POST "$COCKPIT/api/keys/$KEY_ID/export" \
-H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
-d '{"format":"pkcs8","password":"<at least 12 characters>"}' -o key.p8.pem
openssl pkey -in key.p8.pem -noout -text
# PKCS#12
curl -X POST "$COCKPIT/api/keys/$KEY_ID/export" \
-H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
-d '{"format":"pkcs12","password":"<at least 12 characters>"}' -o key.p12
# Wrapped under the import key given by the target KMS
jq -n --rawfile pem wrapping-key.pem '{format:"wrapped", wrapping_public_key_pem:$pem}' \
| curl -X POST "$COCKPIT/api/keys/$KEY_ID/export" \
-H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
-d @- -o key.rsa-aes-wrapped.bin
GET /api/keys/{id} tells you in advance whether a key can be exported and in which formats (is_exportable, export_supported, export_formats). When a quorum applies, the export call answers 202 with a JSON body carrying the request_id of the approval request instead of a file.
Over KMIP
# Publish the key on a KMIP endpoint of your tenant
curl -X POST "$COCKPIT/api/keys/$KEY_ID/kmip-publications" \
-H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
-d '{"endpoint_id":"<kmip endpoint id>"}'
# -> {"unique_identifier":"kmip-...","endpoint_slug":"..."}
# List, then withdraw a publication
curl "$COCKPIT/api/keys/$KEY_ID/kmip-publications" -H "Authorization: Bearer $TOKEN"
curl -X DELETE "$COCKPIT/api/keys/$KEY_ID/kmip-publications/<unique identifier>" -H "Authorization: Bearer $TOKEN"
The KMIP client then sends Get with the returned Unique Identifier. To publish asymmetric keys, add PrivateKey to the endpoint's allowed object types.
The published object holds no key material: every Get re-checks the key, so withdrawing the exportable flag, binding a quorum policy on export, or deleting the key closes the KMIP channel immediately. The published object can only be exported; it cannot be used for server-side encryption, and a KMIP Destroy only withdraws the publication, never the key itself.
With the DuoKey CLI
read -rs DKE_EXPORT_PASSWORD && export DKE_EXPORT_PASSWORD # typed, not echoed
dke keys export $KEY_ID --format pkcs8 --out key.p8.pem
dke keys export $KEY_ID --format pkcs12 --out key.p12
dke keys export $KEY_ID --format wrapped --wrapping-key import-key.pem --out key.bin
The CLI reads the password from an environment variable (--password-env, default DKE_EXPORT_PASSWORD) or from standard input, never from a command-line argument, and does not overwrite an existing file without --force.
Audit
Every export is recorded in the activity log on the key, with the user and the format, whatever the key's own audit setting. A KMIP Get that serves a published key is recorded the same way and names the endpoint, and each publication is recorded too. The activity log shows them all under the Export action. Neither the key material nor the password is ever written to a log or to the audit trail.
Double Key Encryption keys
A DKE key is an ordinary Cockpit key, so the same rules apply: it is exportable only if it was created exportable in the Software Vault or the Securosys HSM. A DKE key held in a cloud KMS, the DuoKey MPC KMS or behind the HSM Agent cannot be exported. Decide at creation time: the exportable flag cannot be added afterwards.
Whoever holds an exported private key and its password can decrypt everything protected by that key, outside the Cockpit and its access policies. Keep exported files and passwords apart, and keep them only as long as you need them.