Previously valid signing certificate shows invalid policy constraint in DC 2019

[Peter Goodey]

We have previously been able to sign documents with certificates with the following intended usages: Digital Signature, Encrypt Keys, Email Protection, 1.3.6.1.4.1.6449.1.3.5.2

As per Steven.Madwin​'s response to Document signing requires code signing certificate this should be fine. However as of Acrobat Reader DC 2019 the signature is marked as invalid. The certificate path shows "Invalid policy constraint" for the issuing certificate paths and the signing certificate. The certificate we are using is issued by Sectigo and is AATL approved.

Has Acrobat become fussier about the types of certificates it will accept. If so what needs to be present in the certificate?

[Steven_Madwin]

Hi pingu7931,

This is not a Key Usage/Extended Key Usage issue, but rather a Policy Restriction issue. Sectigo recently added the USERTrust RSA Certification Authority certificate to the Adobe Approved Trust List (AATL) program, and part of the requirements of being an AATL Member is we only trust signer's end-entity certificates if they comply with a specific set of policies. If you select the top most certificate in the tree view on the Certificate Viewer dialog, and then select the Policies tab, you will see the allowable set of policies. To see if your certificate meets one of the allowable policies select your cert from the tree view (the one you redacted), then select the Details tab, and finally, scroll to and select the Certificate Policies extension in the list view on the Details tab.

Granted, displaying this as an invalid signature is incorrect as it should show as Unknown because ultimately it is not valid because trust has not been established and the Acrobat should treat this the same as when trusted certificate is not found. Although I'm not sure when, there is a plan to align the two behaviors.

Thank you for sharing on the forum so others can benefit.

Steve

[Peter Goodey]

Hi Steven Madwin​

Thanks for getting back to me so quickly. Here's the policy details from the UserTrust/Sectigo CA Cert. Look reasonable? I could delve into the cert to dump lower level details?

[Steven_Madwin · Accepted solution]

Hi pingu7931,

The Object Identifier (OID, the number in the Certificate Policies edit field) is a representation for a document that lays out all of the requirements of a the Sectigo AATL Policy. If the digital ID that Sectigo issued you met those requirements then they wound have include that specific OID in your Public-key Certificate (PKC), or more specifically, the Certificate Policy extension in your PKC.

The missing piece of this picture puzzle is what is listed in your PKC? If you highlight your cert in the tree view on the left of the Certificate Viewer dialog, then select the Details tab, you can scroll the list view and find the Certificate Policy extension. If you click on that entry you will see a Policy OID that is a short-hand for which set of requirements your certificate met when it was issued. If it had matched the OID displayed above then the signature would have been valid.

Steve

[rolando_rerf]

The same is happening to me .. is there any way that we can get signatures verified ?

[Peter Goodey]

@rolandor81994411 I have submitted a bug report to Adobe to suggest that Signature's validity is changed to unknown rather than invalid when this policy requirement has not been met. It is valid in the sense that it is proven that the signing certificate's private key signed the document; the signing certificate chains up to a trusted AATL root; and that the certificate has not been revoked.

[Peter Goodey]

I know it's been a while but just to complete this response for anyone else, here is the Certificate Policies extension for the signing certificate. As you can see it does not have the policy with Oid 1.3.6.1.4.1.6449.1.2.1.6.6 that appears in the root certificate. I do agree that it should not mark the signature as invalid - that is entirely misleading. The certificate has been used to created a valid signature. It is only the validity of the certificate that is in question!

[Peter Goodey]

One final note on this: We have previously signed documents that had long term validation information which had then been document timestamped - making the document PAdEs Baseline Long Term Archival which are now showing as invalid. This runs counter to the logic of PADES LTA reasonaing which should show if a  signature was valid at signing time, and information to support this is included the document, then the signature should be still valid for as long as the timestamp's certificate chain is valid. I would therefore suggest that this behaviour change breaks with PADES LTA.

[Tomer5E8A]

Hi,

Although two years have passed I am having the same problem as in the DC21 version. Did Adobe align the two behaviors?

Thank you

Tomer

[Tomer5E8A]

@Peter Goodey 

[Peter Goodey]

Hi Tomer

Basically the signing certificate has to have the AATL policy specified.

Most annoyingly it also makes PAdES LTA documents signed 4+ years ago using non-AATL certificates invalid which is definitely incorrect and goes against core the intention of the standard. It was reported 18 months ago as a bug but there has been no response from Adobe.

As a developer you have no option but to obtain an unnecessarily over-priced AATL certificate. Or alternatively ignore the inavlid-policy constraint error and perhaps use a different reader.

Regards

Peter 

[learnEnglish100]

كيف يمكن كتابة كلمات لها علاقة بتعلم اللغة الانجليزية باستخدام أدوبي دي سي مثل جمل بالانجليزي