- When signing with the SHA512 hash algorithm, the minimum key length must be 2048 bits, otherwise it will throw the encoding exception: Encoding error: emLen (128) shorter than hashLen + saltLen + 2!
- Due to the limitations in some of the third party libraries used by ADSS Server, PSS padding scheme could not be supported as yet, i.e.:
- When using some of the hardware tokens (Safenet, Utimaco)
- When doing client-side signing by using Go>Sign Desktop, as MS-CAPI doesn’t support PSS padding scheme.
- ADSS Server supports Microsoft Office Word/ Excel native signing and verification. However Microsoft Office doesn’t support PSS padding scheme. Therefore for Microsoft Office native signing, ADSS Server will fallback to the PKCS1.5 padding scheme for server-side signing even if PSS padding scheme is configured in Global Settings > Advanced Settings for signing service.
- While creating a signing profile for PKCS1 signatures, Compute hash at signing time option must be enabled in the Advanced Settings under Hash Signing Settings.
What are the ADSS Server limitations when ECDSA key algorithm is is used?
ADSS Server supports Microsoft Office Word/ Excel native signing and verification. However Microsoft Office doesn’t support ECDSA.
- ECDSA is not supported for PKCS7 signatures as per RFC limitations.
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.
How to trust a Root CA certificate in the Adobe Reader?