Private Key is generated locally in your browser. Only the CSR is sent to Vault for signing. Your key never leaves your device.
Pros: Maximum security — the private key never leaves the device; on rotation you reuse the same key and re-sign a fresh CSR (only the cert changes).
Cons: More client-side crypto — and each rotation needs the client to regenerate and re-upload a CSR (no server-side one-click).
1. Choose Subdomain:
.demo.konekt.io
*.demo.konekt.io wildcard. It becomes the client cert CN and the SNI/Host used to reach the gateway — all partners share one wildcard server cert + one route. Leave empty to use the default mtls.demo.konekt.io for access.5m, 1h, 168h). Capped by the role max_ttl = 720h — a role-level ceiling, not a per-request value; Vault silently truncates anything larger. A short TTL makes rotation observable fast. The private key and CSR never expire — only this leaf does.2. Generate CSR Locally:
openssl req -new -newkey rsa:2048 -nodes -keyout mtls.demo.konekt.io.key -out mtls.demo.konekt.io.csr -subj "/CN=mtls.demo.konekt.io"
3. Paste CSR to Sign:
Vault generates both the Private Key and the Certificate centrally on the server, then returns them to the client.
Pros: Simpler client — the server does all crypto. Rotation is one call: Vault re-issues key + cert, with no client-side CSR step.
Cons: Lower security — every issuance and every rotation mints a new private key and sends it over the network.
1. Choose Subdomain:
.demo.konekt.io
*.demo.konekt.io wildcard. It becomes the client cert CN and the SNI/Host used to reach the gateway — all partners share one wildcard server cert + one route. Leave empty to use the default mtls.demo.konekt.io for access.5m, 1h, 168h). Capped by the role max_ttl = 720h — a role-level ceiling, not a per-request value; Vault silently truncates anything larger. A short TTL makes rotation observable fast. The private key and CSR never expire — only this leaf does.2. Vault Direct Issuance
Client requests a full identity from Vault for mtls.demo.konekt.io. Vault generates both the Private Key and the Certificate internally and returns them together. Both files will be downloaded automatically.
Leaf certs are short-lived and rotated often (role ttl, ≤ 720h) — unlike the CA, which lives for years. A rotation re-mints a leaf under the same CA (serial + validity change; CN and CA stay). The two paths rotate differently: Path A re-signs a new CSR — the private key stays on the device and can be reused, only the cert changes; Path B has Vault re-issue a brand-new key + cert (key crosses the network). Re-sign / re-issue in the cards above (both logged below), or one-click Path B here.
No leaf issued yet — click above, or provision one in Path A / B.Test the mTLS connection natively through this Web App (via Next.js BFF proxy). If you used Path B, both credentials are auto-filled. If you used Path A, the cert is auto-filled but you must manually paste your locally generated client.key!
Rotating the client-trust CA (the CA that signs partner leaves) must not drop in-flight terminals. Trust both CAs during an overlap window, migrate, then drop the old one. Two fixed probe leaves — one signed by CA v1, one by CA v2 — are re-tested against the gateway after each step; their ✓/✗ flipping is the proof. The trust bundle lives in Vault KV and syncs via VSO (~30s) into the secret APISIX hot-reloads. The demo-v2 CA is self-bootstrapped by this app on first use (no shell step).