Signing a PDF is the easy part. The work is everything the signature has to survive: a certificate that can still be checked years later, a timestamp from someone who is not us, revocation data captured at the moment of signing, and an answer to what happens when two people sign the same document in the same second. Signum is four years of that, mostly on the failure modes.

Bring your own PKI

Most signing platforms make you sign with their certificates from their authority. For anyone who already runs a CA — and in regulated European industries, plenty do — that is a second trust hierarchy to reconcile with the one they already audit. So certificate issuance, revocation and status checking sit behind a provider interface, and the trust anchors, revocation endpoints and timestamp authority are all configuration rather than code. A deployment can be pointed at a customer’s existing hierarchy; ours is the default, not the requirement.

One provider implementation ships — the internal EJBCA CA. The interface exists so a second one is a class, not a rewrite
Trust anchors, CRL and OCSP endpoints and the RFC 3161 timestamp authority are all deployment configuration
The same seam is the route to a qualified trust provider later, which is a commercial decision rather than an engineering one

Advanced, not qualified — and why saying so matters

Signum produces advanced electronic signatures under eIDAS. It does not produce qualified ones, and on a private CA it cannot: qualified requires a certificate from a trust service provider on an EU Trusted List, a key in certified hardware, and a qualified timestamp. That word is legally reserved, and claiming it is not marketing licence — it is a misrepresentation a regulator or a competitor can act on, and it is precisely the claim that enterprise legal teams check first. The honest version is a better sales position anyway: advanced signatures cover the overwhelming majority of business signing, and the buyers who genuinely need qualified know they do.

Signature construction and validation run on the EU’s own DSS library, so output verifies in the EU’s own validator rather than only in ours
Revocation data and a timestamp are embedded at signing time, so a signature stays checkable after its certificate expires

The trust anchor in the wrong list

The validation library skips revocation checking for anything it treats as a trust anchor. That is correct behaviour and it is also a trap: put the intermediate CA in the trusted list rather than the adjunct one and you get signatures that validate perfectly while quietly carrying no revocation data — which is the entire thing long-term validation exists to provide. Root in trusted, intermediate in adjunct, plus fallback revocation endpoints for the case where the URL baked into a certificate no longer resolves.

Two people signing the same document at once

A parallel envelope lets every recipient sign whenever they like, which means two signing requests can arrive against one file milliseconds apart. Each envelope takes its own lock with a bounded wait — a caller that cannot acquire it gets a 503 rather than a corrupted document — and the file is re-read inside the lock, so the second signer signs the first signer’s output instead of the original.

Stamping form fields rewrites the whole PDF and destroys any signature already in it, so the signing engine refuses outright when it sees existing signatures rather than trusting its caller to have ordered the steps correctly
If field values cannot be stamped, signing is refused: the alternative is a valid signature over a document missing its own content, which cannot be corrected afterwards

A revocation result that looked like a bug for two months

Revoke a certificate as compromised, backdate the compromise to before a document was signed, and that document still validates as passed. That looked wrong, and it went through the CA configuration and the revocation publishing before the real answer surfaced: the validation model is point-in-time, the signature was valid when it was made, and reporting otherwise would have been the defect. The change was to the wording of the validation report, not to the behaviour.

Instrumented because a signing platform has to explain itself

Every service publishes metrics, traces and structured logs into a Prometheus, Grafana, Tempo and Loki stack. The signing path reports an outcome and a reason at each of its exit points — a closed set of reasons, deliberately, because the human-readable message interpolates certificate status and would have produced unbounded label cardinality. The timestamp and revocation sources are wrapped so a failure is counted and still propagates: a swallowed timestamp failure turns a hard failure into a signature that quietly is not what it claims to be.

First real measurement contradicted the assumptions: one library call accounted for 75% of signing time, and the CRL fallback path had never once been exercised

The pitch is bring-your-own-PKI: organisations that already run a certificate authority should not have to adopt someone else’s to get signing. That shaped the architecture rather than the other way round — certificate issuance, revocation and status sit behind a provider interface, and the trust anchors and timestamp authority are configuration. If you are building your own signature stack, I am the supplier here, not the competitor.