Table of Contents
ADSS Signing Server, the Verification service and the Go>Sign service all support PAdES LTV signatures - however the appropriate configurations must be made in these services and the utility modules.
In order to ensure digital certificates are trusted by ADSS Server, the PDF signer certificate Issuer CA must be registered within Trust Manager. The validation policy of the Issuer CA must be defined, i.e. whether it is using CRLs or OCSP?
The CRL Monitor module checks the certificate revocation information for registered CAs when the validation policy is set to "Local CRL Cache". It is not used when the policy is set to dynamically fetch a CRL from the CDP location or if OCSP only is configured. When using a local CRL cache ensure that
If AKI & SKI extensions are being used in the target certificate hierarchy then ensure that the SKI of the target CA must match with the AKI extension in the relevant CRL.
The OCSP responses must be signed using a certificate issued by the same CA that certified the signer certificate. The OCSP response signing certificate must have an Extended Key Usage of “OCSP Signing”.
ADSS Server supports Microsoft Office Word/ Excel native signing and verification. However Microsoft Office doesn’t support ECDSA.
ECDSA is not supported for client side hahsing:
While using .NET Test Tool
While generating XAdES signatures
ECDSA is not supported with PSS padding scheme.
The default size of a file to be uploaded on ADSS Server Console is around 26 MB. To upload a file larger than the default size, follow the instructions below:
Edit the struts.xml file
Search for the parameter "struts.multipart.maxSize"
<constant name="struts.xwork.chaining.copyErrors" value="true"/> <constant name="struts.xwork.chaining.copyFieldErrors" value="true"/> <constant name="struts.xwork.chaining.copyMessages" value="true"/> <constant name="struts.multipart.maxSize" value="26214400" /> //It shows the default value in bytes. Update the value as per your requirement //e.g value="64258800"
If the signatures produced by the ADSS Server are reported as not trusted by Adobe Reader, the reason is that the issuer CAs are not set as trusted in the Adobe Reader trust store.
If the issuer of your PDF signing certificate is not already trusted by Adobe Reader then you will face this issue.
There are two possible solutions to resolve this issue:
Use a certificate from a CA which is pre-embedded in the Adobe Reader so that the signatures are immediately trusted, without any manual update of the Adobe Reader trust store. If you are interested in this option then we do have partnerships with Adobe CDS/AATL CAs and can guide you further on this. Email your inquiries to email@example.com.
Import your Root CA certificate into Adobe Reader trust store. Please note that it's a one-time action which all users who verify signatures will need to perform in their Adobe Reader instances. Follow these steps to import the Root CA in Adobe Reader trust store:
Open the signed PDF file in Adobe Reader
Right click on the signature and select the option "Show Signature properties"
The following signature properties dialogue will be shown:
Clicking on the “Show Signer’s Certificate” button will show the following popup window:
Clicking on the “Add to Trusted Certificates” button will show the following warning message:
Clicking on the "OK" button will show the following window:
Enable the check box "Certified documents" and click on the "OK" button
Again click on the "OK" button to close the popup window
Click on the "Validate Signature" button
Now the signatures produced by Root CA issued certificates will be shown as valid and trusted by Adobe Reader