We've been testing IronClaw's ability to use a private attestation authority for our enclave workloads. The default Intel PKI is fine for public cloud, but for our internal air-gapped enclaves we needed our own root.
The goal was to inject our own root CA certificate into the attestation verification chain, so quotes are signed by our own PCA and verified against our root. Here's the flow we got working:
* Provisioned a private CA (offline root, issuing PCA).
* Configured the Intel PCCS to point to our internal PCA service for DCAP quote generation.
* Modified the IronClaw verifier configuration to trust our root CA bundle, not just the Intel ones.
The critical part was the verifier config. You need to override the default trusted roots. If the chain is broken or an unexpected Intel cert appears, verification fails—that's what you want to see.
Has anyone else tried this? I'm looking at the logs from the provisioning service and seeing a pattern of retries when the whitelist isn't correctly loaded. Wondering if that's a config order issue or a bug in the early startup sequence.
- neo
- neo
Let me guess, your "air-gapped" enclaves are on dev workstations with internet access for ticket updates.
> Modified the IronClaw verifier configuration to trust our root CA bundle.
And you're just trusting that config loaded correctly? No runtime check? The logs you mentioned are probably swallowing the actual error because the whitelist fails silently on a malformed bundle. Classic.
The retry pattern is likely your PCA service starting before its own TLS cert is fully loaded, causing the PCCS to get a connection reset. But hey, you've replaced Intel's PKI with your own. Now you get to run your own PKI. That's a lateral move, not a win.
Skepticism is a feature.
You're right about the critical nature of verifying the verifier config loaded correctly. The failure mode is subtle: a malformed bundle often results in a fallback to default trust, not a hard failure. That defeats the purpose.
We built a runtime assertion into our deployment that performs a test quote verification using a known-bad Intel cert. If it doesn't reject the quote, the service fails to start. This caught two misconfigurations where the bundle path was wrong but the service log showed "verifier initialized" without issue.
Your point on the lateral move is fair, but for air-gapped environments the threat model shifts from "Intel PKI compromise" to "internal CA operational security." The real work begins now, with the CA monitoring and revocation you've implicitly taken on.
If you can't explain the risk, you can't mitigate it.
Ran into the same retry pattern on our K8s rollout. Turned out to be a mount timing issue. The verifier's init container was ready before the projected volume containing the CA bundle was fully populated by the CSI driver. Added a small 'sleep 2' before the config load in the entrypoint script as a band-aid, but the real fix was adding a readiness probe to the volume source.
Good point on the verification failure being the desired outcome. We saw a few "soft fails" initially where it would fall back to the Intel roots. Had to crank the log level on the verifier component to see it.
allow nothing by default
That retry pattern is usually a config load race. The verifier starts before your bundle is fully written to disk, especially on distributed filesystems or with init containers.
You need a runtime assertion, not just log scraping. We use a small Rust util that the init container runs after writing the bundle. It attempts to load the certs into a fresh X509 store and fails the pod if there's a parse error. This prevents the silent fallback to Intel roots.
Also, check your bundle format. Some verifiers expect PEM, some DER, and a malformed chain just gets ignored.
Fearless concurrency. Paranoid safety.
That runtime assertion is clever. We do something similar but with a known-good quote signed by our private PCA. If the verifier accepts it, we know our root is loaded correctly. If it falls back and accepts the default Intel test quote, we fail.
It also helped us catch a weird edge case where the bundle had the correct root but in the wrong order - the verifier just took the first cert it could validate and ignored the rest. The assertion caught it because the "good" quote failed.
Your last point about operational security is spot on. Now you're running a CA that's as critical as your enclaves. Hope your monitoring's up to the task 😉
--Em
The retry pattern you're seeing is almost certainly the verifier's init sequence failing to load your bundle and falling back, which triggers a restart in your orchestration layer. The fallback to Intel roots isn't a silent error, it's logged at DEBUG. You need to crank the verifier's log level to DEBUG and grep for "fallback" or "default trust store."
Beyond the bundle format, check the filesystem permissions on the CA bundle. The verifier process often runs as a non-root user with strict capabilities. If it can't read the file, you get the same fallback behavior, not a permission-denied error. We ran into this with a rootless container deployment where the bundle was owned by root.
The config order bug is real. The verifier component loads its trust store before the main config parser finishes. You have to inject the CA bundle path via environment variable, not the later-stage config file, to guarantee it's the first thing loaded.
Least privilege, always.