Companion note · not a headline feature

In-house RFC 3161 timestamp server.

Every CodeB tenant ships with an in-house RFC 3161 Time Stamp Authority endpoint at /csc/v2/signatures/tsa. Post a DER TimeStampReq, get a DER TimeStampResp back — signed by a per-tenant responder certificate the platform mints for you on first use. This exists as a companion to the external TSA proxy at /csc/v2/signatures/timestamp, which forwards to a public TSA (Sectigo by default). Both are Advanced Electronic Signature scope. Neither is eIDAS-qualified.

Scope disclosure. The in-house TSA cert is self-signed by the tenant — it is not a qualified TSA per ETSI EN 319 421, and the tokens it issues are not qualified electronic timestamps under Regulation (EU) 910/2014 Article 41. Use them the same way you would any RFC 3161 token from an internal enterprise TSA: to fix a Time-of-Existence proof inside PAdES-B-T / B-LT / B-LTA envelopes for internal or contractually-bound audit trails.

Two TSA options — pick per deployment.

External TSA proxy

POST /csc/v2/signatures/timestamp

  • Forwards to whatever TSA URL is set in HKLM\SOFTWARE\CodeB\TSAURL.
  • Default when the registry value is empty: http://timestamp.sectigo.com/qualified.
  • Wrapped in a JSON request/response envelope with the base64 token — convenient for the browser signer.
  • Trust chain follows the upstream TSA (widely-recognised commercial roots).

In-house TSA issuer

POST /csc/v2/signatures/tsa

  • Answers with a full DER TimeStampResp, signed by the tenant's own TSA responder cert.
  • Auto-generates the responder cert on first request — no operator setup needed.
  • Keeps the whole trust chain in-tenant — useful for air-gapped or sovereign deployments.
  • Not qualified. Relying parties need the tenant's TSA cert in their trust list.

POST /csc/v2/signatures/tsa Open #

Full RFC 3161 wire protocol. No Bearer required — RFC 3161 §1.4 documents TSAs as typically-open services. Host-level rate limits still apply.

Request

Content-Type: application/timestamp-query
Body:            DER-encoded TimeStampReq
                 (INTEGER version, MessageImprint {AlgorithmIdentifier hashAlgo, OCTET STRING hashedMessage},
                  OBJECT IDENTIFIER reqPolicy OPTIONAL,
                  INTEGER nonce OPTIONAL,
                  BOOLEAN certReq DEFAULT FALSE,
                  Extensions extensions OPTIONAL)

Response

Content-Type: application/timestamp-reply
Body:            DER-encoded TimeStampResp
                 (PKIStatusInfo status, TimeStampToken timeStampToken OPTIONAL)

On success the PKIStatus is 0 (granted). The TimeStampToken is a full CMS SignedData whose eContent carries the TSTInfo structure (version, policy, MessageImprint echo, INTEGER serial, GeneralizedTime genTime, nonce echo).

Supported hash algorithms

  • 2.16.840.1.101.3.4.2.1 — SHA-256 (32 bytes)
  • 2.16.840.1.101.3.4.2.2 — SHA-384 (48 bytes)
  • 2.16.840.1.101.3.4.2.3 — SHA-512 (64 bytes)

Other algorithms are rejected with PKIStatus=2 (rejection), failInfo=0 (badAlg).

Error responses (RFC 3161 §2.4.2)

  • failInfo = 0 (badAlg) — unsupported hash algorithm OID.
  • failInfo = 5 (badDataFormat) — body missing, unparseable, or MessageImprint hash length wrong for the declared algorithm.
  • failInfo = 25 (systemFailure) — the tenant's TSA credential could not be loaded or the serial counter is unavailable.

Example

openssl ts -query -data document.pdf -sha256 -no_nonce -out req.tsq
curl -H "Content-Type: application/timestamp-query" \
     --data-binary @req.tsq \
     https://phone.aloaha.com/csc/v2/signatures/tsa \
     -o resp.tsr
openssl ts -reply -in resp.tsr -text

TSA responder certificate #

The certificate that signs every TimeStampToken issued by this endpoint. Auto-generated on the first request (no operator step needed) and persisted at App_Data/<tenant>/tsa-cert/tsa.pfx. The private key is wrapped by DPAPI at LocalMachine scope, so restoring the folder to a different host will not re-open the key.

Certificate profile

  • Subject DN: CN=<tenant> TSA Responder, O=Aloaha Limited, C=MT
  • Key algorithm: EC P-256 (id-ecPublicKey, curve secp256r1)
  • Signature: ECDSA with SHA-256 (1.2.840.10045.4.3.2)
  • Validity: 5 years from generation
  • Extension: ExtendedKeyUsage critical, values id-kp-timeStamping only. Per RFC 3161 §2.3, EKU MUST be present, MUST be critical, MUST contain only id-kp-timeStamping.
  • Extension: KeyUsage critical, values digitalSignature + nonRepudiation.
  • Extension: BasicConstraints critical, CA:FALSE.
  • Extension: SubjectKeyIdentifier (SHA-1 of the SubjectPublicKeyInfo).

Serial counter

Every issued token gets a fresh monotonically-increasing INTEGER serial. The counter lives at App_Data/<tenant>/tsa-cert/serial.counter (ASCII decimal, incremented under a file lock). Values are the TSTInfo.serialNumber that goes into the token — not the responder cert serial.

Auto-regeneration

The credential loader checks NotAfter > UtcNow on every request. When the responder cert is within 30 days of expiry or already expired, a replacement PFX is generated and the counter continues (existing tokens issued under the old cert remain verifiable until relying parties drop the old cert from their trust list).

Operating notes #

Retrieving the responder cert

The public responder cert (base64 DER) is served under the tenant's /csc/v2/credentials/info when credentialID is set to the tenant TSA slug — the same mechanism used for signer credentials. Relying parties add it to their PDF Reader / TSA trust list once, and every subsequent token from that tenant validates.

Nonce and policy handling

When the request carries a nonce INTEGER, the TSTInfo echoes it back verbatim (RFC 3161 §2.4.2 replay protection). Absent, the token is deterministic w.r.t. the same MessageImprint. The policy OID emitted in TSTInfo.policy is a private OID that documents the "best-effort accuracy, self-signed responder" profile of this in-house TSA — it deliberately does not clash with any eIDAS-qualified policy OID.

Rate limiting + observability

The endpoint sits behind the same per-IP bucket as the rest of /csc.ashx (30 requests per minute per action). Every issuance emits a [METRIC] csc.tsa.issued log line; every rejection emits [METRIC] csc.tsa.rejected reason=<badAlg|badDataFormat|cred|parse|body_empty|crash>. Traces carry the tenant slug, hash algorithm, hash prefix (8 bytes hex), nonce prefix, and the assigned TSTInfo serial.

When to reach for which endpoint

  • Internal audit trails, air-gapped tenants, sovereign deployments → in-house TSA. The trust chain never leaves your infrastructure.
  • Documents that will be validated by third parties who trust commercial roots → the external TSA proxy (Sectigo default, or point the registry at any TSA you have a relationship with).
  • You want the timestamp inside a PAdES-B-T PDF assembled by the browser → the external TSA proxy is what sign.html reaches for — it returns a base64 token in a small JSON envelope.
  • You want to plug a standard RFC 3161 client (OpenSSL, digiseal, pyHanko) at a TSA URL → point it at the in-house endpoint. It speaks the wire protocol directly.

Standards + citations #

  • RFC 3161 — Time-Stamp Protocol. Wire format for TimeStampReq, TimeStampResp, TimeStampToken, TSTInfo, and the PKIStatusInfo / PKIFailureInfo failure codes above.
  • RFC 5816 — ESSCertIDv2 update to the RFC 3161 signing-certificate reference.
  • RFC 5652 — Cryptographic Message Syntax (the CMS SignedData that wraps the TSTInfo).
  • RFC 5280 — Internet X.509 PKI Profile (KeyUsage, EKU, BasicConstraints handling on the responder cert).
  • ETSI EN 319 421 — Policy and security requirements for TSAs. Referenced for scope-boundary clarity: this in-house TSA is not compliant with this standard, because that would require an accredited Trust Service Provider and a supervised responder key.
  • ETSI EN 319 422 — TSA profiles and protocols.
  • Regulation (EU) 910/2014 — Articles 41 (electronic timestamps) and 42 (qualified electronic timestamps). Tokens from this endpoint fall under Art. 41 — admissible as evidence, but not enjoying the presumption of accuracy that qualified timestamps carry.
Related on this site: CSC v2 API · External TSA proxy · Browser signer · All public APIs

Questions? Ask us.

Frequently asked questions

What is the CodeB in-house RFC 3161 timestamp server?

The CodeB in-house timestamp server is an RFC 3161 Time Stamp Authority endpoint that ships with every CodeB tenant at POST /csc/v2/signatures/tsa. You post a DER TimeStampReq and receive a DER TimeStampResp signed by a per-tenant responder certificate that the platform generates automatically on first use. It is a companion to the external TSA proxy at /csc/v2/signatures/timestamp.

Are timestamps from the CodeB in-house TSA eIDAS-qualified?

No. The CodeB in-house TSA certificate is self-signed by the tenant, so it is not a qualified TSA per ETSI EN 319 421, and its tokens are not qualified electronic timestamps under Regulation (EU) 910/2014. They fall under Article 41: admissible as evidence, but without the presumption of accuracy that qualified timestamps carry.

When should I use the in-house TSA instead of the external TSA proxy?

Use the CodeB in-house TSA for internal audit trails, air-gapped tenants and sovereign deployments where the trust chain must stay in your infrastructure, or when you want to point a standard RFC 3161 client such as OpenSSL or pyHanko at a TSA URL. Use the external TSA proxy, which forwards to Sectigo by default, for documents that third parties will validate against commercial roots; the browser signer sign.html also uses the proxy.

Which hash algorithms does the CodeB in-house TSA accept?

The CodeB in-house TSA accepts SHA-256, SHA-384 and SHA-512 message imprints. Any other hash algorithm is rejected with PKIStatus 2 (rejection) and failInfo badAlg.

Does the CodeB in-house TSA require authentication?

No. The CodeB in-house TSA requires no Bearer token, because RFC 3161 describes TSAs as typically open services. Host-level rate limits still apply: the same per-IP bucket as the rest of /csc.ashx, 30 requests per minute per action.

How do relying parties validate tokens from the CodeB in-house TSA?

Relying parties add the tenant's TSA responder certificate to their PDF reader or TSA trust list once, and every later token from that tenant then validates. The public responder certificate is served via /csc/v2/credentials/info when credentialID is set to the tenant TSA slug.

What is in the CodeB TSA responder certificate and what happens when it expires?

The CodeB TSA responder certificate uses an EC P-256 key with ECDSA-SHA-256, is valid for 5 years, and carries a critical ExtendedKeyUsage of id-kp-timeStamping only, a critical KeyUsage of digitalSignature and nonRepudiation, and CA:FALSE. When the certificate is within 30 days of expiry or expired, a replacement is generated automatically and the serial counter continues. Tokens issued under the old certificate remain verifiable while relying parties keep the old certificate in their trust list.

How can I test the CodeB in-house TSA with OpenSSL?

Create a request with openssl ts -query -data document.pdf -sha256 -no_nonce -out req.tsq, then POST it with curl using Content-Type application/timestamp-query to https://phone.aloaha.com/csc/v2/signatures/tsa and save the reply as resp.tsr. Inspect the result with openssl ts -reply -in resp.tsr -text.