Digital Signature Support in InfoPath 2010

Hi, this is Gergely Kota, a developer on the InfoPath team. Digitally signing data when filling out a form makes the data tamper-proof, authenticates its signer, and is a key component of trusting form data. In this post, I’d like to share the improvements that have been made to digital signature support in InfoPath 2010. InfoPath 2010 allows you to make more secure signatures with improved cryptographic algorithms and makes long-term storage of signed forms more robust by supporting 3rd-party time stamping. This post describes these improvements and shows you how to strengthen any signature created in InfoPath 2010 Filler. For a primer on digital signatures, read an Introduction to Digital Signatures in InfoPath.

Note - Data signing should not be confused with code/template signing, which remains unchanged.

Signature Security

Digital signatures are only as secure as the cryptographic algorithms they use to ensure signed data hasn't been tampered with. InfoPath 2007 and 2003 support RSA or DSA for signing and SHA1 for hashing. Though a combination of RSA and SHA1 is considered secure for now, algorithms become exposed to attack over time and are eventually rendered obsolete. If either the signing or hashing algorithm is cracked or compromised, the integrity of the signature can no longer be verified. InfoPath 2010 enables you to address these concerns by supporting newer, more secure, ECC signing and SHA-2 family of hashing algorithms.

Signing with a particular algorithm

When creating a signature, a user may sign with one of potentially many certificates installed on their machine. The signature algorithm is determined by the chosen digital certificate. To determine the algorithm:

  1. Begin the signing process Clickhere to sign
  2. Change your signing certificate ChangeCert
  3. Highlight desired certificate and click View Certificate 
  4. Look at the Public key field under the Details tab Viewcert

Administrator Settings: Hashing algorithms

By default, InfoPath 2010 hashes signature data using SHA1. This is done to maintain backwards compatibility with InfoPath 2007 and InfoPath 2003. InfoPath 2010 also supports the SHA2 family of hashing algorithms. If backwards compatibility is not a concern, an administrator can set the hashing algorithm in the registry.

Value Description
“sha1” (default) SHA1 hash algorithm
“sha256” SHA256 hash algorithm
“sha384” SHA384 hash algorithm
“sha512” SHA512 hash algorithm

Signing and Hashing Algorithm Compatibility

The following table shows which versions of InfoPath are able to sign and/or verify signatures with the given combinations of signing and hashing algorithms:


Long-term Signature Support

Certificates guarantee the identity of the signer, but expire after a while. This is to reduce the time attackers have to deduce an associated private key (which would allow them to impersonate a signer) and to limit the shelf-life of a compromised certificate. Certificates may also be revoked if they are taken out of commission before their expiration date. If the certificate used to create a signature is now expired or revoked, we should be cautious of whether the signed data is valid or not unless we can verify that the data was signed while the certificate was still valid. This poses an impending problem because all certificates expire (often in a year!), and we would require a trusted timestamp to confirm when the signature was created. Without such a trusted timestamp, InfoPath will show the signature as invalid, with the reason in the Signature Details dialog:



This can be especially problematic, for example, for a printed copy of the form which would show an invalid signature, and there would be no way to verify why. InfoPath 2010 adds support for XML Advanced Electronic Signature (XAdES), which allows for adding a trusted timestamp that can be used to resolve when the signature was added relative to the signing certificate's expiration and/or revocation time (see a detailed discussion of XAdES in Microsoft Office for details and level options). If such a timestamp exists and confirms that the signature was made when the signing certificate was valid, InfoPath can safely conclude that the signature is entirely valid:



Server Support

InfoPath 2010 Forms Services signs forms using RSA and SHA1, and is able to verify any signature created in the InfoPath 2010 client. XAdES is a client-only feature.

Final Word

By leveraging the security improvements and time-stamping support described in this post, you are increasing the strength and longevity of your signatures. Happy signing!

Gergely, InfoPath dev

Comments (34)

  1. G M Liew says:

    Hi Gergely,

    Very useful post there. Would like to ask, how about browser forms that are uploaded to SharePoint? Is it still possible to sign?

  2. Gergely says:

    Signing is supported in the browser as well, however the enhancements for 2010 are for client only. Forms signed with other algorithms in the client and opened in the browser will be validated properly, but you can only apply a signature using RSA+SHA1 in the browser.

  3. G M Liew says:

    Thanks Gergely for your prompt response. Would you be able to point me to any guides or more details on dig sig in SharePoint browser forms (or maybe as one of your blog topic?)? Since CAPI is already not supported, we hope to find an updated solution. Thanks!

  4. Gergely says:

    We have a lab that covers creating a form template and signing it in a web browser:…/bb251748(office.12).aspx

    If you are looking to sign using signing/hashing algorithms other than RSA and SHA1, you have 2 options:

    1. you can open the same forms from SharePoint using InfoPath client, apply the signature and save the form back to SharePoint. When you open the same form in the future in the browser, these signatures will be properly validated.

    2. if you don't have InfoPath client, you could download the form from SharePoint, apply the signature using whatever solution you come up with, then upload the form back to SharePoint. As in [1], the signature will be validated when someone later opens the form in the browser as long as supported algorithms were used (see Signing and Hashing Algorithm Compatibility earlier in this post). However, you will need to exactly mimic the format of the signature applied by InfoPath.

  5. Nirav says:

    Hi Gergely,

    Your post is really a knowledge enhancer.

    I have developed an infopath 2010 form with some digital signature fields using optional section control. When I preview the form and click on "Click here to insert" it shows a pop up wherein I can select an image from my local drives. But the problem is when I publish the form and open in IE 8, and click on "Click here to insert" it does not give me an option to select image.

    Let me know if anybody is having any knowledge about this problem.

    I look forward to hearing from you.



  6. Gergely says:

    Signing with an inserted image is a client-only feature. IPFS is limited to text in the signature.

  7. Y H says:

    Hi Gergely,

    Very interesting post. I would like to ask, why do I have to click on <sign> twice in order to sign my form? The first click prompt me that the data has been tamper with. And only successfully digital sign upon the second click. However, I did not make any changes to any fields in the form.

  8. Rob Tribble says:

    I have two questions that I would love to have answered

    1. Attached documents, are they ecrypted also, or just the link to the document

    2. what does the digital signature do to the size of the signed document ?

  9. Gergely says:


    File attachments are included inline in Base64, so as long as they are part of your signed section, their content is included in the signed data.

    The signature data is dominated by the nonrepudiation image, which is a Base64 encoded png of your InfoPath window. In the worst case, this is a full-screen on a high resolution and in my experience runs 2-300 kbytes. The rest of the signature is a few kilobytes.


  10. Eduard Spelier says:

    Hi Gergely,

    Thanks for your post. I have a question that I hope you can help with. We've been using InfoPath 2007 forms with digital signatures for a while now. The forms are stored as XML in a Forms library but we've found that when we create a new form template and deploy that to the library or when we move the forms to a new library (which we need to do as part of our 2010 upgrade), all digital signatures are invalidated which is a big problem for compliance reasons. Is there a way that we can either:

    a) store all form data including the digital signature in a list so that we don't need a form per se to access the form data

    b) store the form in a read only type format (like .pdf or .xsf) so that we don't need a template to view the forms (for the auditors)

    I really appreciate your help.

    Thanks, Eduard

  11. Hi Gergely,

    I submitted this bug report about InfoPath 2010 custom digital signatures to site a while ago:…/infopath-2010-custom-digital-signature-support-not-working

    Is there any hope for getting a hotfix for this? Our customers are starting to migrate from IP 2007 to 2010, and the custom digital signature support not being all there is a bit of a problem for us.


  12. Philip says:

    Why is this digital certificate crap forced on us?  I can understand why it's needed in some cases, but I am just trying to use some infopath forms as an easy way to put data in databases so I can retrieve and work with the data within my 30 person organization.  I spend 100x the amount of time screwing around with the certificate crap than everyone uses the forms combined.  Certificate problems just popped up on the form and I've already spent 2 hours on trying to get the form to work, which so far I can't and I just don't have the time to waste on this crap.  Why can't simple options be available to us that don't need all this security?  I just want to be able to go and do my work, not fight with garbage programs.

  13. Gabriel says:

    An InfoPath template on Form Services opened and signed using the browser still shows me the "There is a problem with this signature" error… The certificate has expired but the time and date of the signature is valid.

    How come this verification is not working? Am I missing something. I have SharePoint 2010 Entreprise with InfoPath Form Services installed.

  14. Gergely says:

    Hi Gabriel,

    Your scenario is a fuzzy area of signature validation and InfoPath has chosen to go with the more strict version. The issue largely boils down to the fact that there is no trusted timestamp in the signature (which XAdES addresses, but only the client can apply, and the server does not validate). Since the timestamp can be trivially spoofed and the cert's expiration time has passed, there's "some chance" that an attacker has reverse-engineered the signer's private key and created a document to look like it has a valid signature.

  15. LogicWorm says:


    I am writing to get some help on the digital signatures used in InfoPath 2007. We have a local CA issuing certificates for users to digital sign browser enabled forms.

    The timestamp information etc. is all in place, but considered valid only until the certificate has not expired. Once expired, Infopath browser forms mark them as "There is a problem with this signature" and the pop-up window shows Expired Certificate.

    What can I do to resolve this issue since we have over 5000 forms signed and my boss is about to slit me apart!!

    I also tried the hotfix below, but it works only for the desktop environment. The browser enabled forms still show an error:…/980206

    Is there something I can do!! Please help me out.



  16. Scott Heim says:

    Hi LogicWorm,

    Take a look at this Knowledge Base article:

    Description of the Office Forms Server 2007 hotfix package (ifswfe-x-none.msp): December 14, 2010…/2466315

    This is the equivalent fix to the one you mentioned but this is for the server.


  17. Gabriel says:

    So, if the client signs a browser-enabled form using Internet Explorer, the timestamp is not trusted? Why?

    If XAdES is client side, then why does Internet Explorer not implement this?

    I do not understand. What will happen to all the forms already signed? The signatures cannot be trusted and will fail to pass an audit?

    Can you advise me in what I should do now with over 500 signed forms that have a fuzzy timestamp?


  18. Gabriel –

    The timestamp is not trusted because the consumer of the signature has no guarantee about where that value came from. The untrusted timestamp is taken from the signing machine's system clock which can be set by the signer at will.

    The client in this case is the InfoPath client application (infopath.exe). The implementation of all the XAdES timestamping exists in the Office client applications only (and thus not in IE – also it requires configuration that a browser-based form user is unlikely to be able to do correctly). The XAdES information is added to the signed information that InfoPath would place there anyways (follow 'XAdES in Microsoft Office' link in the blog post for more info on format and config). The goal is to get a trusted timestamp of what was signed from a 3rd-party time-stamping service, thus we can later verify that the signature was created while the signing cert was valid.

    When a signing cert is expired, the InfoPath client will check the additional XAdES information to verify that it's fine to consider the signature valid anyways. Forms that are signed without XAdES information will eventually fail to validate due to the signing certificate's expiration. There are patches released for both the server and client to override this behavior.

  19. Gabriel says:

    "There are patches released for both the server and client to override this behavior. "

    I could find a patch for InfoPath Form Services 2010..

    Do you have links?


  20. Gabriel says:

    "There are patches released for both the server and client to override this behavior. "

    I could NOT find a patch for InfoPath Form Services 2010..

    Do you have links?


  21. JC says:

    I have a form in 2007 that has digital signature and it works fine form infopath 2007 to infopath 2007; however, when people try to open this form with infopath 2010, it crashes. Can you advise what is the fix for this issue? Thank you,

  22. Scott Heim says:

    Hi JC,

    On your machines with Office/InfoPath 2010, have you applied Service Pack 1 for Office 2010? The reason I ask is that there was an issue with the original released version where InfoPath 2010 would crash. This was resolved with a fix that was part of Service Pack 1.


  23. I have a somewhat odd issue: when opening an Infopath document on a computer with Office 2010, a user is not able to sign the document because the "Sign" button is greyed out.  We utilize Infopath as a template for a Form Library on SharePoint 2007.  This error occurs even when opening Infopath 2007 documents, but only on computers with Office 2010; a computer on Office 2007 can still open, sign, and save Infopath documents.  Even creating a new Infopath document with Infopath Designer on a 2010 computer, without even using SharePoint, we are still unable to sign the document.

    After not being able to sign the document (either on your own computer or

    from the SharePoint) and selecting "Cancel", Infopath freezes up, displays

    "Not Responding" and forces you to close the program without saving. If you

    click "See additional information about what you are signing…", Infopath

    also freezes up, Infopath freezes up, displays "Not Responding" and forces

    you to close the program without saving.  Selecting "Change…" and

    selecting a different certificate gives the same result.

    Is there a patch, work around, or fix action that will allow users with Office 2010 to digitally sign Infopath documents?  Is it a security issue or a software issue with Office 2010?

    I can provide a screenshot if necessary.

  24. Scott Heim says:

    Hi Jazley21,

    This was an issue that was corrected with Service Pack 1 (SP1) for Office/InfoPath 2010. Please install that update and you should be good.


  25. Jehnavi says:

    I've been doing this for years using a program called PDFpen, which also lets you add text to documents. For example, you can use it to fill out scanned PDF forms. With PDFpen, you can even modify text that's already there (but not scanned text).

  26. anildwa says:

    Can forms with digital signatures be submitted to a CRM database using the web services submit option?

  27. Jeanne Callen says:

    How do you enforce data validation when using an electronic signature?  I don't want the user to be able to sign the form if certain fields aren't filled in.  Right now a pop up box just comes up saying there are validation errors – and it lets you override the message and still sign.

  28. Scott Heim says:

    Hi Jeanne,

    Assuming your area to be signed is a "section" then you can simply wrap that section within another section and then add conditional formatting to this new section that insures it is hidden until your other field has been completed.


  29. Upgrading InfoPath forms with Digital Signatures. says:

    We have recently made some minor changes to one of our InfoPath templates that uses Digital Signatures and upgraded the Forms library in SharePoint that already had a number of forms there. We now get the following warning "This form is digitally signed, but was created with an older version of the form template. This form will be upgraded to work with the new template, but this may remove its signatures. Do you want to view the signatures before upgrading?" whenever we try to open one of the existing forms (i.e. ones that existed prior to the template upgrade). If we proceed it invalidates the signatures stored in these existing forms. Can anyone suggest a solution?

  30. DeveloperForExplorer says:

    What is there about signing on the explorer?

  31. David says:

    When using InfoPath and digital signatures with SharePoint, a Digital Signature Control Installation must take place at the user workstations.  In my environment most users are not administrators.  I've located the .cab files on the SharePoint servers but was wondering if you had instructions on how these files should be installed and where they should be located if this were to be pushed out via GPO.  Thanks.

  32. Zach B says:

    I have a IP 2010 form with multiple signature line controls.  How to I extract the typed name or the name on the certificate and promote each to their own SP column?

    Also, I was trying to figure out how to identify a form saved to a SP form library that has a completed signature. For example, I have three different organizations that have to apply their signature to this form. Is it possible to create some indictor that promotes to SP that is based off the signature line control which would indicate Organization 1 has Signed/Not Signed, Organization 2 has signed/not signed, etc.


  33. Disableing "Remove" signature from an InfoPath form on a SharePoint site says:

    I have an InfoPath 2013 form on a SharePoint 2013 site and after users enter

    in the required information, I digitally sign it to lock the data the users

    entered. The form is opened in a Browser by default.

    However once I sign it and the data is locked, any other user can log into

    SharePoint and hit the remove button next to my signature and remove it and

    edit the form.

    Is there any way to keep other users from removing my signature from an

    InfoPath form on a SharePoint site

Skip to main content