[Bug]:TestBootstrapClientServerRotation: certificate has expired or is not yet valid: current time 2026-06-15T15:55:08Z is after 2026-06-15T15:55:08Z

[jas4711]

Steps to Reproduce

Build and run tests. Is this a race condition perhaps? It doesn't seem to always happen.

Your Environment

• OS - Debian GNU/Linux trixie
• step-ca Version - 0.30.2

Expected Behavior

PASS

Actual Behavior

414s === RUN   TestBootstrapClientServerRotation
414s 2026/06/15 15:54:52 Building new tls configuration using step-ca x509 Signer Interface
414s 2026/06/15 15:54:52 Serving HTTPS on 127.0.0.1:33803 ...
414s 2026/06/15 15:54:59 Building new tls configuration using step-ca x509 Signer Interface
414s 2026/06/15 15:55:00 Serving HTTPS on 127.0.0.1:33803 ...
414s 2026/06/15 15:55:05 Building new tls configuration using step-ca x509 Signer Interface
414s 2026/06/15 15:55:05 Serving HTTPS on 127.0.0.1:33803 ...
414s 2026/06/15 15:55:08 http: TLS handshake error from 127.0.0.1:56786: tls: failed to verify certificate: x509: certificate has expired or is not yet valid: current time 2026-06-15T15:55:08Z is after 2026-06-15T15:55:08Z
414s     bootstrap_test.go:496: Test with rotate-ca-2.json failed: client.Get(https://127.0.0.1:38309) failed: Get "https://127.0.0.1:38309": remote error: tls: expired certificate
414s 2026/06/15 15:55:13 Building new tls configuration using step-ca x509 Signer Interface
414s 2026/06/15 15:55:13 Serving HTTPS on 127.0.0.1:33803 ...
414s --- FAIL: TestBootstrapClientServerRotation (21.55s)

Additional Context

Complete build log: https://ci.debian.net/packages/g/golang-github-smallstep-certificates/testing/ppc64el/72117800/#L9335

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[lechedesnatada23]

Hi! Thank you for reporting this, and sorry you ran into it.

I'd like to take a stab at fixing it. From a first look at TestBootstrapClientServerRotation: the test issues certificates with a 5s lifetime (defaultTLSCertDuration in ca/testdata/rotate-ca-*.json), and TLSRenewer schedules each renewal at ~2/3 of the certificate's lifetime (see #873), which leaves only ~1-2s of margin between a renewal and the expiry of the certificate in use. On a slow or loaded machine a scheduling stall longer than that means the next mTLS handshake presents an already-expired certificate; since /renew requires a valid client certificate, the client cannot recover and the test fails. That matches your log: the handshake at 15:55:08 hit a certificate that had just expired at 15:55:08.

The approach I'd like to try (test-only, no production behavior changes): increase the test certificates' lifetime (e.g. 5s → 15s) and scale the renewal waits accordingly, so the margin before expiry grows to a few seconds and slow CIs get some headroom. I'll validate with repeated runs, including under CPU load, before opening a PR.

Would that approach be okay with the maintainers? Thank you!

(Note: I'm using AI tooling to assist with this contribution.)

[jas4711]

Thanks for analyzing the code to find the cause. I would prefer a solution that avoids the race condition, it seems that is the real bug and not what the actual timeout settings are.

[lechedesnatada23]

Thanks @jas4711, I agree the race is the underlying problem. Two notes on what it concretely is, since it's sharper than just tight timeouts:

• With 5s certificates, TLSRenewer schedules each renewal at notAfter - renewBefore - jitter, which leaves only ~1.7–2.9s between the scheduled renewal and the expiry of the certificate in use. On a loaded machine (like Debian's CI runners), a stall longer than that means the next mTLS handshake presents an already-expired certificate.
• Once expired, the client can never recover: /renew requires a valid client certificate, and the bootstrap token can't be used to re-sign a fresh one because OTTs are protected against reuse (Authority.UseToken → db.UseToken). This unrecoverable state is documented as a known issue in TLSRenewer.getCertificate and is tracked more broadly in Stabilize TLSRenewal on special cases #873.

Avoiding the race at the root would therefore mean changing behavior — for example, accepting recently-expired client certificates on /renew within a grace window, or defining a proper re-bootstrap path. Both are server/client behavior changes that look like a design decision for the maintainers rather than something to land in a drive-by PR. And within the test itself, any rotation check necessarily races expiry, because the renewal timing is internal to the renewer.

That's the rationale behind #2787: it widens the test's margin so the test stops failing on slow machines, while the production-side sharp edge stays tracked in #873. If the maintainers would rather fix the root cause first, I'm glad to close the PR in favor of that work, or to help with a grace-window design if that direction gets a 👍.