checkId: check.timestamp.tsa.valid-response plugin: stellaops.doctor.timestamping severity: fail tags: [timestamping, tsa, validation, rfc3161]

TSA Valid Response

This Stella Ops Doctor check proves that every active timestamping authority (TSA) actually returns a well-formed RFC 3161 timestamp token, not just an HTTP response. It is a critical-severity gate for platform operators: a TSA that is reachable but returns malformed tokens is more dangerous than no TSA at all, because it stamps release evidence that looks valid until someone tries to verify it.

What It Checks

Verifies that TSA endpoints return valid RFC 3161 timestamp responses. The check:

Why It Matters

A reachable TSA that returns invalid timestamps is worse than no TSA at all — it produces evidence that appears valid but cannot be verified. Invalid timestamps break the chain of trust for release evidence and can cause compliance audit failures. This is a critical-severity check.

Common Causes

How to Fix

Docker Compose

Verify TSA configuration and switch to a known-good provider:

environment:
  Timestamping__TsaEndpoints__0__Name: "DigiCert"
  Timestamping__TsaEndpoints__0__Url: "http://timestamp.digicert.com"

Bare Metal / systemd

# Test TSA response manually with openssl
openssl ts -query -data /dev/null -sha256 -cert -no_nonce -out /tmp/ts.req
curl -H "Content-Type: application/timestamp-query" --data-binary @/tmp/ts.req \
  http://timestamp.digicert.com -o /tmp/ts.resp
openssl ts -reply -in /tmp/ts.resp -text

Kubernetes / Helm

timestamping:
  tsaEndpoints:
    - name: "DigiCert"
      url: "http://timestamp.digicert.com"

If a TSA consistently returns invalid responses, remove it and add an alternative qualified provider.

Verification

stella doctor run --check check.timestamp.tsa.valid-response