I'm following the How-to on Implementing PAdES signing of PDF documents using SecureBlackBox, and I'm having difficulty applying it. I'm using a certificate stored on a crypto-key from a trusted CA that links back to the Adobe Root CA. I was able to use the PDFPublicSecurityHandler to successfully certify a PDF with our secure token and everything seemed perfectly fine when we opened the PDF in Adobe Reader X, but then when someone opened the PDF in Adobe Reader XI they got that "PDF is not LTV-enabled and will expire" warning. Following a series of searches on the site, I ended up at the How-To that led to using the PDFAdvancedPublicSecurityHandler and its advanced options to meet Adobe's LTV requirements.

I followed the documentation, but I'm hitting a snag on signing; the chain validation fails. I followed further documentation on diagnosing failed chain validation to output a log of the validation actions and the results showed that I first had failed to generate a CRL retriever because I had not registered an HTTPCRLRetrieverFactory. After clearing up that issue, I am now getting a CRL error 1001 - Validation of CRL's signature failed on my certificate. Then, I'm getting OCSP errors 2002 and 2004 on my certificate. My CA's certificate is not generating any CRL or OCSP errors on validation, but it is still failing validation for reason 32.

As far as the code I'm using, it's similar to the how-to documentation. The cert storage I'm using in my handler contains my certificate and my CA certificate--I don't know how to or if I need to include the Adobe Root CA. I added my CA certificate to the CustomRevocationInfo.Certificates, but I was unsure of how to add the CRL manually. I am using an http client for the time stamp provider using a trusted time stamp authority. I have tried setting MandatoryCLRCheck and MAndatoryOCSPCheck to false, and if I set IgnoreChainValidationErrors to true the process finishes successfully but the certificate on the pdf doesn't display correctly and still does not show to be LTV-enabled.

If you have any further questions, please let me know! Any help would be greatly appreciated.

Thank you for your quick response! I followed the how-to documents and used the TElX509CertificateValidator directly to perform validation of my certificate from the certificate store, then a second validation on the CA certificate. I don't believe I'm using any LDAP components, but I checked on the type of CRL Retriever just in case and it did say it was a TElHTTPCRLRetriever. I don't think there's an issue with the HTTP requests because of where it appears to be failing, but please let me know if I misunderstood. I used the validation events to log the process step-by-step and compared the resultant codes and I think I've narrowed down the problem. Here's what I learned:

The validation successfully retrieves and uses the CRL for my certificate from the provided URI in the certificate.

The validation works to retrieve an OCSP response for my certificate from Entrust.

The validation successfully retrieves and uses the CRL for the Entrust Validation Authority certificate.

The validation successfully retrieves and uses an OCSP response for the Entrust Validation Authority certificate.

The validation attempts to validate the Entrust CA certificate. The response is invalid, giving reason 32--Unknown CA. The OCSP response then throws an error and validation chain fails.

When validating only the Entrust CA for Adobe certificate, I get the same reason. The CA for that certificate is the Adobe Root CA, which I'm not sure is obtainable? I must be doing something wrong, because I can only imagine this being a wall that anyone hits when trying to use a certificate that points back to the Adobe Root CA. I followed the How-To's on diagnosing the issue and tried to modify the settings to get past the issue to no avail. Is there a way around this?

If you have registered a CA certificate retriever class as well (this is done in the same way OCSP and CRL retrievers are registered) and after that you still get no CA Certificate error, this means that you should get some collection of CA and/or ROOT certificates somewhere and add them to the validation process. In other words, it's your job to find where to get Adobe Root CA certificate.

Good news is that in your case it seems that you will have problems only with Adobe certificates, so you can try to pull them out of Adobe software and carry with your application.

I registered an HTTPCertificateRetriever but the results were the same. I was able to extract and install the Adobe Root CA with Adobe Acrobat, but now that I have it installed I'm getting more errors. It still says that it successfully retrieves and uses the CRL for my certificate from Entrust, but where it had been validating the CRL certificate it is now validating the Entrust CA for Adobe certificate instead. If I set MandatoryCRLCheck to false, it checks the Entrust CA for Adobe certificate a total of 6 times. Every time it checks against the Entrust CA for Adobe certificate, the validation now fails for the reason CA Unauthorized. However, when I check the key usage for that certificate it seems okay. I've attached my code this time in case it helps:

certStorage.Add(ceCert, true);
//entrustCert = CreateCertificateCopy(entrustCert); I attempted to use a solution provided to another person on the forums having an issue with this method of certification with the same issuer and SafeKey hardware, but it didn't appear to make a difference.
//adobeCert = CreateCertificateCopy(adobeCert);
certStorage.Add(entrustCert, false);
certStorage.Add(adobeCert, false);
int reason = 0;
TSBCertificateValidity test = TSBCertificateValidity.cvInvalid;

That certStorage was a relic from the code I was using to attempt to apply the certificate to a signature in a PDF, but using it in the validator's AddTrustedCertificates method got me back the proper validation of the certificate's CRL. I am still stuck on the Entrust CA for Adobe validation, however. It still fails validation for reason 64, CAUnauthorized.

Checking against the error codes, it says that the "Issuer (CA) certificate was found but it's key usage fields don't allow use of this certificate for signing other certificates." However, when I check the Entrust CA for Adobe certificate's key usage fields, it says "Certificate Signing, Off-line CRL Signing, CRL Signing (06)". It also has an Enhanced Key Usage field that reads "Unknown Key Usage (1.2.840.113583.1.1.5)". Under that certificate's CA (Adobe Root CA) for key usage rights (it's hard to tell from the documentation whether the error refers to this CA or it's parent CA), it says "Certificate Signing, Off-line CRL Signing, CRL Signing (06)".

I apologize for all of the issue. I was able to successfully use the TElPDFPublicKeySecurityHandler to certify PDFs with this certificate, but my end-goal is to get that LTV-enabled tag in Adobe Reader/Acrobat XI by following your documentation using TElPDFAdvancedPublicKeySecurityHandler and I have not successfully gotten that tag so far with the certificate chain being unable to validate. I'm hoping that if I can at least get the validation to succeed, I'll be one step closer to that goal.

Let's continue in HelpDesk ( https://www.eldos.com/helpdesk/ ) please. I have created a new support ticket based on your above message. You will see your (and only your) support tickets by following this URL. You will also get e-mail notifications about updates related to your support ticket.

For anyone having the same issue, here is the solution we found that worked for me. This applies at least to a certificate from Entrust stored on a SafeKey USB token. First, I had to extract and install the Adobe Root CA using Adobe Acrobat. Then, this method worked for signing:

We use cookies to help provide you with the best possible online experience. By using this site, you agree that we may store and access cookies on your device. You can find out more about and set your own preferences here.