certz
A confidential, on-chain certificate authority.
Certz issues real X.509 certificates signed by a CA key that lives only inside a TEE. Ownership is proven with DNS-01, verified in an Oasis ROFL enclave, and every issuance is anchored in a public, auditable on-chain registry.
A certificate authority whose private key no one can read.
Confidential signing and public transparency, combined. Five properties define Certz.
TEE-held CA key
The CA private key is generated inside an Oasis Sapphire confidential contract and never leaves the TEE. No operator, admin, or host ever sees it.
ACME-style DNS-01 proof
Domain control is proven by publishing a TXT record at _certz-challenge.<domain> — the same ownership model ACME clients already use.
Public transparency log
Every issuance is anchored on-chain: domain → certificate digest, with status and revocation. Auditable by anyone, Certificate-Transparency style.
Out-of-band verifier
A verifier checks a presented certificate against the on-chain CA root and registry — a DANE-like layer on top of normal HTTPS.
Built on Oasis Sapphire
A confidential, TEE-backed EVM chain. Signing stays private; the audit trail stays public. Both properties from one platform.
The result: a CA you can audit but cannot impersonate.
Request, prove, sign, anchor, verify.
A single issuance walks through six steps. The signing key never leaves the enclave at any point.
- 01
Request
A caller asks Certz for a certificate for their domain.
- 02
DNS-01 challenge
Certz returns a token to publish as a TXT record at _certz-challenge.<domain>.
- 03
ROFL TEE verifies
An Oasis ROFL enclave resolves DNS and attests that ownership checks out.
- 04
Confidential CA signs
The on-chain CA contract signs the X.509 cert inside the TEE — key never exposed.
- 05
Recorded on-chain
The issuance is anchored in the public registry: domain → digest, with status.
- 06
Verify out-of-band
Anyone checks a presented cert against the CA root and registry, DANE-style.
Two properties that normally fight each other, on one chain.
Traditional CAs ask you to trust that an operator protects the signing key and runs an honest log. Certz removes the operator from both.
Confidential signing
Sapphire runs the CA contract inside a TEE. The key is born there, used there, and never exported — not even to the node operator.
Public transparency
The registry contract is plain on-chain state. Anyone can enumerate issuances, confirm a digest, or watch for mis-issuance — no privileged access required.
What Certz is not.
An honest CA has to be honest about its limits, too.
Not trusted by browsers
Certz certificates are not in any browser root program. Mainstream TLS trust requires audited inclusion in Mozilla/Apple/Microsoft/Chrome stores — out of scope here. Browsers will not show a green lock for a Certz cert.
Extension is soft-verify only
A future browser extension can only do advisory verification — a badge or warning. Chrome exposes no API to override TLS validation, so it can never replace the browser's own trust decision.
A testnet research demo
This is a working proof of concept on Oasis Sapphire testnet, not a production CA. The site currently runs against a local mock of the data-layer while the contracts are finalised.
Issue a certificate in the open.
Run the full flow against the mock client — prove a domain, get a PEM, and see the on-chain registry record it produces.