The same signature verified fine on my laptop and came back invalid on the server. Same document, same key, same code path.
This was an e-signature service built to national digital-signature standards, with the document workflow in Go. The verification step did something that looked fine in review: it rebuilt the PDF from the template plus the stored form data, hashed the result, and compared that hash against the one sealed in the signature.
Locally the rebuilt bytes matched every time. On the server they didn't. The host had a different font available, the renderer fell back, one line of a table wrapped a millimetre differently, and the byte stream changed. The hash changed with it. So a document nobody had touched since signing was now reported as tampered.
The fix was cheap. The expensive part was the two days I spent staring at keys, clock skew and encoding, because the error said "invalid signature" and an invalid signature is supposed to mean something serious. And what I then had to go explain was worse than a bug: for a while, whether a legally binding document was valid depended on which machine asked.
What I changed: the signed artifact is bytes, not a recipe. At signing time the rendered document gets stored once, immutably, and that stored object is the only thing verification ever reads. I treat generation as non-deterministic by default, because it is: fonts, library versions, locale, image codecs, timestamps all leak in.
The general shape of it: "works on my machine" usually means the machine is an input you never declared. In document pipelines that input gets baked into something you later have to prove in front of someone.
So the question I now ask early on any pipeline that produces an artifact of record: can this artifact be produced twice? And if yes, which copy is the truth?
I write up more of these document and payment pipeline failures here: https://polycratia.com/c/3367aff6
Somewhere in your system something still gets regenerated when it should have been stored...