Gatekeeper

Test or unsigned builds

What to do when Gatekeeper denies with "not in the Super Protocol trusted registry": accept the measurement yourself, or trust the cloud's root certificate.

How-toFor developers

Needed only when the cloud's measurement is not signed in the Super Protocol registry, which is what a local or test build looks like, and Gatekeeper denies with not in the Super Protocol trusted registry. The production router is registry-signed; the default path on Connect needs none of this.

The denial reads like this, with the measurement of the cloud you pointed at:

DENIED — … not in trusted store (attested-root check: measurement bb6962eb… isnot in the Super Protocol trusted registry, and it is not listed inattestedRoots.trustedMeasurements — the hardware report verified, so this iswhat an unsigned or test build looks like (see "Optional: test or unsignedbuilds" in the setup guide); pin it with `gatekeeper trust measurements add--from-upstream router`, or add the cloud's root with `gatekeeper trust roots add`)

The hardware report verified. What is missing is Super Protocol's signature on the image, which is a statement only Super Protocol can publish. Two ways in, strongest first.

Accept this cloud's measurement yourself

shfrom the console
gatekeeper trust measurements add --from-upstream router

It fetches the bundle, runs the whole attested-root check, prints the full hardware report, and asks before writing. Everything else still has to pass: the report must chain to the CPU vendor, commit to the certificate's key, and reproduce the rebuilt measurement; requireNetworkType still applies; every policy still runs; and the endpoint's own digest pin still has to match. A root admitted this way is reported as attested (operator-pinned), never as registry-signed.

list and rm are the other two verbs; rm takes the hex the reports print. --yes skips the question for a script.

Or trust the cloud's root certificate

Code examples
shfrom the console
curl -fsSL https://router.superprotocol.com/swarm-root.pem | gatekeeper trust roots add swarm-prod --pem-file -
PowerShellfrom the console
irm https://router.superprotocol.com/swarm-root.pem -OutFile swarm-root.pem; gatekeeper trust roots add swarm-prod --pem-file swarm-root.pem

This skips the attested check for that certificate authority entirely and works offline. The certificate is fetched from where Super Protocol publishes it, not from the endpoint under inspection: a root taken from the thing it vouches for would prove nothing. The landing page prints the fingerprint the command should echo back, sha256:2d9c20a6…54c276; if it prints anything else, stop.

A root added this way is matched by the SHA-256 of its DER. Adding one that is already trusted under another name is a no-op.

Afterwards

A running Gatekeeper asks the registry again once its 10-minute cache (attestedRoots.cacheTtl) expires, within about 15 minutes with the default re-attestation, so a cloud whose measurement is signed later is admitted without a restart. At that point the operator pin is no longer what admits it: a measurement that is in the registry is always reported as registry, even if you pinned it too.

To require the closed chain and nothing else, a one-rule policy refuses every operator-pinned root:

rego
package user.registryonlyimport rego.v1default allow := falseallow if not input.attestation.rootAttestationallow if input.attestation.rootAttestation.measurementSource == "registry"