Issuing Post-Quantum ML-DSA-65 Certificates

Path A: Software Key ML-DSA-65 (Recommended First)

Generate the key and certificate with OpenSSL 3.5 (Generating a Test ML-DSA-65 Certificate), then register them:

curl -X POST http://<console>:8081/api/v1/certificates \
-H "Authorization: Bearer <token>" -H 'Content-Type: application/json' \
-d '{
    "name": "gw-mldsa",
    "domain": "gw.example.com",
    "cert_pem": "<ML-DSA-65 certificate chain in PEM>",
    "key_pem": "<ML-DSA-65 private key in PEM>",
    "cert_type": "external_ca",
    "key_source": "local",
    "key_algorithm": "ml-dsa-65",
    "cluster_id": "<target cluster UUID>"
}'

The private key is stored encrypted, delivered as ciphertext, and decrypted by the gateway node into memory only.

Path B: HSM-Managed ML-DSA-65

UI path: Cluster Certificate Management → Add Certificate → key source Utimaco HSM managed → key algorithm Post-quantum ML-DSA-65 (the UI notes that Quantum Protect firmware is required).

curl -X POST http://<console>:8081/api/v1/certificates \
-H "Authorization: Bearer <token>" -H 'Content-Type: application/json' \
-d '{
  "name": "gw-mldsa-hsm",
  "domain": "gw.example.com",
  "key_source": "utimaco_hsm",
  "key_algorithm": "ml-dsa-65",
  "hsm_key_label": "<key label inside the HSM; defaults to <key_label_prefix><name>>",
  "cluster_id": "<target cluster UUID>"
}'

An ML-DSA-65 key pair is then generated inside the HSM through PKCS#11 — the private key never leaves it — and the certificate records the key source, the algorithm and the key reference. The list view shows it as "HSM managed · ML-DSA-65".

key_source defaults to local . For HSM-managed certificates key_algorithm defaults to ecdsa, so ml-dsa-65 must be specified explicitly to obtain post-quantum. Valid algorithm families are rsa , ecdsa , sm2 and ml-dsa-65.

Activation, Rotation and Revocation

  • No manual delivery step is needed. After a certificate is created, rotated, deleted or revoked, it is delivered to the online gateway nodes of its cluster and acknowledged. A node that (re)connects receives the full current set for its cluster_id .

  • Hot activation: new connections use the new certificate immediately; a node restart is not required.

  • Rotation (POST /api/v1/certificates/<id>/rotate) retains the original key source and algorithm by default; both can be overridden explicitly in the request.