Security
What the seal covers, and why that is the whole point.
A signing service is asking you to trust a record it produced about itself. The only way out of that circle is to make the record checkable by arithmetic rather than by reputation.
Step one: the document gets a fingerprint
When signing completes, the finished file is run through SHA-256, a cryptographic hash. The result is a short fixed-length value that behaves like a fingerprint for those exact bytes: change a comma, change a pixel, re-save the file, and the fingerprint changes completely.
That fingerprint is stored inside the seal. This is what distinguishes a seal that covers a document from a record that merely mentions one.
Step two: the seal is signed with a private key
The sealed record — the document fingerprint, the certificate fingerprint, each signer’s entry, and the time — is signed using Ed25519, a public-key signature scheme.
The property that matters: verifying the signature requires only the public key. It is a calculation anyone can perform. It is not a question we answer about ourselves, and it is not a row in a database we control and could quietly change.
You can try that on a real document. Check a signed document takes the reference printed on the certificate and re-computes the signature in front of you. You do not need an account, and you do not have to be a party to the agreement.
What a completed seal contains
- document_sha256
- Fingerprint of the document as it was sent for signature.
- signed_document_sha256
- Fingerprint of the finished file, with every signature rendered into it.
- certificate_sha256
- Fingerprint of the certificate of completion, binding the evidence to the document.
- signature entries
- One per signer: who they were, how they signed, that they consented to sign electronically, and a fingerprint of any answers they gave.
- seal signature
- The Ed25519 signature over all of the above.
Step three: the certificate records what happened
Alongside the signed document, CoreSign produces a certificate of completion: a readable account of the signing. When it was created and sent, when each signer verified their identity, when they read the document and how many of its pages were shown to them, when they consented, when they signed, and any answers they gave beside the question they were asked. A signer cannot sign until every page has been shown to them.
It also states what did not happen. If a step was never recorded, the certificate prints the gap rather than omitting the line. A record that silently drops what it lacks is not evidence — it is a summary, and the difference only becomes visible when someone is relying on it.
Who can open what
A signing link authorises one person, for one document. It is not a shared password and it is not a link that works for whoever forwards it onwards.
The document being signed is served only to the person holding a valid signing authorisation for it, and is returned with caching switched off — a document under signature should not remain in a shared cache after the authorisation that opened it has been used.
Requests for a document that does not exist and requests for one you are not authorised to see return the identical response. That is deliberate: a service that answers differently in the two cases lets an outsider discover which documents exist by asking.
For account holders, two-step sign-in is available. Turn it on and, after your password, you confirm it is you with a code from an authenticator app or with a passkey. A passkey needs your fingerprint, face or device PIN, and works only on sign.coresignapp.com, so a look-alike page cannot use it. The first one you turn on comes with recovery codes, for when a device is lost.
What a document cannot carry
A PDF can carry more than its pages — scripts, attached files, embedded media, and actions that open other programs or send form data elsewhere — and a signed copy downloaded afterwards would carry them too. So a PDF containing any of these is refused when it is uploaded, along with XFA forms, links into attached files, and password-protected PDFs, whose contents cannot be checked. It is refused rather than quietly altered: the sender is told why, and can upload a clean copy.
What we do not claim yet
A security page is the page a careful reader checks hardest, so it is the worst possible place to round up.
- The verifier is ours, and that is not the same as independent. A checker you can run yourself is published, its source reads in a browser, and the public verification key is fetchable without an account. The arithmetic is open, and the two files that do the checking are byte-identical to the code that produces the seal.
But you are fetching that tool from CoreSign. That is a smaller thing to trust than our verdict on our own document, and it is not nothing — so we still do not describe verification as independent of us. What you can do instead of trusting the tool is read it: three short files, around 14 KB, plain text in a browser. - We hold no third-party security certification. CoreSign has not been audited against SOC 2, ISO 27001 or any comparable standard, and we will not imply otherwise by decorating this page with badges.
- We publish no uptime guarantee. A service level we have not measured over time is a number, not a commitment.
Reporting a security problem
If you believe you have found a vulnerability, write to coresign.support@corelegacystudios.com with enough detail to reproduce it. We will confirm receipt, and we will not pursue anyone who reports a genuine issue in good faith and gives us a reasonable opportunity to fix it before publishing.
Please do not test against documents belonging to other people. If you need something to test against, ask us and we will set one up.
Signing something and want to understand your side of it? Read the signer’s guide.