I think you have two separate issues.
1. It looks like your original PDF is certified with permissions that do not allow you (or anyone else) to sign. You can see certification permissions in the Signature Panel (on the left) and also in the [certifying] Signature Properties. You need to ask the PDFs author to create another copy with signing permissions.
2. You certificate does not have policy constraints whereas the root certificate has them (as your screenshots show). But you probably also have policy constraints specified in your local configuration. Open "Trusted Identities" dialog (Edit->Preferences->Signatures->Digital IDs&Trusted Identities->More->Trusted Identities), select you root certificate and click on "Edit Trust" tab. In the "Edit Trust" dialog that comes up select "Policy Restrictions" tab. I bet policy restrictions are there for this certificate. If you want to validate your signature without policy constraints checking you can edit trust to remove policy constraints. But this may violate your organization's internal policies. Someone (perhaps your IT) must have placed policy constraints in the Trusted Identities.
You may want to procure a new certificate from Hong Kong Post that has policy constraints suitable for your organization. Since the second Hong Kong Post CA in the chain does not have policy constraints make sure that in the "Policy Constraints" in Trusted Identities->Edit Trust the "Apply policy constraints to the signing certificate only" radio button is selected.
1 person found this helpful
I am the person that effectively put the Hongkong Post certificates onto your computer, so trust me when I say I know from whence I speak. I’m going to first give you some background, both general and specific, and then I’ll tell you how you can make the signature valid, and finally, let you know why the fix is a bad idea.
The general background… All of the rules of signature validation are covered by the X.509 specification. There is a section in there that covers processing certificate policies and here’s a high level overview. A public-key certificate is made up with a bunch of extensions that define the certificate. Some of them are easy to understand like the issuer (who gave you the cert), the subject (you), the serial number, and the validity period (valid from & valid to). Other extensions are a bit more esoteric such as the Certificate Policy extension. What the Certificate Policy does is it tell the person looking at the certificate under what rules it was issued, and part of the Certificate Policy extension is a URL where you can see the rules written out. Not all certificates contain the Certificate Policy extension, and that’s okay, it just means that there were no specific rules about the issuance of that certificate.
The next think to understand is Policy Restrictions. A policy restriction is assigned (usually) to the root certificate and it tells the processing application (in this case Acrobat) that in order for the signature to be valid the certificates in the chain below the root certificate (but not the root certificate itself) must contain the Certificate Policy extension and within that extension it must contain the value of the at least one of the Object Identifiers (known as OIDs) that is listed as a restriction. It’s the old Venn diagram from high school math. One circle contains the Policy Restrictions, the other circle contains the Certificate Policies, and at least part of the circles must overlap in order for the signature to be valid.
Specific background… Adobe has a program we call AATL, which you can read about here (http://helpx.adobe.com/acrobat/kb/approved-trust-list2.html). When the Hongkonk Post gave Adobe the two certificates that are in the path they asked us to assign a Policy Restriction to the root certificate that contained the following two OIDs; 188.8.131.52.4.1.16030.1.4, and 184.108.40.206.4.1.16030.1.5. In essence, if the end-entity certificate (in this case your certificate) does not assert at least one of these two OIDs the signature will not be valid. That begs the question why apply the restriction, and the answer is Adobe will not add a certificate to the AATL unless the Certificate Authority (in this case Hongkong Post) guarantees that the digital IDs they issue will reside on a hardware device (either locked onto a token or a smart card). The two Certificate Policy OIDs they provided tell Acrobat that those certificates issued under that particular set of rules were issued on hardware devices. There may be other rules in the documentation as well, but that’s the one we care about.
How to fix this…
- Select the Edit > Preferences menu item
- Select Signatures from the Categories list box on the Preferences dialog
- Click the More button in the Identities & Trusted Certificates groupbox
- Select Trusted Certificates from the tree view on the left of the Digital ID and Trusted Certificate Settings dialog
- Scroll down and list view and select Hongkong Post Root CA 1
- Click the Edit Trust toolbar button on the dialog
- Select the Policy Restrictions tab on the Edit Certificate Trust dialog
- Delete the text in the Certificate Policies edit field (the Description edit field doesn’t do anything so don’t worry about clearing it)
- Click the OK button on the Edit Certificate Trust dialog
- Close the Digital ID and Trusted Certificate Settings dialog by the red X in the upper right corner
- Click the OK button on the Preferences dialog
At this point, if you re-validate the signature is should be valid
Finally, why you shouldn’t fix this (or if you do, put the OIDs back)… Yes, you can make the signature valid on your machine, but anybody else that gets a PDF file that you signed with this particular digital ID will see an invalid signature, just as you do now. You want to be assured that if you send out a signed file that the document recipient will see a valid signature, and if you remove the Policy Restriction you will give yourself a false sense of confidence. I strongly suggest that you accept that the good folks at Hongkong Post did not intend for you to sign PDF file with the digital ID that they supplied you, and if you really do need to sign PDF files, then you procure a digital ID that meets the security requirements.
I know this isn’t the answer you wanted.
Today, almost four years later, I think the simple answer is: "this is still too cumbersome and too complicated for any even computer-savvy person to use". I have trying to make this work for a while, but just to no avail.
Google results suggests that no individuals actually use this.