E-signatures · Glossary
What is a certificate of completion?
A certificate of completion is a PDF built at the end of a signing that summarises what happened. It carries the envelope details and hashes, one block per signer with their identity check, signing time, IP address and consent record, and the full event log in order. It is the document you hand over when somebody asks you to prove the signing.
Nobody reads a certificate of completion until there is an argument. At that point it is the only thing in the file that answers who, when and how, in one place, in a form a third party can read.
Nuwan Madhusanka · Co-founder
5 min read · Published · Updated
Three sections, in order
The envelope section carries the envelope id, when it was sent and completed, how many signers there were, the certification algorithm, and two document hashes: the document hash as sent and the fully signed hash. The signers section gives one block per person: which identity check they passed, when they signed, from which IP address, when and against which version they accepted the consent, the document hash at their moment of signing, and a hash of their signature image. The event log then lists every event with its sequence number, UTC timestamp, label and the signer's email.
What the hashes are, and what they are not
The document hash as sent is the file that was uploaded. The fully signed hash is the stamped file carrying every signature, taken before the certification seal is applied. Neither is a checksum of the completed PDF you download, because certification writes a signature into the file after that second hash is taken. Hashing your download and comparing it with either number will show a mismatch even when nothing is wrong, so that is not a test to run. What the hashes do is tie the record to specific states of the document held by the provider: each signer's block adds the hash at the moment they signed, so every signature sits against a known version. To check that the download itself is intact, open it in a PDF reader, which reports whether the certified document has changed since it was certified.
A separate file, and optionally appended
Every completed envelope gets the certificate as its own PDF, offered as a separate download beside the signed document. A checkbox in the prepare panel, off by default, also appends the certificate's pages to the end of the signed PDF. That append happens before certification, because the finished file is certified at DocMDP level 1, the strictest permission level, which forbids any change afterwards, including adding a page. If a process adds a certificate after certification, the seal is broken or was never applied. Tick the box when the other side wants one file; leave it off when the signed document should stay exactly as drafted.
What the page looks like
The certificate is an A4 PDF. Timestamps print in UTC as YYYY-MM-DD HH:MM:SS UTC, so signers in different time zones sit on one clock. Every page carries a hairline rule with Certificate of completion bottom left and Page n of N bottom right, and a two signer envelope with an ordinary event log fits on a single page. The verification line in each signer block reads Email link, Email link + access code, or Email link + emailed one time code. The certification row reads PAdES-SHA256-DocMDP; it would add with RFC 3161 timestamp only when a timestamp authority is configured, and none currently is, so no trusted timestamp is attached.
Common mistakes
Treating either envelope hash as a checksum of the download, covered above. Adding the certificate pages later with a PDF editor, which breaks the certification. Sending only the signed PDF to somebody who needs the evidence, when the separate certificate is what answers who, when and how. Reading an IP address as proof of identity rather than a signal about where an action came from. Filing the two files apart with nothing to pair them; the envelope id printed on the certificate is the link. One quirk to expect: an in person signing appears in the event log under its raw event name, in_person_started, rather than a readable label.
Questions people ask
Do I need the certificate if I have the signed PDF?
The signed PDF proves the file has not changed. The certificate proves the process around it: who was challenged, who authenticated, from where, and in what order. Most disputes are about the process rather than the file, so keeping both is the sensible default and costs nothing.
Does it show the document contents?
No, and deliberately. It carries hashes of the document rather than its text, so the certificate can be shared with somebody who should see the evidence of signing without seeing the commercial terms. The hash is enough to prove which document it refers to.
What is the consent version for?
Electronic signing regimes generally require the signer to be told they are signing electronically and to agree to it. Recording which version of that wording they accepted, and when, is what lets you answer the challenge that they never agreed to sign electronically at all.
Why does it record an IP address?
Because it is the only routine signal about where an action came from. It is not proof of identity and should never be presented as such, but two signatures from the same address, or a signature from an unexpected country, are the sort of thing a challenge turns on.
Can the certificate be forged?
On its own, a PDF is a PDF, and anybody can type one up. What makes a copied or edited certificate hard to use is that its hashes have to match the document states the provider stores, and its event log has to match the chained audit trail behind it, which is checked link by link. A certificate that contradicts either is evidence of tampering, not of signing.
Why does the certificate print times in UTC?
Because signers are often in different time zones, and a log mixing local times invites the wrong reading of who acted first. Printing every event as a UTC timestamp puts the whole signing on one clock. Converting to local time is a job for whoever reads it, and the sequence number beside each event settles order even when two times look close.
Make one with e-signatures
The button opens the generator with this use case already described. Change the wording to match your own.
Send a document for signingRelated questions
- What is an audit trail in e-signature?What is an audit trail in e-signature? The time ordered record of when a document was sent, who opened it, how signers were verified and who signed.
- What is PAdES?PAdES is the ETSI standard for digital signatures embedded in a PDF. What it adds over a plain signature, its levels, and how to spot one in a reader.
- Access code against one time codeAn access code is a shared secret you send the signer yourself. A one time code is emailed at signing time and expires. When each is the right check.
- Initials against a signatureA signature signs the agreement. Initials mark that a specific page or clause was seen. When to ask for each, and when initials are theatre.
Step by step in the builder: Send a PDF for e-signature.
Written and checked by the OneCraft team. Last checked .