Digital signatures

Blockchain for PDF Documents

You've paid a digital invoice of your supplier, and afterwards it seemed to be fake - you were a victim of invoicing fraud. These issues and many more can now be solved by Blockchain. This eBook focuses on how you can use Blockchain in combination with PDFs to write applications.

We all know blockchain because it's the technology used by Bitcoin in the context of cryptocurrency. "Virtual money" or "Digital currency" is only one application of Distributed Ledger Technology (DLT). At iText, we've developed a series of patents that describe mechanisms:

  • to automate document workflow and version management,

  • to ensure document integrity, authentication, and non-repudiation,

  • to provide long-term validation, and

  • to manage document identification and retrieval.

You may already have read our RefCard on DZone, entitled Blockchain and Distributed Ledger Technology for Documents. Or you've seen the article on Forbes explaining the rationale of our Blockchain efforts: Can Blockchain Solve Your Document And Digital Signature Headaches? This Forbes article was inspired by an OracleOne talk by Joris Schellekens. The patents were filed on December 22, 2016. They were already granted in Belgium, and they are now pending internationally (ETA: June 2019). We've also created an iText add-on pdfChain that is released on github.

We've been evangelizing these mechanisms at events such as:

In the next handful of articles, we'll take a closer look at specific topics related to Blockchain and documents.

E-book cover image
eBook cover Blockchain for PDF Documents
Main image
iText 7 and UWP

Digital Signatures in a Universal Application (UWP) with iText - reblog

Recently we found Paul Madary's blog post about digital signatures in files in a UWP app with iText, and we wanted to share it. Paul gracefully agreed to let us do that, and as a bonus we upgraded the code to be usable out-of-the-box with iText 7.1.3. The only change needed is the method SignDocumentSignature.

What does it take to make electronic signatures legally binding?

In the United States, the main law governing electronic signatures is the Electronic Signatures in Global and National Commerce (ESIGN) act of 2000. There is also the Uniform Electronic Transactions Act (UETA), which has been adopted by 47 states. Those laws require the following criteria to be met to make an electronic signature legally binding:

  • Intent to sign

  • Consent to do business electronically

    • Received UETA Consumer Consent Disclosures

    • Affirmatively agreed to use electronic records for the transaction

    • Has not withdrawn such consent

  • Association of signature with the record

    • System used to capture the transaction must keep an associated record that reflects the process by which the signature was created or generate a textual or graphic statement (which is added to the signed record) proving that it was executed with an electronic signature.

  • Record retention

    • Electronic signature records be capable of retention and accurate reproduction for reference by all parties or persons entitled to retain the contract or record.

  • Opt-out clause

  • Signed copy of fully executed agreement

Electronic signatures and digital there a difference?

In a word, YES! Although the terms are often used interchangeably, there is a difference between an electronic and digital signature.

Electronic Signature

It is the equivalent of a hand-written signature. It can be a client typing their name in a text box, checking an “I accept” checkbox, or some other process that records a person’s agreement to be bound by a contract. In the past, contracts would need to be printed out, signed, and stored. This could take days/weeks; but, with electronic signatures, it can be completed in minutes.

Digital Signature

It is more like having a notary public stamp a document assuring that the signatures are valid and that the document hasn’t been tampered with. Simply put, the electronic signature captures the person’s intent to enter into the agreement, and the digital signature is used to secure the data and verify the authenticity of the signed document.

Tell me more about a digital signature!

Digital signatures are typically used in Adobe PDF documents by individuals and organizations to prove who verified the document on a specific date/time and that the document hasn’t been modified since being signed.

Based on the requirements and work flow associated with signing a contract, there can be one or more signatures on a single PDF document. The actual digital signature is a section of non-visible, hashed & encrypted metadata embedded in the document using a certificate. In addition to the actual digital signature, an optional visible representation of the signature can also be included in the PDF document. The visible portion of the signature can include an image of the signature and/or a description of the signing certificate.

signature example

digital signature properties

What type of certificate do I need?

Depending on your needs, there are varying certificate options available:

Self-signed Certificate

They’re free to create and work to sign PDF documents. They’re great for testing, but they are the least secure option. If they are ever compromised, they can’t be revoked – which could potentially invalidate all contracts signed with the certificate.

Client Certificate

For about $10 per year, a certificate authority (CA) such as DigiCert, GlobalSign, etc. can issue a certificate used for signing PDF documents. The upsides of this solution are that they’re cheap, the certificate is issued by a trusted CA, and it can be revoked if it ever gets compromised. The downsides of this option are that client certificates aren’t included in Adobe’s Approved Trust List (AATL) so the PDF document would display a default warning in Adobe, and (since client certificates have fewer security requirements compared to AATL certificates) they are less secure.

AATL Certificate

This is the most secure option, but because of the added security and certification requirements imposed by Adobe, it can cost thousands of dollars per year (pricing is typically based on the number of signatures needed). For our project, costs for this solution were estimated between $4,000 - $13,000 per year. It requires 2-factor authentication via a hardware key per device, a Hardware Security Device (HSM), or a cloud-based solution. Some AATL solutions offer a new certificate per signature which would facilitate a unique certificate per signer.

Note: If you need to sign a document directly in Adobe, MS Word, or other similar application, the AATL certificate is the only solution available. Finally, this is the only option that will show up as a valid & trusted signature in Adobe by default.

aalt certifcate

So, I’ve heard of another topic called Long Term Validation (LTV). What is it?

Say you need to store the signed contract for years or decades but are concerned that the signature may become invalid if the certificate expires, is revoked, or (worse yet) the CA goes out of business. Any of these scenarios, which are external to the signed document, put the validity of the contract in jeopardy. This is where Long Term Validation comes in. LTV adds an extra section to the digital signature that includes a timestamp from a trusted Timestamp Authority and the status of the certificate at the time of signing. By adding an LTV section, everything needed to verify the certificate and signature which were valid at the time the contract was signed is self-contained within the PDF document and have no external dependencies that may change over time.

Let’s get into the details starting with the workflow….

In our specific case,

  1. A client comes into the business and signs an agreement for a year of service.

  2. We use a tablet device running a custom UWP application to first populate the agreement with the specific terms of the contract for the client (name, price, service plan, etc.). Then we display the filled-in PDF document on the screen for the client to review.

  3. Once the client reviews the document, they are given the option to either print the agreement and hand-sign it manually or electronically sign the document on the tablet.

  4. If they choose to electronically sign the document, a “Capture Signature” screen is displayed where the client can sign their name and choose whether they want a copy of the signed contract emailed to them and/or have a physical copy of the contract printed.

  5. When they click the “Yes, I Agree” button, the PDF contract is digitally signed, a copy of the contract is saved in the database with additional details related to the document, and then the contract is emailed and/or printed based on what the client selected when signing the contract.

Long term validation signature

Can I see some code?

You bet!

  • On the UI, I used an InkCanvas control to capture the client’s signature: <InkCanvas x:Name="signatureInkCanvas" Height="125" Width="750" />

  • In the code, the InkCanvas gets initialized in the constructor:inkcanvas code

  • Add a check to make sure the client has made at least some sort of signature before clicking the “Yes, I Agree” button:inkpresenter code

  • And finally capture the image:client signature button codeink canvas bitmapink canvas byte array code

  • In the SaveClientSignature method, that’s where the digital signature magic happens. First, we fill in the PDF document with the name, price, service plan, etc., and then flatten and save the PDF to a file [not shown]. After we have the flattened PDF, we apply the signature using the SignDocumentDigitalSignature method below:

    private async Task SignDocumentSignature(string filePath, AgreementElectronicSignatureParametersDTO agreementParameters, ElectronicSignatureInfoDTO signatureInfo)
        if (agreementParameters != null && signatureInfo != null)
            //Maintain the same ratio as the height/width of the client's signature image
            const int signatureHeight = 25;
            const int signatureWidth = 150;
            string clientSignaturePath = string.Concat(filePath.Replace(".pdf", "_ClientSignature.jpg"));
            string filePathSigned = string.Concat(filePath.Replace(".pdf", "_Signed.pdf"));
                PdfReader pdfReader = new PdfReader(filePath);
                PdfSigner pdfSigner = new PdfSigner(pdfReader, new FileStream(filePathSigned, FileMode.Create), false);
                IExternalSignature pks = GetPrivateKeySignature();         
                Org.BouncyCastle.X509.X509Certificate[] chain = GetCertificateChain();
                OCSPVerifier ocspVerifier = new OCSPVerifier(null, null);
                OcspClientBouncyCastle ocspClient = new OcspClientBouncyCastle(ocspVerifier);
                CrlClientOnline crlClient = new CrlClientOnline();
                TSAClientBouncyCastle tsa = new TSAClientBouncyCastle(GetTimeStampAuthorityURL());
                //Show image of the client's signature on the pdf
                SaveBase64AsImage(clientSignaturePath, agreementParameters.ClientSignature);
                ImageData clientSignatureImage = ImageDataFactory.Create(clientSignaturePath);
                PdfSignatureAppearance signatureAppearance = pdfSigner.GetSignatureAppearance();
                signatureAppearance.SetPageRect(new Rectangle(signatureInfo.Left, signatureInfo.Bottom,
                    signatureWidth, signatureHeight));
                pdfSigner.SignDetached(pks, chain, (new List<ICrlClient>() {crlClient}), ocspClient, tsa, 0,
                // Replace the original agreement with the signed version
                File.Copy(filePathSigned, filePath);
                //Remove signature images if it exists
                if (!String.IsNullOrEmpty(clientSignaturePath) && File.Exists(clientSignaturePath))

    key vault client codesignature code

    And there you have it: an electronically and digitally signed document.

Where to Learn More

What makes an electronic signature legally binding:

Article type
Technical notes

Digital transformation to paperless

With companies and organizations caught up in the next wave of digital transformation, we offer a closer look at how PDF may overcome the traditional roadblocks on the way there and how it helps meet the goals of forward-thinking business strategies.

Get the eBook "Digital Signatures for PDF Documents"

Learn all you need to know about digital signatures, making the right technology decisions and implementing a future-proof PDF solution.  

Get a complete overview of PDF features, industry standards and technology options with regards to digital signature, as well as in-depth best practices, real-life examples and code samples for PDF development.


  • Understanding digital signatures
  • PDF and digital signatures
  • Certificate authorities, certificate revocation and time stamping
  • Options for signing documents externally
  • Validation of signed documents

Sign your PDFs with iText
About the eBook
A comprehensive guide to PDF and digital signatures
eBook cover Sign your PDFs with iText
eBook - free copy
Campaign Details

How does it work?

  • Fill out the form on the right.
  • On the thank you page you will get a direct link to our online book page.
  • You will receive an e-mail with a link to download the free PDF or EPUB version on LeanPub.
Campaign Embed form

Get your free copy

Digital signatures for PDF Documents

The main rationale for PDF used to be viewing and printing documents in a reliable way. The technology was conceived with the goal “to provide a collection of utilities, applications, and system software so that a corporation can effectively capture documents from any application, send electronic versions of these documents anywhere, and view and print these documents on any machines.” (Warnock, 1991) 

Why we need PDF

This mission was set forth in the Camelot paper, and it was accomplished with the first publication of the Portable Document Format Reference (Adobe, 1993) and the availability of the first PDF software products created by Adobe. PDF became renowned as the format that could be trusted to ensure a consistent output, be it on screen or in print. 

In the years that followed, an abundance of new tools from Adobe as well as from third party software vendors emerged, and the PDF specification was —and still is— very much alive. Plenty of functionality has been added to the PDF format over the years. Because of this, PDF has become the preferred document format of choice in many professional sectors and industries.

In this paper we’ll focus on one specific aspect of PDF files that makes the choice for PDF over any other document format a no-brainer: digital signatures.

  Why we need digital signatures

Imagine a document that has legal value. Such a document may contain important information about rights and obligations, in which case you need to ensure its authenticity. You don’t want people to deny the commitments they’ve written down. Furthermore, this document probably has to be mailed to, viewed and stored by different parties. On different places in the workflow, at different moments in time, the document can be altered, be it voluntary, for instance to add an extra signature, involuntary, for example due to a transmission error, or deliberately, if somebody wants to create a forgery from the original document. 

For centuries, we’ve tried to solve this problem by putting a so-called ‘wet ink signature’ on paper. Nowadays, we can use digital signatures to ensure: 

  • the integrity of the document— we want assurance that the document hasn’t been changed somewhere in the workflow,
  • the authenticity of the document— we want assurance that the author of the document is who we think it is (and not somebody else),
  • non-repudiation— we want assurance that the author can’t deny his or her authorship. 

In this paper, we’ll focus on documents in the portable document format (PDF). 

E-book cover image
Digital signatures for PDF documents

Are PDF Signatures shattered?

Last week there was a huge buzz surrounding SHA-1. The hashing algorithm has been deemed unsafe for many years, but is still used in outdated software for digital signatures. Recently a team of researchers was able to break SHA-1, proving definitively that the algorithim should be replaced . The attack was orchestrated on a PDF file that contained an image, which they exploited to generate a collision. A collision can be quite scary as it allows an attacker to generate two files that have the same digest value. If a victim was to sign one of these files using SHA-1, the signed digest would be applicable to both documents. This means that you could validate both documents using the same signature and would appear as if the victim signed both documents and not just theirs.

How does this affect PDF and iText? What can you do to protect your digital signatures?

Does this mean that PDF is an unsafe format?

No. The issue here is that SHA-1 has been broken, not PDF. The PDF specification explicitly allows for different hashing algorithms to be used, like the more secure SHA-256 or SHA-512. Additionally, SHA-1 has been officially deprecated since 2011 by the NIST and it has been deemed unsafe to use as early as 2005. Developers and businesses who deal with digital signatures and security know this and (should) have moved on years ago. Anyone still using SHA-1 should immediately upgrade to a more secure algorithm.

Furthermore in 2009, the PAdES standard mentioned that "The use of SHA-1 is being phased out in some countries and hence the use of other hashing algorithms is recommended". We have been warning developers using the LGPL-MPL versions of iText (dating from 2009) for many years that they shouldn't use some of the signature types that we knew would be deprecated in the PDF 2.0 specification — the long-awaited ISO 32000-2. In PDF 2.0, SHA-1 will be formally deprecated. This means that a PDF 2.0 writer should not use SHA-1 anymore, and a PDF 2.0 reader can reject signatures that still use SHA-1.

Does this mean that PDFs that were signed using the SHA-1 algorithm in the past suddenly become invalid? In principle, it is now proven that the contents of a PDF can be changed without invalidating the signature, if that signature signed a message digest that was created with SHA-1.

Future proofing your signing processes

It's simple, stop using SHA-1 and start using another algorithm. You can also keep an eye out for news about that algorithm and cryptography in general. Unfortunately cryptography is an ever evolving industry and there is no definitive algorithm, so keeping yourself informed on the industry will keep your signed documents are secure and reliable.

How to fix existing SHA-1 signatures

Although it has been deprecated for almost 6 years now, I expect a lot of people still use SHA-1 when signing their documents. If you have a repository of PDF files that still rely on SHA-1, PAdES-4 allows you to add a Document Security Store (DSS) including Validation-Related Information (VRI), as well as a document time-stamp (DTS) signature.

This process adds an additional signature through a time-stamp. It doesn't replace the original, SHA-1 signature, but it adds a new one. It is important to use a different, more recent hashing algorithm to create this signature. This way you can change the original contents to fit the original SHA-1 signature, but the second signature will be broken because the hashing algorithm you used in the time-stamp signature isn't SHA-1.

This procedure of adding a DSS and a document time-stamp should be repeated before the certificate of the last signature that was added expires, or when there are indications that the algorithms that were used, be it the cryptograph hash function or the encryption algorithm, could be jeopardized.

Our free e-book on digital signatures in PDF describes how to add a DSS to a signed document. You can download the e-book here.


This attack doesn't change much for the PDF specification. PDF already anticipated that SHA-1 would have been broken as we can see in PAdES (2009) and PDF 2.0 (2017). We advise you to double check your PDF signatures and to apply a DSS when you've used SHA-1.

Article type
Technical notes

What is the connection between LTV and document timestamps?

How do I make a PDF document LTV enabled without using timestamps?

What does "Not LTV-enabled" mean?

Since my signature was declared valid at a known and certified date, why would it become invalid in the future?

How to enable LTV for a timestamp signature?

Acrobat tells me my signature is LTV enabled, but the timestamp signature is not. How can I make both LTV enabled?

How can I create a Reader enabled PDF with a signature field that can be signed in Adobe Reader

I've read that I need to Reader enable my document, but I can't find how to do this using iText.

Still have questions? 

We're happy to answer your questions. Reach out to us and we'll get back to you shortly.

Contact us
Stay updated

Join 11,000+ subscribers and become an iText PDF expert by staying up to date with our new products, updates, tips, technical solutions and happenings.

Subscribe Now