EUTL auto sync doesn't run

Question

Adobe updates the list of EUTL certificates regularly, but Adobe Acrobat does not sync with that list automatically.
You need to force sync manually for the Adobe Acrobat EUTL list to update.
It's a bug that Adobe must solve, since theoretically it should automatically synchronize if more than 14 days have passed since the last synchronization, but it is something it doesn't do.
Tested on multiple computers, it only syncs manually, never automatically.
If you do not update, checking for signatures issued with that certificate fails with a validation error.

And certificate is on EUTL since July, 24 (this year 2024), but internal EUTL list in Adobe Reader never update, unless we update EUTL manually or install Adobe Acrobat again (in the new installation it seems to perform a synchronization)

Thanks

adaptable_grace3419 · Answer

ANF document timestamp trust issue resolved by manual trust-list updates: investigation request

Product: Adobe Acrobat (64-bit) 26.002.21931 (Acrobat Reader mode), Windows 11 Pro 10.0.26200.

Trust Manager settings observed before any change: "Load trusted certificates from an Adobe AATL server" and "... from an Adobe EUTL server" checked; "Ask before updating" unchecked for both. Factory defaults were not tested.

Date of tests: 2026-10-16 and 2026-10-17. All test times below are local time in Madrid, UTC+02:00. HTTP header dates keep their stated GMT timezone. English UI messages are translations of the Spanish interface shown in the screenshots.

Summary:

On this installation, PDF document timestamps issued under the CA "ANF AC Qualified TSA" showed an unknown-trust result. After clicking "Update Now" for AATL and EUTL, the same PDF validated. That CA is present, with Root=1, in the Adobe EUTL bundles we examined from August 2025, May 2026 and October 2026, and absent from the July 2024 bundle. We ask Adobe to investigate why Acrobat did not establish trust for this timestamp before the manual updates. We did not preserve the original store, so we cannot determine whether the CA certificate was absent or present without usable trust settings. We need these timestamps to validate without any action by the recipient.

Facts:

1. The CA. "ANF AC Qualified TSA" (certificate validity begins on 2024-11-13), SHA-256 AFBC8E2D546CA7499D8A8104A765B00D2A30F3B0275394D67A8D60C03D0163B5, issues the TSU certificates that sign the timestamps ("ANF Qualified Time-Stamping Unit 1382" and "1383").

2. Adobe bundle content. In https://trustlist.adobe.com/eutl12.acrobatsecuritysettings (downloaded 2026-10-16, Last-Modified: Fri, 02 Oct 2026 12:35:28 GMT) and in the copies archived by the Wayback Machine on 2025-08-26 and 2026-05-08, the certificate appears with ImportAction=1, Root=1, Enabled=1, Source=EUTL. It is absent from the copy archived on 2024-07-28.

3. Reinstallation and user store. We reinstalled Acrobat on 2026-10-12; Windows reports InstallDate=20261012 for version 26.002.21931. On 2026-10-16, the user trust-store file addressbook.acrodata still had a creation timestamp of 2024-02-21. We do not know whether the reinstallation changed the store contents.

4. Initial failure (20:55). Signature panel: "Signature validity is UNKNOWN ... the signer's identity is unknown because it has not been included in your list of trusted certificates and none of its parent certificates are trusted certificates."

5. Manual update (20:57). "Update Now" for AATL and then EUTL; no other setting changed. At 21:01 the same PDF showed "Signature is valid. Source of Trust obtained from European Union Trusted Lists". A timestamp issued at 21:04 by the same TSA also validated ("... last checked on 2026-10-02").

6. Automatic check observation. With both cLastChecked values (HKCU\Software\Adobe\Adobe Acrobat\DC\Security\cDigSig\cEUTLDownload and cAdobeDownload) set to 2026-08-01, opening a signed PDF at 21:23:31 changed both values to 21:23:33.

7. Separate, modified-state test. We removed the ANF CA from Trusted Certificates and set both cLastChecked values to 2026-08-01. After opening the signed PDF, both values were observed to have changed to the current date and time, but the PDF still showed a signature problem, and the observed file size and modification timestamp of the trust store remained unchanged. A manual EUTL "Update Now" then restored validation. We did not capture network traffic or import logs. This test does not reproduce a genuinely outdated bundle: the result may be caused by Acrobat not re-importing a bundle version it already has, or by honoring an explicit removal.

8. Controlled EUTL-only test (2026-10-17). With a newly created empty user trust store and both AATL/EUTL loading options disabled, the TSU 1383 timestamp showed unknown validity at 10:18:52. After enabling only EUTL loading and clicking its "Update Now", it showed valid at 10:20:25, with trust obtained from the EU Trusted Lists. This establishes that EUTL alone was sufficient in this controlled test; it does not establish the contents of the original store on 2026-10-16.

9. Related community report. This thread reports a related automatic EUTL update symptom, but we have not established whether our case has the same cause.

What we could not preserve: the original trust-store contents and the previous cLastChecked values. The cause of the initial failure is therefore not determined.

Questions:

1. When the automatic AATL/EUTL check runs, under which conditions does Acrobat download and import a newer bundle? Is there a log we can enable to see it?

2. Does installing, updating or repairing Acrobat refresh or replace an existing user trust store, or does it keep the previous one?

3. Does an explicit removal of an EUTL certificate prevent its restoration during automatic checks? Does "Update Now" force a re-import of an unchanged bundle while automatic checks only import a newer version?

4. Is there a supported way for an organization to make sure its users' installations (and third-party recipients) pick up the current EUTL without manual action?

5. Is our case related to the issue reported in that community thread? If so, what is its current status, and is there a fix or supported workaround?

Available on request: the test PDF timestamped by TSU 1383, the timestamp token of the earlier TSU 1382 PDF, screenshots, the test log, and the SHA-256 hashes and archive URLs of the examined Adobe bundles.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.