Published At: 2026-10-15 Summary: The proposed wif-01 challenge type lets ACME (RFC 8555) clients obtain certificates using the identity their platform already provides, with no stored credentials Categories: [acme, rfc8555, workload identity federation, OIDC, openid connect, secret zero, tls, x.509 certificate management]
Disclaimers:
ACME is a protocol for issuing X.509 certificates. It was developed to make it easy to automate HTTPS/TLS for web servers. The protocol has some really handy features: - Private keys are generated by the client and never sent over the protocol - Clients authenticate with an account key, which can be tied to an existing customer account via External Account Binding (EAB) - The certificate authority can challenge the client to prove control of what it's requesting before issuing the certificate - It's designed to be fully automated
Originally developed for the Let's Encrypt certificate authority, ACME is now ubiquitous across the public certificate space, and it continues to gain traction with private certificate authorities. What it lacks is a way for a workload to prove who it is, rather than which domain it controls, without first being handed a credential.
WIF-01 adds exactly that: a standard way for any ACME client to get a certificate from any ACME CA using the identity its platform already provides.
Secret zero is the initial credential needed to access resources: the "bootstrap" credential for a system, platform or secrets manager. Every credential has to be created, transferred, stored, rotated and monitored, and each of those steps is an opportunity for it to leak. Modern authentication approaches aim to remove secret zero entirely.
Workload Identity Federation, or WIF for short, is one of those approaches. It has become commonplace in enterprise environments for authentication between services, because the workload never holds a long-lived secret.
With WIF, the client obtains a passport (a JWT) from the platform it runs on, such as Kubernetes, a CI/CD system or a cloud provider. The issuer depends on the platform, but they all follow the same process and issue the same kind of passport. Inside the passport is a field that identifies the client (sub). The client presents its passport to a receiving party as identification. The receiving party is already configured to trust the passport's issuer, and checks the passport's signature against the issuer's published keys. Once the passport is verified, authentication can proceed.
Key attributes of this approach: - The passport usually expires only a few minutes after it is issued - The receiving party must already trust the issuer - The passport can include a value supplied by the receiving party, proving it is fresh and intended only for that party
ACME already supports authentication and challenges.
For authentication in private deployments, External Account Binding is typically used. The ACME server issues a key ID and HMAC key (the equivalent of a username and password) to the client, which uses them to link its ACME account to an existing account before requesting certificates. That is a secret zero: the credentials must be created, securely transferred to the client environment, stored there and rotated when required.
Challenges are different: after a request is made, the ACME server performs a challenge to confirm the client is authorised to obtain the requested certificate. The common challenge types are:
These work well for public web servers, but they all prove control of a domain or endpoint. They don't help when the certificate isn't for a public name, when the CA can't reach the client, or when automating the challenge needs its own credential. DNS-01 automation, for example, needs DNS API credentials, which just moves secret zero to your DNS provider.
WIF-01 brings the passport model to ACME:
Step 6 is where the trust decision lives. The CA operator defines which workloads (issuer + subject) may obtain which certificates, for example "the payments service in the production cluster may obtain client certificates for payments". The workload never holds a credential for the CA; its identity comes from where it runs.
One practical note: the ACME server must be able to fetch the JWT issuer's public keys, so locked-down environments may need to publish them somewhere the CA can reach.
There are already ways to get certificates without a stored credential: SPIFFE/SPIRE, Vault PKI with JWT authentication, step-ca's OIDC provisioner, and cloud providers' private CA APIs. They work, but each has its own API, client and integration. Today, many certificates are obtained through a certificate lifecycle management (CLM) tool, using vendor-specific REST APIs or command-line tools.
WIF-01 makes this a standard. Any ACME client can talk to any ACME CA, using the identity the platform already provides. There's nothing new to learn, no vendor lock-in, and the huge existing ecosystem of ACME clients can benefit.
There are many uses for X.509 certificates where automation would help but which have nothing to do with proving control of a public domain. For example:
Mutual TLS (mTLS) certificates carry a specific flag (clientAuth) that allows them to be used for client authentication. They identify a client rather than a website, so there is often no domain to prove control of, and the DNS and HTTP challenge types don't apply.
Modern mTLS implementations rely on narrowly scoped certificate authorities and short-lived certificates, valid for minutes to hours. The server authenticating the client is configured to trust a private certificate authority, ideally one dedicated to that relationship. Any certificate issued by that CA can be trusted by the server (with optional field-level validation). Short lifetimes mean frequent renewal, which only works if renewal is fully automated and needs no credential. ACME-WIF provides exactly that.
SSH authentication has already moved past passwords to private keys, and is now moving past private keys to short-lived certificates. As with mTLS, the SSH server is configured to trust certificates issued by a private, narrowly scoped certificate authority.
Automation platforms like Ansible can obtain a short-lived certificate, authenticate to the target system and execute a runbook. Ansible itself doesn't need to hold any secrets or credentials; everything is ephemeral.
Mobile applications often need a public key to encrypt data, for example before sending it to a backend. Managing and rotating that key is difficult because users may not be running the latest version of the app. Delivering the key in a certificate provides a built-in expiry, along with metadata the app can validate.
In this scenario, the mobile app is configured to trust a private certificate authority. The backend service or build pipeline that owns the key obtains a certificate for it using ACME-WIF, authenticating with its platform identity rather than a stored CA credential. The certificate is then published at a public URL for the app to fetch. Because the app trusts the issuing CA, it can trust the public key in the certificate for encrypting data.
Creating short-lived test environments entirely through automation is increasingly common in modern software development. These environments benefit from being as close to production as possible, which often means enabling HTTPS. Because they are short-lived and often isolated, HTTP and TLS-ALPN challenges are usually impractical, and DNS-01 means giving every pipeline DNS API credentials. ACME-WIF lets the pipelines that build these environments obtain certificates using the identity the CI/CD platform already gives them.
Highly regulated environments often have a "traffic out, but not in" restriction. HTTP-01 and TLS-ALPN-01 aren't viable because the CA can't connect into the environment. DNS-01 doesn't need inbound traffic, but internal names often aren't in public DNS, and automating it requires DNS credentials, which these environments are trying to avoid. The environment already bakes in the CA's trust anchor and still needs HTTPS for its internal services.
Workloads in these environments often run on platforms that can issue a JWT, such as Kubernetes or a cloud provider. ACME-WIF lets them obtain certificates using only outbound connections, while narrowing the integration from a full vendor REST API to just the ACME protocol.
WIF-01 is currently a proposal, and feedback is what turns a proposal into a standard. You can read the draft here: https://datatracker.ietf.org/doc/draft-rasmussen-acme-wif/. If you run an ACME CA, build an ACME client, or have a use case I haven't covered, I'd love to hear from you.