Skip to main content
The Lit Chipotle API server runs inside an Intel TDX Trusted Execution Environment on Phala Cloud, with its keys gated by smart contracts on Base. This section explains how that works and how to verify it yourself.

Start with the report and quick diagnostics

Phala Trust Center report plus preliminary API metadata and on-chain policy checks, with the prerequisites for attestation and TLS verification.

​
Production verification

Follow Phala’s official application verification instructions and complete chain-of-trust checklist for full production verification. They are the authoritative references for Phala/dstack verification; the examples here are diagnostic aids. You are responsible for implementing and enforcing attestation verification in your integration. What you need to implement depends on your setup and where and how your client connects to Chipotle, including proxies, gateways, and TLS termination points. Verify against your approved workload and security policy, and bind the verified identity to the connection carrying application traffic before sending secrets. A Trust Center report or a separate diagnostic connection does not enforce these checks in your client.

​
Zero-Trust TLS

What is Zero-Trust TLS? In traditional web hosting, you trust the server operator not to inspect or tamper with your traffic. Zero-Trust TLS (ZT-TLS) eliminates this trust assumption entirely. The TLS private key is generated inside the Trusted Execution Environment (TEE) and never leaves it — not even the cloud provider, OS administrator, or Lit Protocol team can extract it. How it works for Lit Chipotle:
  1. The dstack-ingress container, running inside the CVM, generates a private key and requests a TLS certificate from Let’s Encrypt via DNS-01 challenge (Route 53). The private key never leaves the TEE.
  2. DNS CAA records for the domain restrict which CAs can issue certificates and require DNS-01 validation with a specific ACME account URI, ensuring only the TEE-controlled ACME flow can obtain a cert.
  3. The certificate and ACME account are recorded as evidence files. Their SHA-256 checksums are hashed into a single digest that is embedded in a TDX attestation quote’s reportData field.
  4. Because the quote is signed by Intel’s TDX hardware root of trust and bound to this digest, anyone can cryptographically prove the certificate was generated inside this specific TEE.
What you must verify: A valid public-CA certificate and successful TLS handshake do not by themselves prove TEE termination. Authenticate the evidence quote and approved workload, verify the certificate’s checksum binding, and enforce that certificate on the connection used for application traffic. Contrast with traditional TLS: Traditional TLS proves identity (the server holds the private key for this domain) but says nothing about where the key lives or what code uses it. ZT-TLS closes that gap: the key can only exist inside attested TEE hardware.
Zero-Trust TLS means the encryption endpoint is the trust boundary. Once you verify the certificate was issued to the TEE, the HTTPS connection itself becomes your proof of confidentiality.
For the full design, see Phala: TEE-Controlled Domain Certificates.

​
Inspect the TLS Certificate

The command below only inspects the certificate. It does not verify an attestation quote or prove TEE termination.
  • The certificate is issued by Let’s Encrypt (a public CA) to the exact domain.
  • Public-CA validity alone does not prove that the private key lives in a TEE. Follow the authentication prerequisites in the Full Verification Guide.
  • For programmatic clients: pin the certificate fingerprint after initial verification (see Certificate Pinning below).

​
Certificate Pinning

Once full verification passes, pin the TLS certificate fingerprint:
  1. Record the SHA-256 fingerprint from the verification above.
  2. On subsequent connections, validate the cert matches the pinned fingerprint — this is fast and doesn’t require re-running attestation.
  3. When to re-verify: After any CVM redeployment, a new TLS cert is generated inside the TEE. Re-run the full verification and update your pinned fingerprint.

​
What’s Next

  • Verify in 30 Seconds — Phala Trust Center report and preliminary metadata and policy checks
  • On-Chain KMS — how Base smart contracts gate key release and how to confirm the KMS is active
  • Full Verification Guide — Chipotle-specific diagnostic examples and prerequisites; follow Phala’s instructions for production
  • Chain of Trust Reference — detailed explanation of what each verification step checks and why it matters

​
Further Reading