Attempting to send an encrypted email with PGP Encryption Desktop results in blocked message and error: "Keys not found (key is not end-to-end)"
Article ID: 446516
Updated On:
Products
Issue/Introduction
In PGP Encryption Desktop environments, outbound emails may be blocked even when the recipient's key exists on the PGP Encryption Server. This occurs when the client's mail policy requires "End-to-End" encryption or a "Verified Key," but the local client cannot validate these properties for the recipient's key. This would likely be seen in SKM (Server Key Mode) environments.
Environment
Possible errors:`Key not found; email blocked` (Even though the key is there)`REJECTED - key is not end-to-end` (Visible in PGP Encryption Server logs/Email reports)
- `keys not found` (Visible in Outlook/PGP Desktop notifications)
- `No usable encryption key found locally; will ask SEMS..` (Visible in PGP Desktop F3F Debug logs)
- `Failed with error not an error (0). Will try with AltString` (Visible in PGP Desktop F3F Debug logs)
Cause
The primary cause of this issue is the lack of a local key that matches the requirements in the policy on PGP Encryption Server, which utilizes mail policy "Chains" and "Rules" to trigger encryption.
Resolution
It's useful to track down which Chain and Rule are being matched by the PGP Encryption policies to really pinpoint where this could be failing. In the case of the error where it can't find an end to end key, this will typically occur if the policy requires "End-to-End" keys for Encryption policies.
Understanding End-to-End Keys
PGP identifies specific key management modes as true "End-to-End" (E2E) because the private key (or the ability to use it) resides on the client side, ensuring encryption happens before the data leaves the endpoint. In order for the key to be a true E2E key, the owner must have the keypair and the password to the key.
The key modes that utilize E2E are GKM and CKM--this is because in each of these cases, the owner has the full keypair and cane type passphrase for authentication.
With SCKM, the end user does have the private key to encrypt and sign, and they do know the passphrase and can enter it in, but the policy does not consider this true "End-to-End".
SKM is not a true E2E key, because although they have the keypair for signing and decryption, the end user does not ever type a passphrase. SKM keypairs are automatically authenticated as a part of enrollment.
For more information on key modes, see the following article:
153249 - PGP Encryption Management Server Key Modes (Symantec Encryption Management Server)
If you are running into the error listed above, make sure the policy is unchecked that requires "End to End"
Steps:
To resolve the block, the PGP administrator must adjust the outbound mail policy to allow keys that do not meet the strict local "end-to-end" definition:
- Log in to the PGP Encryption Server admin console.
- Navigate to Mail > Mail Policy.
- Edit the Outbound rule (e.g., "Encrypt Button").
- Uncheck the following options:
- `Require verified key`
- `Require end-to-end` - Save the policy.
- On the client machines, perform a Policy Update via the PGP Tray icon.
Additional Information
EPG-40923
225360 - PGP Message Blocked when sending email in Outlook (PGP Desktop)
153426 - Troubleshooting: Mailflow with Symantec Encryption Management Server (PGP Server)
153690 - PGP: Message is blocked by policy - recipient key not found (PGP Encryption Desktop)
181072 - Configuring Mail Proxies with the PGP Server (Symantec Encryption Management Server)
156100 - Emails going to exception chain on the PGP Server (Symantec Encryption Management Server)
157981 - Encrypting to Distribution Lists with Symantec Encryption Desktop (PGP Desktop)
156303 - Symantec Encryption Products Current Version Available
Feedback
