Deployment Bundle Example (Linux)

This is exactly what Export Bundle → Linux produces from the Oracle TDE app detail page (Getting Started, Step 1), with realistic placeholder values substituted for the real app_id, access_guid, and access_token. Deploying on Windows instead? See the Windows bundle example.

# Oracle TDE Deployment Bundle
# App: my-oracle-db
# Access GUID: a8a7344f-244a-4f10-966d-b2f3094612c3
# Master key: TDE-MASTER-20260811 (8ce6e566-5ee3-4a38-9700-a55113a2fecc)

## 1. pkcs11.toml  (install at: /home/oracle/.dke/pkcs11.toml)
# DKE Oracle TDE PKCS#11 Provider Configuration
# Generated: 2026-08-11 13:29:59 UTC

[http_config]
server_url = "https://cockpit-api-test.duokey.cloud/api/apps/7d3b929b-18cb-4bd7-b518-47a49a9cb2de/tde/pkcs11/a8a7344f-244a-4f10-966d-b2f3094612c3"
access_token = "8ed23e3a5a568b497d4447e15302c3a6f5464e0fc0d583fa69787c3fc8153c16"
timeout_secs = 30
verify_tls = true

[pkcs11]
slot_id = 0
logging_level = "info"
logging_folder = "/var/log/dke-pkcs11"

## 2. Install the PKCS#11 library  (target: /opt/oracle/extapi/64/hsm/DuoKey/1.0/libdke_pkcs11.so)
# The libdke_pkcs11.so must be linked against a glibc no newer than the database host's. Do not
# infer the OS from the Oracle version — e.g. the official container-registry.oracle.com/database/
# enterprise:19.3.0.0 image is Oracle Linux 7.9 (glibc 2.17), not OL8. Run `ldd --version` as the
# oracle OS user on the actual host and build on a matching-or-older glibc baseline. Verify with:
# objdump -T libdke_pkcs11.so | grep GLIBC_ (nothing above the host's real glibc must appear).
sudo mkdir -p /opt/oracle/extapi/64/hsm/DuoKey/1.0
sudo cp libdke_pkcs11.so /opt/oracle/extapi/64/hsm/DuoKey/1.0/
sudo chown -R oracle:oinstall /opt/oracle/extapi/64/hsm
sudo chmod 0755 /opt/oracle/extapi/64/hsm/DuoKey/1.0/libdke_pkcs11.so

## 3. Environment variables
DKE_PKCS11_LOGGING_LEVEL=info
DKE_PKCS11_CONF=/home/oracle/.dke/pkcs11.toml

## 4. SQL deployment scripts

-- 1. Set Wallet Root
-- Configure the Oracle wallet root directory.
ALTER SYSTEM SET WALLET_ROOT='/opt/oracle/admin/ORCL/wallet' SCOPE=SPFILE;

-- 2. Restart Database
-- Restart required for WALLET_ROOT to become active. This MUST run before the next step —
-- setting TDE_CONFIGURATION while WALLET_ROOT is still pending (SPFILE-only) fails with
-- ORA-32017/ORA-46693.
SHUTDOWN IMMEDIATE;
STARTUP;

-- 3. Set TDE Configuration
-- Set TDE to use HSM mode. Run only after the restart above.
ALTER SYSTEM SET TDE_CONFIGURATION='KEYSTORE_CONFIGURATION=HSM' SCOPE=BOTH;

-- 4. Open HSM Keystore
-- Open the HSM-backed keystore for every container (CDB root + all PDBs). The PIN is a syntactic
-- placeholder only — the real credential is access_token in pkcs11.toml, presented as
-- Authorization: Bearer — but Oracle's grammar requires a literal string here, not EXTERNAL STORE.
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "<pin>" CONTAINER=ALL;

-- 5. Set TDE Master Key
-- Create and activate the master encryption key for every container. Run this in the SAME
-- session as the previous step — Oracle's default 3-second HSM heartbeat can close the keystore
-- if too much time passes between separate sqlplus sessions.
ADMINISTER KEY MANAGEMENT SET KEY
  IDENTIFIED BY "<pin>"
  WITH BACKUP USING 'dke_tde_backup_20260811'
  CONTAINER=ALL;

-- 6. Enable Auto-Login (Optional)
-- Auto-open keystore on startup.
ADMINISTER KEY MANAGEMENT CREATE LOCAL AUTO_LOGIN KEYSTORE
  FROM KEYSTORE '<wallet_root>/tde'
  IDENTIFIED BY "<wallet_password>";

-- 7. Encrypt Tablespace (Example)
-- Example: encrypt USERS tablespace.
ALTER TABLESPACE USERS ENCRYPTION ONLINE
  USING 'AES256'
  ENCRYPT;

-- 8. Verify Encryption
-- Verify TDE is active.
SELECT KEY_ID, KEYSTORE_TYPE, ACTIVATION_TIME
FROM V$ENCRYPTION_KEYS
WHERE ACTIVATION_TIME IS NOT NULL;

SELECT TABLESPACE_NAME, ENCRYPTED
FROM DBA_TABLESPACES;

SELECT WRL_TYPE, STATUS, WALLET_TYPE
FROM V$ENCRYPTION_WALLET;

server_url uses the API hostname, not the frontend one

Notice cockpit-api-test.duokey.cloud, not cockpit-test.duokey.cloud — Cockpit v2 serves the machine-facing API and the browser UI on separate hostnames. If you ever see <cockpit-host> literally in a bundle instead of a real hostname, or a bundle whose server_url points at the browser UI's hostname, treat it as a bug — a curl/Invoke-WebRequest against it should return JSON ({"ok":true,"status":"ready",...}), never an HTML page.

Never commit this file to version control or paste it into a ticket/chat — it contains the real access_token bearer credential.