What is a SignNow Digital Certificate
Every document completed through a SignNow signature request is sealed with a digital certificate upon download. The certificate is issued by DigiCert — a public Certificate Authority recognized by Adobe Reader out of the box — and it is applied to the final PDF by airSlate Inc., SignNow's parent company. From the moment the last recipient signs, the completed document carries cryptographic proof of two things: that it was finalized by SignNow, and that nothing in it has changed since.
The certificate itself is invisible on the page. It does not print as a stamp, a badge, or a watermark; it lives inside the PDF's signature dictionary and is read by PDF viewers. In Adobe Reader, it shows up as a blue certification bar at the top of the document that reads "Certified by airSlate Inc., Engineering Operations, certificate issued by DigiCert Assured ID G2 Multi Doc Signing RSA4096 SHA384 2023 CA1. Signed and all signatures are valid." The Signature Panel opens the certificate details.
A few things the digital certificate is not, and that are easy to confuse with it:
It is not the signer's personal certificate. It attests that the document came from SignNow and has not been altered since completion. Who each recipient is, when they signed, and from which device is proven by the Certificate of Completion and the audit trail.
It is not the visible "Signed by [name], [date]" stamp inside the signature field. That stamp is a visible mark on the page. The digital certificate is cryptographic proof inside the file.
It is not a Qualified Electronic Signature (QES). Under eIDAS it is an Advanced Electronic Seal (Article 36). It is admissible as evidence across the EU, but it is not legally equivalent to a handwritten signature on its own.
Technically, the signature is PAdES-compliant (CAdES-based, PAdES BASELINE-LTA) with Long-Term Validation data embedded: OCSP responses and CRLs are included in the file so the signature stays verifiable after the signing certificate expires. An RFC 3161 archive timestamp is added when a Time Stamp Authority is available.
What the digital certificate affects
The digital certificate changes what someone sees when they open the completed PDF, not how the document is signed or routed. Three parts of the experience are affected.
The completed PDF itself. The certificate is embedded in the file, so the proof travels with the document wherever it goes — to a recipient's inbox, into a shared drive, to a lawyer, to a bank. It is not stored on SignNow's side after download, and the recipient does not need to come back to SignNow to verify anything.
How PDF viewers display the document. AATL-aware readers — Adobe Acrobat and Adobe Reader — show a blue certification bar at the top of the document and a green check in the Signature Panel. Older viewers, browser PDF plugins (Chrome, Edge, Safari preview), and third-party readers such as Nitro each validate against their own trust store; what they show depends on that store. Section "External validators and the trust list" below covers what to do when the viewer does not include DigiCert by default.
Content lock after completion. The seal is applied to the final PDF with a document hash. Any change to the file after completion — adding a comment, filling in a field, re-saving in an editor, OCR-ing the file — will be shown in Adobe Reader as the document version updates. The signature panel then reports the document as modified. This is intended behavior: the certificate's job is to expose any change.
What the certificate does not change
It does not affect the look of the signed page, the signing experience for recipients, the Certificate of Completion, or the audit trail. The Certificate of Completion is still generated for every signature request and still contains signer identity, IP, device, timestamps, and the full event chain. The digital certificate on the PDF and the Certificate of Completion complement each other: the certificate proves the file is intact; the Certificate of Completion proves who signed it.
Why the digital certificate is needed
Before SignNow added the digital certificate, a completed signature request came back as a plain PDF. Adobe Reader opened it with a red bar — "At least one signature has problems" or "Signer's identity is unknown" — and the only proof of the signatures lived in a separate Certificate of Completion. A counterparty received the file and the first thing they saw was a trust warning. The certificate replaces that warning with a validated trust statement anchored in a public Certificate Authority.
Three concrete problems it solves
Authenticity. The counterparty needs to know the document came from SignNow and not from a copy someone edited. The certificate chain anchors that proof in DigiCert, a public CA recognized by Adobe Reader and by most document workflows, so the trust statement does not depend on SignNow being reachable or trusted locally.
Integrity. Once the document is exported outside of SignNow after signing, the content of the document is fixed. If anyone edits it afterwards — on purpose or by accident — the certificate exposes the change.
Compliance and legal admissibility. Under eIDAS, the certificate qualifies as an Advanced Electronic Seal (Article 36), admissible as evidence in all 27 EU member states. Under the US ESIGN Act and UETA, a sealed PDF together with the Certificate of Completion is accepted as a signed record in the same way as paper. Regulated workflows (financial services, insurance, healthcare) rely on this kind of tamper-evident sealing as part of their recordkeeping.
In practical terms: a contract that reaches an outside lawyer, a lease that reaches a property manager, an offer letter that reaches HR, a signed form that reaches a bank or a school — any of these now opens with a trust statement rather than a warning, and travels with its own proof.
External validators and the trust list
SignNow's certificate is anchored in DigiCert, and DigiCert's roots are on the Adobe Approved Trust List (AATL). This means Adobe Acrobat and Adobe Reader validate SignNow-signed documents correctly out of the box, in any country, with nothing to install on the recipient's side.
External validators — PDF viewers other than Adobe, browser PDF plugins, and signature-validation tools that use their own trust list — may not include DigiCert's roots by default. For those tools, the recipient (or their IT team) needs to add the DigiCert certificates to the trust list.
If you use an external validator, you must add the DigiCert certificates to the trust list. Ensure you have added the DigiCert CA root certificate, as well as the intermediate and end-user certificates.
All three levels of the chain should be added:
The DigiCert CA root certificate. SignNow's chain currently anchors at DigiCert Assured ID Root G2. Thumbprint:
A14B48D943EE0A0E40904F3CE0A4C09193515D3F. Download: cacerts.digicert.com/DigiCertAssuredIDRootG2.crt.The intermediate certificate. The issuing CA that DigiCert uses for SignNow document-signing certificates is DigiCert Assured ID G2 Multi Doc Signing RSA4096 SHA384 2023 CA1. Validators that build the chain themselves fetch it from the signature's AIA extension; validators that need the intermediate loaded in advance should import it alongside the root.
The end-user (signing) certificate. Readers that do not fetch certificates from AIA need the signing certificate itself in their trust list.
Windows (Edge, Chrome, Nitro)
Edge, Chrome and other viewers on Windows use the system Trusted Root Certification Authorities store. DigiCert Assured ID Root G2 is a trusted public root, but Windows does not pre-install every trusted root on every machine. It is added on demand through the Microsoft automatic root update mechanism. A machine may be missing the root if automatic root updates are turned off, if the network is restricted or blocks Microsoft's trust servers, or if the computer was imaged from an older base.
To check whether the root is present, run this in PowerShell:
Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Thumbprint -eq "A14B48D943EE0A0E40904F3CE0A4C09193515D3F" }If the command returns nothing, download the root from the DigiCert link above and import it into Trusted Root Certification Authorities, either by hand or through Group Policy.
macOS and other platforms
Adobe Acrobat and Adobe Reader on macOS, Linux and Windows carry their own AATL-synced trust list, so DigiCert is trusted by default. Preview on macOS does not validate PDF signatures; opening a signed document there shows the content without any signature statement, which is not an invalidation.
Microsoft Edge on macOS uses its own trust logic rather than the system keychain. If a document validates in Adobe Reader on macOS but not in Edge, follow the same import step as on Windows, inside Edge's trust configuration.
What makes the certificate invalid by design
The whole point of the certificate is that it fails when the document is not what it was at completion. A few specific things make it report as invalid, and each of them is working as intended.
The document was edited after completion. Opening the sealed PDF in any editor — Adobe Acrobat with edit permissions, Microsoft Word, a third-party form-filler, a tool that re-saves the file — and saving it changes the bytes. The embedded hash no longer matches, and the Signature Panel reports "Document has been modified" or "At least one signature has problems". A re-flattened or OCR'd copy creates a new document entirely where the digital signature is not present.
Pages were added, removed, or rotated. Any structural change to the file — merging the sealed PDF with another document, extracting pages, rotating pages and saving — invalidates the seal.
Form fields were filled in after completion. SignNow's certification level locks content on completion. Filling in a new field after the file is sealed counts as a modification and breaks the signature.
The file was re-printed to PDF. Printing a sealed PDF to a new PDF (through "Save as PDF" or a virtual PDF printer) produces a new file that no longer carries the original signature. This is not a workaround for a validation warning — it strips the proof entirely.
The signing certificate was revoked. The certificate's status is checked against DigiCert's revocation lists. If the signing certificate has been revoked, the Signature Panel marks the signature as invalid. Long-Term Validation data embedded at signing time preserves the state at the moment of signing, so a signature stays verifiable after the certificate's natural expiration — but not after an explicit revocation.
Two situations that look like "invalid by design" and are not
The certificate chain cannot be built on the recipient's machine. The signature itself is valid; the recipient's reader cannot verify it. The fix is adding the DigiCert certificates to the trust list (see External validators above) or opening the document in Adobe Acrobat Reader.
The reader uses an older or restricted trust list. Same situation — the signature is intact, and the reader is the limitation. Browser PDF plugins and third-party viewers are the usual cause.
If a document shows invalid in Edge, Chrome or Nitro but valid in Adobe Reader, the signature is intact and the document has not been tampered with. The viewer is simply not using a trust list that includes DigiCert's roots.
Known limitations
There are a few situations where a SignNow-signed document shows as invalid even though the document is intact and the certificate itself is valid. These are environment issues, not tamper events.
Regular downloads signed with the older method. Until mid-October 2026, regular (non-NOM 151, non-QES) downloads were signed with an older signing method. Documents signed through QES and NOM 151 flows already used the newer method and are not affected.
Microsoft Edge 154 on Windows. Edge 154 (released September 24, 2026) enabled the PDFSecureMode policy by default on Windows. In this mode Edge's built-in PDF reader validates signatures against the Windows Trusted Root Certification Authorities store strictly. A document signed with the older method shows as "At least one signature has problems", "Document modified", or "Signer's certificate and its parent certificates can't be found in the certificate trust store" in Edge, Nitro and Chrome, while the same document opens as valid in Adobe Reader. This behavior comes from the viewer's validator; the document and the signature are intact. Microsoft confirmed on their side that the behavior change is expected and that UseSystemCertificateVerifier can be set to 1 on managed Windows machines to fall back to the Windows cert store.
Missing root certificate on Windows. On some Windows machines, DigiCert Assured ID Root G2 is missing from the Trusted Root Certification Authorities store. Microsoft confirmed that this root is a trusted public root but not pre-installed on every machine. It may be missing if automatic root updates are turned off, if the network blocks Microsoft's trust servers, or if the computer was imaged from an older base. Importing the root (see External validators above) resolves this on its own.