Hello support team.
I’m using Aspose PDF v19.4
We created private root CA via Windows Certificate Authority and issued certificate for signing PDF.
We verified certificate is valid from bunch of 3rd party PDF component such as Dynamic PDF and etc.
Unfortunately certificate failed to validate in Adobe Reader if use a Aspose.
also there’s no problem to sign Adobe Reader directly which saved in Windows Cert Store.
I have no idea which problem makes error.
I attached our certificate and sample pdf with source project.
Certwin.zip (89.7 KB)
Please let me know what was the problem.
@Jaehoon
We have tested the scenario using Aspose.PDF for .NET 19.6 and managed to observe the message in Adobe that you have mentioned. We have also observed that certificate file did not have any signer information. Signer information is required to add the certificate into local certificate store after which Adobe Reader is able to recognize and authenticate the signature.
Nevertheless, we have logged an investigation ticket as PDFNET-46608 in our issue tracking system. We will further look into details of the issue and keep you posted with the status. Please be patient and spare us little time.
We are sorry for the inconvenience.
Hello asad.ali
Could you describe what was mean that certificate did not have signer information?
I think something wrong because there’s no problem to import to Windows Certificate Store and sign at Adobe Reader
I need more information which makes error certificate or Aspose
@Jaehoon
When you open the Signed PDF in Adobe Reader, you can check signature properties by right clicking over it in signature panel. In pop up window you can check that information is missing about certificate. Please check attached screenshot:
SignerInfo.png (56.8 KB)
A valid certificate uses to have this information and once it is added into local certificate store, Adobe Reader recognizes it as valid one. You can try using a different certificate and check if issue still persists.
Hello asad.ali
I attached 2 pfx files.
1.pfx exported programically using C# from Windows Certificate Service.
and 2.pfx manually exported Windows Certificate Store after I imported 1.pfx there.
So I think actually 1.pfx and 2.pfx same certificate
I checked my exported pfx file using certutil -dump command and found a difference
Please see attached image.
1.pfx certificate structure order is user certificate and Root CA
2.pfx certificate’s order is Root CA and user certificate
So in my opinion, Aspose PDF did not recognize certificate structure in case of 1.pfx.
Could you confirm these certificate has no problem that relation of my problem?
pfx.zip (8.3 KB)
11111111111111.png (34.2 KB)
@Jaehoon
Could you please provide passwords for both .pfx files.
@Jaehoon
We tested scenario using both .pfx files and found that 2.pfx file was fine when signing document with Aspose.PDF for .NET. However, we have added certificate to the local trusted certificate store in Adobe Reader after opening the signed PDF.
We performed following steps:
- Right Click over Signatures and goto Signature Properties
- Press Show Signer Information button in popup
- Goto Trust Tab
- Click Add to Trusted Certificates button
AddToTrustCertificates.png (22.1 KB)
After performing above, the document showed valid signatures. ValidSignatures.png (4.1 KB)
You may use such certificate files to sign PDF documents. As far as logged ticket is concerned, we will let you know in case we have some additional updates.
Hello asad
My point was 1.pfx did not sign properly when I used Aspose but 2.pfx working fine.
Differences is certificate’s internal order because certutil.exe shows different order each pfx files.
So I would like to know is there any related at signing Aspose.
@Jaehoon
We will be able to share our feedback as soon as the logged ticket is investigated. We greatly appreciate your patience in this regard. Please spare us little time.
Hello asad.
How is it going?
Could you tell me is it Aspose problem or not? Actually we have not much time.
@Jaehoon
The issue was logged under free support model where issues have low priority and are investigated on first come first serve basis. We have recorded your concerns and will definitely consider them during investigation. We will let you know as soon as some definite updates are available in this regard. Please spare us little time.
We are sorry for the inconvenience.
@Jaehoon
We have investigated the earlier logged ticket. Differences in the certificate’s internal order have meaning. Usually, the child certificate comes first on the list. Root last.
In file 1.pfx, they are reversed. Sorry, but now we can’t fully check these certificates because they are Expired 30.06.2021. If you can please share the code for obtaining a certificate of this kind, and new examples of certificates we can continue research.
If the results of retrieving the certificate programmatically and manually differ, then you should avoid this.