attezt is a Go-based suite of remote attestation components that issues hardware-backed device certificates via the ACME device-attest-01 challenge for authorized identity infrastructure.

attezt is a suite of remote attestation tools written in Go, published under the MIT license, that answers a question many infrastructure teams eventually hit: how do you turn a TPM, which every modern Linux machine ships with, into a usable, hardware-backed device identity for mTLS? The project, currently sitting at 63 stars and tagged with topics like tpm, tpm2, acme, attestation, and device-attestation, implements the device-attest-01 ACME challenge end to end. The README is candid about maturity — it labels the whole project a WIP — but the architecture it describes is coherent and worth studying regardless.

The suite decomposes into three cooperating components. atteztd is the Attestation Certificate Authority, the server-side piece that validates attestation claims and signs device certificates. attezt-agent is the client-side daemon that holds and serves the TPM-backed certificate over a PKCS11 agent, making the key material usable to ordinary software without ever leaving the TPM's protection boundary. The attezt binary itself is the management plane, letting administrators check device enrollment, provision certificates, and administer the attestation CA from one entry point.

What makes attezt interesting architecturally is the device-attest-01 ACME challenge itself. Where classic ACME (http-01, dns-01) proves control over a domain, device-attest-01 proves possession of a hardware key — typically an Attestation Key (AK) seeded in the TPM's endorsement hierarchy. The README shows the resulting certificates being attested by the ak, meaning the private key never exists as a file on disk. For environments that want a strong device identity claim feeding into X.509 certificates used for mTLS setups, this is the intended use case, stated almost verbatim in the project description.

On the server side, atteztd exposes a backend inventory API that can query a CMDB for device inventory and validate devices against it. This is the detail that elevates the tool beyond a demo: real attestation deployments live or die on the verification database, because signing a certificate proves nothing unless the CA cross-checks the TPM's Endorsement Key against a known-good device registry. Wiring atteztd to a CMDB is how an operator turns cryptographic proof of identity into an authorization decision — device X is known, enrolled, and therefore allowed a certificate. The README notes current support for smallstep, with step-ca acting as the front-door ACME endpoint that delegates attestation challenges to atteztd.

The smallstep integration path is documented concretely. After attezt ca create builds a small CA chain, atteztd starts an HTTP listener (the README shows it on :8080). The operator then fetches root.pem from that listener and registers an ACME provisioner in step-ca with step ca provisioner add, passing --type ACME, --challenge device-attest-01, --attestation-format tpm, and --attestation-roots pointing at the downloaded root. From that point, step ca certificate with --attestation-ca-url and an --attestation-uri like tpmkms:name=device issues a device certificate, and step ca renew --kms tpmkms handles renewal — all through the standard step CLI an administrator already knows.

The client side is where attezt-agent earns its keep. Run with sudo, it starts a p11kit-server exposing a UNIX socket (illustrated as /run/attezt/p11kit.socket) and a varlink service at /run/attezt/dev.attezt.Agent. Any PKCS11-aware application can then consume the TPM-held certificate transparently. The README demonstrates enrollment with attezt enroll --acme and --attestation URLs, and attezt status prints the Endorsement Key hash, enrollment state, the ACME and attestation server endpoints, and the full X.509 chain including subject, issuer, provisioner, and validity window — a useful debugging surface when a fleet enrollment goes sideways.

The browser integration example is particularly practical, because client-certificate mTLS in browsers is a notorious pain point. The README walks through registering p11-kit-client.so into the NSS database with modutil, exporting P11_KIT_SERVER_ADDRESS to point at the agent socket, and shipping a Chromium managed policy (/etc/chromium/policies/managed/mtls.json) that uses AutoSelectCertificateForUrls with an issuer filter tied to the internal CA. The result: Chromium automatically presents the TPM-backed certificate to matching internal sites, giving hardware-certified client authentication to web applications with zero user interaction. That end-to-end story — TPM to ACME to PKCS11 to browser — is rare to find in one toolchain.

One important caveat the README flags explicitly deserves emphasis: a bare atteztd will sign any certificate capable of solving the challenge. In other words, out of the box there is no allow-listing — the CMDB inventory integration is the mechanism that turns the CA from a cryptographic notary into a policy-enforcing authority. Operators deploying this in anything beyond a lab should treat the inventory backend as mandatory, not optional, and should think hard about what their CMDB actually asserts before trusting its verdicts. This is standard attestation-systems wisdom: the crypto is the easy part; the trust anchors and the device database are where deployments succeed or fail.

From a defensive perspective, attezt is infrastructure hardening rather than an attack surface. Hardware-backed keys are non-exportable, which removes the entire class of incidents involving stolen client certificate private keys from disk, memory dumps, or backups. Enrollment also leaves a clean audit trail — Endorsement Key hashes recorded at enrollment, certificate serials in CA logs, and observable mTLS handshakes — giving defenders concrete artifacts to monitor. A security team reviewing this stack should focus on the usual PKI hygiene: protecting the root and intermediate keys, restricting who can modify the CMDB records that atteztd consults, and monitoring the atteztd listener for unauthorized access, since it holds signing power.

For who should look at this: platform engineers building zero-trust or mTLS-heavy internal infrastructure, especially on Linux fleets with tpm2 hardware, will find attezt a credible open building block despite the WIP label. The author is a known Arch Linux developer and signer (Foxboron), which lends the project credibility in the trust-and-identity niche. It is not a turnkey product — expect to run smallstep's step-ca, maintain a CMDB integration, and handle fleet enrollment yourself — but as a blueprint for how TPM-backed ACME attestation should fit together, from attezt ca create down to a Chromium policy file, the repository is an unusually complete reference implementation for authorized, defensively-oriented identity work.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Related coverage

• Meta_SecAlign for built-in prompt injection defense in open-weight LLMs


• Inside PCYBOX AttackGraph: how a browser lab turns attack paths into something you can watch and defend


• TRACE for probing security risks in LLM agents