Possible Solution for Failure to Produce LTV Enabled PDF Signature

This blog post describes the case where your application asks Chilkat to produce an LTV-enabled PDF signature by specifying “ltvOcsp” in the signing attributes, yet the signed PDF as viewed in Adobe Acrobat does not show the signature as being LTV enabled.

For example, in Adobe Acrobat, an LTV enabled signature looks like this:

You can see the message “Signature is LTV enabled”.   If that message is missing, or the message is “Signature is not LTV enabled and will expire after…”, then something is amiss.

The RevocationInfoArchival Authenticated Attribute

One likely reason for the signature not being LTV-enabled is that Chilkat was unable to add the RevocationInfoArchival authenticated attribute.  Look at the contents of the Pdf.LastErrorText for the call to Pdf.SignPdf to see what transpired.  If the RevocationInfoArchival attribute was included in the PKCS7 signature, then you should see a section in the LastErrorText like this:

                IssuerCertOrg: Sectigo Limited
                  numCrlResponses: 2
                  numOcspResponses: 3
                  adding SigningCertificateV2 authenticated attribute...

If you don’t see a “pdfRevocationInfoArchival” section within the “createAuthenticatedAttributes”, then it means no RevocationInfoArchival attribute was added.  It is likely the retrieval of the CRLs from the issuer cert’s CRL dist point failed.  (the issuer certs are the  root certificate, and also any intermediate root certificates).  It could also be that OCSP requests failed.  To get more detailed information in the LastErrorText about the CRL and OCSP requests, add the following keywords to the Pdf.UncommonOptions property:  “LOG_OCSP_HTTP,LOG_CRL_HTTP”.

Then re-run your code to sign, and look at the contents of the Pdf.LastErrorText.  The information you’ll want to find is anything having to do with the CRL and OCSP HTTP requests ( to see if they failed, and the reasons for failure).