Here's a report you can paste into both channels. I've written it to be clear, specific, and to frame the issue as both a UX problem and a m
Product: Adobe Acrobat Pro Vers 2026.001.21691
OS: macOS 26.5 (Tahoe)
Severity: High — blocks users from sending email in Apple Mail with no clear indication of the cause.
Summary
When a user creates a new digital ID through Acrobat's digital signature workflow, Acrobat installs the resulting self-signed certificate and its private key into the macOS login Keychain without adequately disclosing that (a) the key will be visible to other applications on the system, and (b) Apple Mail will subsequently attempt to use it to sign every outgoing message. This produces a confusing, seemingly unrelated failure in a different application (Mail) that most users cannot diagnose on their own.
Steps to reproduce
- In Adobe Acrobat on macOS, initiate a workflow that requires a digital signature (e.g., signing a PDF form).
- When prompted, choose to create a new digital ID and enter a name for the certificate.
- Complete the signing workflow in Acrobat.
- Open Apple Mail and attempt to send any outgoing email.
Observed behavior
- A new private key labeled "Imported Private Key" appears in the macOS login Keychain, associated with a certificate bearing the exact name (including capitalization) that the user typed into Acrobat.
- Apple Mail begins displaying the prompt "Mail wants to sign using key 'Imported Private Key' in your keychain" on every outgoing message.
- Outgoing mail is blocked until the user dismisses the prompt (and the prompt often reappears repeatedly).
- The user has no way to connect this Mail prompt back to their earlier action in Acrobat, because Acrobat never disclosed that the key would be installed system-wide or accessible to other apps.
Further most Mac users will not understand what the “Imported private key” is or how to correct it. Therefore most users’ mail will be irretrievably broken. This is serious.
Expected behavior
Acrobat should, at minimum:
- Clearly disclose, before creating the digital ID, that the certificate and private key will be installed into the macOS system Keychain and will therefore be visible and usable by other applications (including Mail, Safari, and any app that queries the keychain for signing certificates).
- Offer a default option to store the digital ID in an Acrobat-scoped file (e.g., a
.pfx/ PKCS#12 file used only by Acrobat), rather than defaulting to the system Keychain. - Restrict access control on the private key so that only Acrobat is permitted to use it by default, rather than allowing any application (notably Apple Mail) to pick it up automatically for S/MIME signing.
- Provide clear cleanup instructions in Acrobat's Digital ID settings for users who want to remove an ID they no longer use — including the system-level implications of doing so.
Why this matters
- User impact: Users experience an unexplained Mail failure hours or days after using Acrobat and cannot diagnose it. Support forums (Apple Discussions, Reddit r/MacOS, Adobe Community) contain many threads from confused users going back several years describing this exact scenario. This is not a rare edge case.
- Security/consent concern: Writing a private signing key into the shared login Keychain with broad application access, without explicit disclosure, is inconsistent with modern least-privilege expectations. Users cannot give informed consent to a system-wide change they were never told was happening.
- Trust: Users who eventually figure this out (usually by deleting the certificate) lose confidence in Acrobat's handling of their credentials.
Requested action
Please review the Digital ID creation flow on macOS and add (1) explicit disclosure of Keychain installation, (2) a non-Keychain storage option as the default, and (3) tighter access control on the private key so it is not exposed to unrelated applications without the user's consent.