What is a digital signature?

The mechanics, without the algebra

Hashing reduces a file of any size to a fixed string, and changing anything at all produces a completely different string. Signing encrypts that string with a private key that only the signer holds. Verification runs the same hash over the file you have, decrypts the signed value with the public key from the certificate, and compares. Two outcomes are possible: they match, in which case this file is byte for byte the file that was signed, or they differ, in which case something changed and the reader says so. There is no third state where the signature is probably fine.

Certificates are the weak joint

The maths is not usually where trust breaks down. A certificate says a key belongs to a named person or organisation, and that claim is only as good as the checks the issuer performed before signing it. A self signed certificate asserts identity with nothing behind it. A certificate from a commercial authority means somebody verified a company registration. A qualified certificate under European rules means a supervised provider checked an identity to a defined standard. Readers show this difference plainly: a valid signature from an unknown issuer still reports that the identity could not be confirmed.

Where it sits inside a PDF

The signature is stored in the file itself, under a signature dictionary, with the certificate and a hash of the byte ranges it covers. That structure is standardised, which is why any reader can check it without contacting the software that produced it. A certified signature adds a permission entry that says what may be done to the document afterwards, and at the strictest level any change at all invalidates it. Because the signature covers the bytes, anything appended later has to be appended before certification rather than after, which is a small constraint with large consequences for how a signing pipeline is ordered.

Where people get it wrong

Assuming a green tick means the person is who they claim, when it may only mean the file is intact. Assuming the date shown is proven, when without a timestamp token it came from the signer's own clock. Assuming a digital signature is required for a contract to bind, when the statutes ask for intent rather than cryptography. And assuming that a signature applied to page one covers pages that were swapped in afterwards, which it does, so the swap shows up as a broken signature rather than as a quietly altered document.

How the signed copy here is produced

Once every signer has finished, the completed PDF is signed as PAdES CMS from a P12 certificate and certified with DocMDP at permission level one, recorded as PAdES-SHA256-DocMDP. Nothing may be changed afterwards without breaking it, so where a certificate of completion is appended to the document, that append happens first. Timestamping is built and available but the timestamp authority address is empty in the deployed configuration, so signed files currently carry no RFC 3161 token and the recorded algorithm string says so.

Reading the signature panel in a viewer

Any full featured PDF reader will show a signature panel, and it repays a look. It reports whether the document has been modified since signing, who the certificate says signed it, whether the issuer is trusted on that machine, and whether a timestamp is present. Those are four separate findings and a reader collapses them into one icon, which is where confusion starts. A green tick usually means intact and trusted; a warning triangle often means intact but the issuer is unknown; a red cross means the bytes no longer match. The panel also lists the certificate chain and its validity dates, and it will tell you whether revocation was checked. None of this requires special software or an account, which is the practical advantage of a signature that lives inside the file: the person receiving it can verify it without asking the sender anything.

Questions people ask