In Sigstore's keyless flow, what does a Fulcio certificate bind, and how long is it valid?
answer
- keyless is not key-free
- the key is made and thrown away
- identity comes from a login token
- issuer recorded next to the subject
- minutes, not months
basics
~20 sA Fulcio certificate binds a one-time public key, generated locally at signing time, to the OIDC identity and issuer in the token you presented. It stays valid for roughly ten minutes, so no signing key is ever stored.
solid answer
~50 sKeyless signing is not key-free; it is key-ephemeral. The client generates a fresh keypair in memory, gets an OIDC token proving who or what it is, and sends the public key plus proof of possession to Fulcio. Fulcio validates the token against an issuer it trusts and mints a short-lived X.509 certificate — on the order of ten minutes — whose subject alternative name carries the identity from the token and whose extensions record the issuer that asserted it. The client signs the artifact digest with the private key and then discards it. The certificate answers exactly one question: **who vouched for this signature**. It says nothing about what is inside the artifact or how it was built — those are an SBOM's and a provenance attestation's jobs. And because any account at a supported issuer can obtain one, holding a Fulcio certificate is not itself an authorisation.
go deeper
Be ready to say plainly what keyless means: a throwaway keypair, an identity token, a certificate that lasts minutes, and no key left on disk afterwards.
Expect to walk the exchange step by step, including proof of possession and why the issuer is stored alongside the identity rather than assumed.
Show you can place the certificate correctly among the other artifacts — who signed, versus what is inside, versus how it was built — and resist claiming it proves more than it does.
Own the argument for why removing key custody is worth adopting an external identity dependency, and what that dependency means for teams that must sign during an identity-provider outage.
## The problem keyless signing is solving Classic artifact signing gives a team a long-lived private key. That key has to be generated, stored somewhere a build can reach, backed up, rotated, and revoked when it leaks — and a key a CI job can read is a key an attacker who reaches that CI job can read. Worse, a signature made with it proves only that *the key* was used, not who used it, so a leaked key is indistinguishable from a legitimate release for as long as nobody notices. Sigstore's keyless flow removes the stored key entirely, and Fulcio is the piece that makes that possible: it is a certificate authority that issues **short-lived code-signing certificates bound to an OIDC identity**. ## What actually happens at signing time 1. The signing client generates a brand-new keypair **in memory**. It has never existed before and will not exist afterwards. 2. The client obtains an OpenID Connect (OIDC) identity token. For a person this is an interactive browser login against an identity provider; for a CI job it is the token the platform mints for the running job. 3. The client sends Fulcio the ephemeral **public** key together with a proof of possession — it signs a value derived from the token's subject with the matching private key — so Fulcio knows the requester actually holds the private half. 4. Fulcio validates the token: is it signed by an issuer this Fulcio trusts, is it unexpired, is the audience right. It does **not** decide whether this identity *should* be signing anything; that judgement belongs to whoever verifies later. 5. Fulcio issues an X.509 certificate valid for roughly ten minutes, containing: - the **identity** from the token, in a subject alternative name — an email address for a human, a URI describing the pipeline for a workload; - the **OIDC issuer** that asserted that identity, in a dedicated Sigstore-defined certificate extension; - for workload identities, further extensions recording context the CI platform supplied, such as the source repository, the ref, and the build configuration. 6. The client signs the artifact's digest, records the signing event in the transparency log, and throws the private key away. The whole exchange takes seconds. The certificate outliving it by a few minutes is slack, not a design goal. ## Why the issuer is part of the identity An email address on its own is not an identity — it is a string that several identity providers might assert about different humans. `[email protected]` asserted by a corporate identity provider and the same string asserted by some consumer login are two different subjects. That is why the issuer is recorded in the certificate as a first-class field: an identity in Sigstore is always the **pair** (subject, issuer), and any verification worth the name pins both. ## What the certificate does and does not say Get the direction of the three supply-chain artifacts right, because mixing them up is the canonical wrong answer in this domain: | Artifact | Question it answers | | --- | --- | | SBOM | What is **inside** this artifact | | Provenance attestation | **How** this artifact came to be | | Signature + Fulcio certificate | **Who** vouches for it | A Fulcio certificate is purely the third column. It carries no claim about dependencies, no claim about build hardening, no claim about quality. It also carries no *permission*: anyone with an account at a supported issuer can get a certificate in their own name any time they like, so "the signature chains to Fulcio" is not a meaningful check on its own — the identity in the certificate is what a consumer has to care about. ## The private key is genuinely gone Because the key existed only for the duration of one signing operation, there is nothing left for an attacker to steal after the fact, nothing to rotate on a schedule, and no revocation list to run. That is the real payoff of the design, and it is why the ten-minute window is a feature rather than an omission. Expiry is also not the same as invalidation: an old signature still verifies because the signing event was recorded in the transparency log when it happened, so the log — not the certificate — is what carries the evidence of *when*. ## Common first misunderstanding People hear "keyless" and conclude that no cryptographic key is involved, or that Sigstore holds a key on their behalf. Neither is true. There is a real private key, the signer holds it exclusively, and it lives for seconds. The certificate is what lets a stranger later connect that throwaway key to a human or a pipeline that an identity provider was willing to name.
- If the private key is discarded, how can anyone verify the signature later?Verification never needs the private key — only the public key, which travels inside the certificate attached to the signature. The verifier checks the signature against that public key, then checks who the certificate says the key belonged to. The private half is only ever needed to create a signature, never to check one.
- Does a Fulcio certificate tell a consumer that the artifact is safe to run?No. It identifies the signer and nothing else. Whether the artifact is safe depends on what is inside it and how it was built, which are an SBOM's and a provenance attestation's territory, plus the consumer's own policy about which signer identities they are willing to accept.
- Why does Fulcio require proof of possession of the private key?Without it, anyone who intercepted or replayed a valid OIDC token could ask Fulcio to certify a public key they control, producing a certificate in someone else's name. Signing a token-derived value with the matching private key proves the requester actually holds the key being certified.
It is like a conference badge printed at the door: the desk checks your ID, prints a badge good for the day, and you hand it back on the way out. Nobody keeps a permanent badge that could be stolen.
saying these in an interview costs you the question
- Says keyless signing means no cryptographic key exists
- Thinks Sigstore stores a private key for you
- Claims the certificate proves the artifact is safe
- Believes the certificate contains the artifact's digest as its subject
- Treats any Fulcio-issued certificate as authorisation to publish