Signer should handle ExpiredCertificate?

[jku]

I was reviewing sign.py and noticed that

• we cache Fulcio certificate by default
• we don't try to renew the certificate when it expires, just raise ExpiredCertificate

It would probably be harmless and good UX to renew the cert in Signer (if OIDC token is still alive). This would obviously only apply to some processes where hundreds of artifacts are being signed.

I'll run some tests before actually proposing anything but I'm filing this already so I don't forget

[jku]

This might not be that useful since

• dex tokens are short lived (shorter than fulcio cert)
• CI OIDC tokens are probably likely short lived

[woodruffw]

Yeah, I think that's why we didn't do it originally 🙂 -- in practice the OIDC cred itself expires when/before the cached signing cert does, so the signer API would need to go through the (potentially interactive) OIDC retrieval flow again.

[jku]

I just checked and I believe the GCP workload token has a 60 minute expiry

• so theoretically the fulcio cert expires earlier (10 mins)
• that's still a lot of signing time even with rekor2 so fixing this is not that important

The minor improvement this would make is that users who do massive signing operations would only need to handle ExpiredIdentity: ExpiredCertificate would be handled internally.

[davidbrochart]

I'm not sure it's related, but I get an error trying to publish to PyPI using https://github.com/pypa/gh-action-pypi-publish:

  Traceback (most recent call last):
    File "/root/.local/lib/python3.13/site-packages/pypi_attestations/_impl.py", line 207, in sign
      bundle = signer.sign_dsse(stmt)
    File "/root/.local/lib/python3.13/site-packages/sigstore/sign.py", line 208, in sign_dsse
      cert = self._signing_cert()
    File "/root/.local/lib/python3.13/site-packages/sigstore/sign.py", line 125, in _signing_cert
      raise ExpiredIdentity
  sigstore.oidc.ExpiredIdentity
  During handling of the above exception, another exception occurred:
  Traceback (most recent call last):
    File "/app/attestations.py", line 152, in <module>
      main()
      ~~~~^^
    File "/app/attestations.py", line 148, in main
      attest_dist(dist_path, attestation_path, signer)
      ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    File "/app/attestations.py", line 115, in attest_dist
      attestation = Attestation.sign(signer, dist)
    File "/root/.local/lib/python3.13/site-packages/pypi_attestations/_impl.py", line 209, in sign
      raise AttestationError(str(e))
  pypi_attestations._impl.AttestationError

Do you know what can go wrong?

[woodruffw]

I believe that's unrelated. The underlying error there is:

    File "/root/.local/lib/python3.13/site-packages/pypi_attestations/_impl.py", line 207, in sign
      bundle = signer.sign_dsse(stmt)
    File "/root/.local/lib/python3.13/site-packages/sigstore/sign.py", line 208, in sign_dsse
      cert = self._signing_cert()
    File "/root/.local/lib/python3.13/site-packages/sigstore/sign.py", line 125, in _signing_cert
      raise ExpiredIdentity

That suggests that your OIDC token expired before you actually used it to request a signing certificate. Are you doing some kind of long-running publish or build step? That should really only happen if your step takes more than 15 minutes.

[davidbrochart]

Indeed the publish step can be longer than 15 minutes because there are quite a lot of wheels. Do you know what would be my options then?

[facutuesca]

I think the problem is related to this, but in a different way. When calling _signing_cert():

sigstore-python/sigstore/sign.py

Lines 154 to 164 in 8b26c92

	# Our CSR cannot possibly succeed if our underlying identity token
	# is expired.
	if not self._identity_token.in_validity_period():
	raise ExpiredIdentity
	# If it exists, verify if the current certificate is expired
	if self.__cached_signing_certificate:
	not_valid_after = self.__cached_signing_certificate.not_valid_after_utc
	if datetime.now(timezone.utc) > not_valid_after:
	raise ExpiredCertificate
	return self.__cached_signing_certificate

we check if the OIDC token is expired before trying to return a (valid) cached certificate. But since OIDC tokens can expire before certificates, this means that we could still have a valid certificate but we fail anyway if the OIDC token expired first.

I think this is what's happening in pypa/gh-action-pypi-publish#415: the signing process fails because it takes more than 5 minutes, and GitHub's OIDC token expiration time is 5 mins:

We still have a valid certificate to sign with, but we fail early because GH's OIDC token expired.

I think the solution here would be to try to return a valid cached cert first, and if that fails continue with the check if the OIDC token is still valid.

WDYT? @woodruffw @jku

[woodruffw]

Huh, did GitHub shorten their OIDC lifetime? I could have sworn it was 10-15 minutes before, 5 minutes feels awfully short.

Returning the cached cert seems reasonable to me, though, I think.

[miketheman]

Huh, did GitHub shorten their OIDC lifetime? I could have sworn it was 10-15 minutes before, 5 minutes feels awfully short.

Returning the cached cert seems reasonable to me, though, I think.

Docs example timestamps iat and exp are 5 minutes apart.

I just ran a test and got:

...
"iat": 1784900124,
"nbf": 1784899824,
"exp": 1784900424,
...

corresponding to what I understand to be is:

• issued at: Fri Jul 24 09:35:24 EDT 2026
• not before: Fri Jul 24 09:30:24 EDT 2026
• expires at: Fri Jul 24 09:40:24 EDT 2026

So it looks like there's now a 5-minute window, which matches the failure of the job timing at ~5m8s

[miketheman]

Looks like this isn't new, either, circa H12025:

• Document that the OIDC token expires in 5min google-github-actions/auth#483
• https://github.com/orgs/community/discussions/190629
• Request for an OIDC token with expiry of > 5 mins actions/toolkit#2048
• https://github.com/orgs/community/discussions/160973

[facutuesca]

The problem I think is that even if we use the cached certificate, once signing is finished the upload would still fail, since the token exchange with warehouse would fail because GH's token is already expired, no?
nvm I see that we exchange the token with warehouse before starting to sign artifacts: src