Fulcio is Sigstore's free code signing certificate authority. It takes an OpenID Connect identity token and a public key, checks both, and issues an X.509 certificate valid for 10 minutes that ties that key to that identity, so signers do not need to keep long lived signing keys.
Why does code signing need a different CA?
A web CA proves control of a domain. A code signing CA has to prove who signed an artifact. Traditionally that meant a developer held a long lived private key, protected it, rotated it, and distributed the public half. Keys leaked, were lost or were never rotated. Sigstore's overview describes the alternative: keyless, or ephemeral key signing, where verifiers rely on the transparency log rather than a long lived key.
Fulcio is the part that binds an identity to a short lived key. The Sigstore documentation states Fulcio was designed to run as a centralized public good instance, auditable by a certificate transparency log, and that it can also be self hosted.
How does issuance work, step by step?
Sigstore's documentation walks through the process in seven steps.
- Request. The client sends an OIDC identity token (a signed JWT naming the principal and the issuer, such as Google, Microsoft or GitHub), its public key, and a signed challenge proving it holds the matching private key. A certificate signing request can replace the key and challenge.
- Authentication. Fulcio uses the token's issuer claim to find that issuer's discovery endpoint, downloads the issuer's signing keys and verifies the token's signature.
- Challenge check. Fulcio verifies the signature over the token's subject using the submitted public key.
- Construction. The certificate embeds the public key, sets its subject alternative name from the token's subject, which can be an email, a SPIFFE ID or a GitHub Actions workflow identity, records the issuer, and adds extensions from token claims such as workflow information.
- Signing. The CA signs the certificate, forming a chain to its root. Fulcio supports backends including cloud KMS, PKCS#11 devices and Google CA Service.
- Transparency log. A precertificate is appended to an immutable, append only certificate transparency log, which returns a Signed Certificate Timestamp that is embedded in the final certificate.
- Return. The client receives the certificate and the timestamp.
How does this fit with Cosign and Rekor?
Sigstore's overview describes three roles. An artifact is signed by a client such as Cosign, associated with an identity through Fulcio, and witnessed by a record in the Rekor transparency log. The private key is discarded after a single signing, and Sigstore services never obtain it. The documentation notes that Fulcio's log stores only issued certificates, while Rekor stores artifact signatures and attestations. They are separate logs.
When someone verifies, the client checks the artifact's signature against the certificate's public key, checks that the identity in the certificate matches the identity they expect, checks the certificate chain against Sigstore's root of trust, and checks proof of inclusion in Rekor.
What can go wrong?
Fulcio proves that an identity provider vouched for a subject at a moment in time. It does not prove the code is good. If a CI workflow is compromised, it can obtain a valid certificate for its own identity and sign malicious output. So verification must pin the identity you expect, such as a specific repository and workflow, not only that a signature exists.
Identity providers are also trusted. Treat the set of accepted issuers as a policy decision and keep it short.
A constructed example
A project builds releases in a hosted CI workflow and signs images with Cosign. Fulcio issues a certificate naming the workflow identity. Consumers configure their verification step to require the repository and workflow name, and to reject anything signed by an email identity. An attacker who steals a maintainer's laptop gets no reusable signing key, because none exists, and cannot produce a valid signature for the workflow identity.
How to check or apply this
- Decide which identities may sign each artifact type: people, or CI workflows.
- Sign in CI using workload identity rather than a stored key.
- Write verification policies that name the exact identity and issuer you accept.
- Verify at deploy time, not only at publish time.
- Monitor the transparency logs for your identities.
- Decide whether you need a public instance or a self hosted one, and plan the root of trust accordingly.
- Keep a record of which artifacts have signatures and which do not.
Quick check
How long is a Fulcio certificate valid?
The Sigstore documentation says Fulcio signs certificates valid for 10 minutes. Verification relies on logs showing it was valid when the signing happened.
Does a valid Sigstore signature mean the software is safe?
No. It shows who signed it and that it was unchanged afterward. It does not show the code is free of flaws or that the signing workflow was uncompromised.
Sources
Last reviewed: 18 October 2026.
