Welcome Dialog

Welcome to the Community!

We have a brand new look! Take a tour with us and explore the latest updates on Adobe Support Community.


Previously valid signing certificate shows invalid policy constraint in DC 2019

Community Beginner ,
Aug 14, 2019 Aug 14, 2019

Copy link to clipboard

Copied

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?

Annotation 2019-08-14 160734.png

TOPICS
Security digital signatures and esignatures

Views

13.3K

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

Adobe Employee , Aug 15, 2019 Aug 15, 2019
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...

Likes

Translate

Translate
Adobe Employee ,
Aug 14, 2019 Aug 14, 2019

Copy link to clipboard

Copied

Hi

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Aug 15, 2019 Aug 15, 2019

Copy link to clipboard

Copied

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?

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Aug 15, 2019 Aug 15, 2019

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Sep 15, 2019 Sep 15, 2019

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Nov 22, 2019 Nov 22, 2019

Copy link to clipboard

Copied

@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.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Nov 21, 2019 Nov 21, 2019

Copy link to clipboard

Copied

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!

Annotation 2019-11-21 135555.png

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Nov 22, 2019 Nov 22, 2019

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
May 01, 2021 May 01, 2021

Copy link to clipboard

Copied

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

 

 

 

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
May 05, 2021 May 05, 2021

Copy link to clipboard

Copied

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
May 05, 2021 May 05, 2021

Copy link to clipboard

Copied

LATEST

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 

 

 

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines