Trusting Obscura signatures — managed fleets (Group Policy / MDM)

Audience: IT administrators at an organization that manages staff devices centrally
(Windows Active Directory / Intune, or macOS MDM such as Jamf, Kandji, Mosyle, Intune).

Outcome: every staff member's Adobe Acrobat/Reader shows documents signed by this
Obscura deployment as trusted, with no action from staff.

Time: ~20 minutes, once.

0. Before you start — get the root certificate and verify it

1. Open the public trust page: https://<your-obscura-host>/trust
2. Download Certificate (.cer / DER).
3. Verify the SHA-256 fingerprint shown on that page against a value you obtained
   out-of-band — the signing organization's official website, a printed letter, or a
   phone call to a known contact.

This step is the whole security model. A root certificate lets its holder issue
certificates your fleet will trust. Only install one whose fingerprint you have
independently confirmed. If you cannot confirm it, stop and contact the organization.

1. Windows — deploy the root via Group Policy

Domain-joined fleets:

1. On a domain controller, open Group Policy Management and edit (or create) a GPO
   linked to the OU containing your users' computers.
2. Navigate to:
   Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities
3. Right-click → Import… → select the .cer you downloaded → finish the wizard.
4. Force a refresh on a test machine (gpupdate /force) and confirm the certificate
   appears in certlm.msc → Trusted Root Certification Authorities → Certificates.

Intune (cloud-managed, no AD): Devices → Configuration profiles → Create profile →
Windows 10 and later → Templates → Trusted certificate, upload the .cer, and target
your device group.

1b. Windows — make Acrobat honor the Windows store

Adobe Acrobat/Reader keeps its own trust list and, by default, ignores the Windows
certificate store for signature validation. Turn that integration on fleet-wide.

The setting is visible to users at:
Edit → Preferences → Signatures → Verification “More…” → Windows Integration → Trust ALL root certificates in the Windows Certificate Store for: ☑ Validating Signatures

To push it centrally, Adobe's enterprise policy hive is:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\<product>\<version>\FeatureLockDown

(<product> = Acrobat Reader or Adobe Acrobat; <version> = e.g. DC.)

⚠️ Verify the exact value name against Adobe's current documentation before you
deploy it. Adobe has renamed these keys across releases, and we have not verified
the current name in your Acrobat version. Authoritative reference: the
Acrobat Application Security Guide
and the Acrobat Preference Reference.
A safe procedure: set the checkbox on one machine, export the resulting registry
branch, and deploy exactly that via GPO Preferences.

Known caveat reported by administrators: with Acrobat Protected Mode enabled,
Windows-store trust may not take effect. If validation still fails after deployment,
test with Protected Mode off to isolate it, then decide your policy.

Alternative that avoids the registry entirely: skip Windows integration and import
the root directly into Acrobat's own trust list on each machine — scriptable by
deploying Adobe's Trusted Identities data file, or simply run the per-user installer
(see the self-serve guide) via your software-distribution tool.

2. macOS — deploy the root via MDM

1. Build a configuration profile containing a Certificate payload
   (com.apple.security.root) with the .cer you downloaded.
   - Jamf Pro: Configuration Profiles → New → Certificate → upload → set “Allow
   export from keychain” off, scope to your device group.
   - Intune / Kandji / Mosyle: equivalent Trusted Certificate / Certificate
   payload; upload the .cer and scope it.
2. Push to a test device and confirm in Keychain Access → System that the
   certificate appears and is marked trusted.

2b. macOS — Acrobat trust

Acrobat on macOS also maintains its own trust list. The reliable route is to import the
root into Acrobat's trusted identities:

Acrobat → Preferences → Signatures → Identities & Trusted Certificates “More…” → Trusted Certificates → Import → select the .cer → Edit Trust → ☑ Use this certificate as a trusted root → OK

For fleets, distribute this as a documented one-time step (it takes ~30 seconds) or
deploy Acrobat's trusted-identities data file through your MDM's file-delivery payload.

3. Verify it worked

On a managed test device:

1. Open any PDF signed by this Obscura deployment.
2. Click the signature (or open the Signature Panel).
3. Expected: “Signature is valid” / signed by …, certificate is trusted.

If it still reads "not trusted", the OS store almost certainly has the root (check
certlm.msc / Keychain Access) and the gap is Acrobat's own trust — revisit §1b / §2b.

4. Ongoing maintenance

Note for the signing organization: regenerating the signing identity in
Admin → Security → Signing identity mints a new CA. Everyone who installed the
previous root must install the new one. Publish the fingerprint only once you're
settled on an identity.

What this does and does not give you

✅ Documents signed by this organization show as trusted on your managed fleet.
✅ No per-document steps, no cost, valid until the certificate expires.

❌ Not trusted by anyone outside your fleet who hasn't installed the root — an
external counterparty still sees "untrusted" unless they follow the self-serve guide.
❌ Not a legally certified electronic signature. In Indonesia only a licensed PSrE
(e.g. Peruri) issues those; Obscura supports that separately as the certified (PSrE)
signing tier.