Signature is invalid - Invalid Policy Constraint - Certificate from EUTL

[John Smithh]

Hello,

I have a digitally signed document with qualified certificate from EUTL - CA named "First certification authority, a.s." or https://www.ica.cz/.

As of today, signature with this certificate is showing as an Invalid, with error "Invalid Policy Constraint".

Version of my Acrobat Reader DC:  2021.001.20155

First, I tried is to turn off "load certificates from AATL server" and only left EUTL turned on in preferences, this did nothing, Acrobat is still showing source of trust obtained from AATL.

Second, I found this thread and it seems like in the end nobody solved it. https://community.adobe.com/t5/acrobat/previously-valid-signing-certificate-shows-invalid-policy-con...

Since this is policy constraint error, here I share the policies from root cert. in chain.

I also attached signed file.

Multiple certificates from different persons are returning this error.

  

Could you give me some advice how to solve this?

Kind regards,

John

[MikelKlink]

I have opened your PDF in Acrobat Reader here and got a "Signed and all signatures are valid." I even updated Adobe Reader to the same version 2021.001.20155 and explicitly updated the trust list information.

An interesting difference to your screen shot, though: Here the certificate path is only displayed up to the intermediary qualified CA certificate, not the root CA certificate. This suffices as that intermediary CA certificate already is trusted by the AATL and/or EUTL.

Thus, it looks like this is not a general issue but one specific to your configuration. Have you or has your system administrator changed relevant trust settings in a way that the intermediary CA certificate is not trusted directly anymore but trust requires the root CA certificate?

Indeed, that root CA certificate in the Adobe Reader trust settings is associated with the policy requirements you see in your screen shot, i.e. 0.4.0.2042.1.2 (NCP+), 0.4.0.194112.1.2 (QCP-n-qscd), or 0.4.0.194112.1.3 (QCP-l-qscd). But the end entity certificate in your certificate chain only has the related policy 0.4.0.194112.1.0 (QCP-n). Thus, if trust is based on the root CA, that end entity certificate does not fulfill the associated policy requirements.

[John Smithh]

I've solved it.

Problem was in addressbook.acrodata

I've deleted whole directory of "%appdata%\Adobe\Acrobat"

Then manually updated AATL and EUTL list in Acrobat in Edit > Preferences > Trust Manager

And it's validating signatures correctly now. Even it shows EUTL server in validated signature detail, before it showed only AATL.

Probably some update of Acrobat Reader DC from last 2 months did this, because I have multiple computers with same problem.

[md555 · Accepted solution]

The real problem here is, that certificate issuer "I.CA Qualified 2 CA/RSA 02/2016" is registered both in AATL and in EUTL, but the registrations are not identical.

When you first load EUTL, addressbook.acrodata contains:

/Country(CZ)/Editable true/Enabled true/ID ..../Source[(EUTL)(AATL)]/

and the signature is verified according to EUTL.

However, the default is to load AATL first, which results in addressbook.acrodata containing:

/Editable true/ID ..../Source[(AATL)(EUTL)]/

and the signature fails verification with Invalid policy constraint

[MikelKlink · Accepted solution]

That would explain why it works for me. Indeed, I have /Source[(EUTL)(AATL)] for that certificate.

But looking at the OP's screen shot the root certificate is selected and displays the inappropriate policy constraints, it looks like in his case the CA certificate was not trusted at all, neither AATL nor EUTL. Or is the CA not taken as a trust anchor in his case because of the unfulfilled AATL policy constraints?

[md555]

Certificate for "I.CA Qualified 2 CA/RSA 02/2016" is directly trusted in EUTL, so "I.CA Root CA/RSA" is not even considered/displayed and its policy constraints are ignored when EUTL is checked first.

However, when AATL is checked first, Acrobat shows, that only "I.CA Root CA/RSA" is directly trusted in AATL, but for "I.CA Qualified 2 CA/RSA 02/2016" it shows "Source of trust obtained from AATL". Thus policy constraints from root CA now apply down the certification path and are not fulfilled by the signing certificate.

[MikelKlink]

Ah, ok, so you actually meant that the CA certificate is implicitly registered via its issuer, the root. I first though you meant that the CA certificate was explicitly registered on the AATL...

[md555]

Well, Source[(EUTL)(AATL)] means it is explicitly registered on AATL, but it's not flagged as direct trust anchor there.

[John Smithh]

First of all, thank you for looking into it, you and @MikelKlink .

My knowledge about this topic is near zero, do you have any good documentation or links where I can read up on all this stuff?

Problem is, I have a new problem with other document signed also with qualified certificate, with root from I.CA.

And now, nothing helps and it shows invalid cert.

Also, I will try message to I.CA if they can do something with this.

[MikelKlink]

Problem is, I have a new problem with other document signed also with qualified certificate, with root from I.CA.

And now, nothing helps and it shows invalid cert.

Can you share this PDF for analysis, too?

My knowledge about this topic is near zero, do you have any good documentation or links where I can read up on all this stuff?

What exactly do you mean by "this topic"? Do you mean all things related to validation of digital signatures? Or do you merely mean the limitations of Adobe's handling of trust lists?

[John Smithh]

>Or do you merely mean the limitations of Adobe's handling of trust lists

This, everything about AATL and EUTL and is it somewhere documented more technically?

[MikelKlink]

Well, I found out about the limitations of Adobe's handling of trust lists here in this thread and similar threads or bug reports here or there.

Even if you merely want to find out about the AATL and the EUTL in general on a technical level, I'm not aware of any public Adobe documentation.

The situation changes as soon as you become interested in the sources from which Adobe's EUTL is fed, the EU trusted lists, as there is a lot of public specifications by ETSI available online.

Therefore my question what exactly you want to know.