KB Article #176497
MailGate's Plain Text Policy and Client-to-Client encryption inspection
Problem
End users are utilizing S/MIME client-to-client (Desktop) encryption to secure email communication between each other, however organizations would often require that the email content is inspected by MailGate.This article provides a guideline to enforce policies that will allow MailGate to inspect mail which has been encrypted at the desktop or via other 3rd party mail encryption mechanisms, even if MailGate does not have the relevant sender and recipient certificates.
Resolution
The Axway Plain Text Policy
Axway MailGate appliance ships out of the box with a policy which is called Plain Text Policy. The Plain Text Policy simply checks to see if the MailGate appliance has been able to decrypt the message into plain text that can be scanned by the Policy Engine. If it can be decrypted, additional policies are applied and the mail item is processed according to those policies. If it cannot be decrypted, a signed notification is sent back to the sender telling them how to send an encrypted message to your organization, which includes the public MailGate encryption key.
A mail client such as Outlook or Lotus Notes will, when directed to do so, encrypt a mail item for each recipient. By doing this, only the intended recipient(s) can open it, and only by using their private decryption key. Axway MailGate inspects encrypted emails my expecting the appliance itself to be included as a recipient. This is done by the sender explicitly including the MailGate email address (e.g. secure-server@yourdomain.com), as an additional recipient of the email (typically on the CC line). This allows MailGate to decrypt the email and apply policies respectively; without it, no policies can be applied. For this to work, the sender’s machine must have the public encryption key of secure-server@yourdomain.com address in its key store, which is why the encryption key is provided in all decryption failure notifications.
I. Creating or importing a secure server certificate
In order to use a certificate for decrypting an email, you must first create and/or import a server certificate into MailGate.
A. Generating a certificate from MailGate Admin UI:
1. Navigate to Administration > Certificates > Local and click on 'New S/MIME Certificate'
2. You will be redirected to a page that prompts you to specify certificate's details. On that page:
- Select the domain
- Certificate Purpose: Signature & Encryption
- Enable for Proxy S/MIME usage
- (Select 'New key on HSM': put in a name for the key) - Optional, if HSM is enabled
- Chose key size
- Simple Distinguished Name: Put in all details needed
- Common name: your-domain.com
- Email address: secure-server@your-domain.com
3. Once you saved the certificate, make sure that it appears as “trusted”. You can also
select the “Trust unconditionally” option from the drop-down
B. Importing a third party certificate:
1. Navigate to Administration > Certificates > Local and click on 'Import'
- Chose the file type option (PEM | P12 | PEM with HSM key), browse to the file and specify the password.
- Import the certificate
NOTE: You should import all relevant certificates from the chain under “Root” and
“Intermediate” sections respectively. Detailed instructions for importing root, intermediate, and local certificates are included in MailGate Administrator’s Guide
2. On the same page (Admin UI > Administration > Certificates > Local > drop-down option)
verify the following:
- The new certificate is trusted
- “Edit domain” >> add your domain(s)
- Set default signing, set default encrypting
- Purpose must be “Signature and Encryption”
- “Enable for Proxy S/MIME” is selected
II. Enabling the Plain Text Policy
Axway Mailgate ships with default inbound and outbound Plain Text Policies. They are both disabled by default. For the decrypt/content scanning purpose outlined in this document, the policies need to be enabled (and customized, if needed). This policy is configured to quarantine messages that were encrypted but not for MailGate.
This is the Default policy content:
TARGET |
message |
IF |
contains any of the tags: 'Decomposition Error: Decrypt and Verify Failure','Decomposition Error: No certificate to decrypt message' |
THEN |
quarantine into "Default" queue and send the notification(s): 'Default Plain Text Policy Notification to Sender' |
The notification can be customized under Content Policies > Policy Objects > Notifications > Default Plain Text Policy Notification to Sender
Once you make sure the policy configuration fit your business case, please select "Enable Policy" at the top (you can enable it inbound or outbound only, or both).
III. How does the policy work?
Each sender, encrypting email at the desktop (or through another mechanism) will be expected to put MailGate's email address (secure-server@yourdomain.com) in the CC line of the same email and sign and encrypt the carbon copy with MailGate's public key.
If the condition above is not met, MailGate will stop (quarantine) the encrypted email in question and will return a notification to the original sender. The notification contains details about what is expected and it will be signed with MailGate's public key, so that the sender can use it to set up the encryption to secure-server@yourdomain.com.
If the condition above is met and a carbon copy to secure-server@yourdomain.com is properly included and encrypted, then the message will be accepted for processing and all subsequent content policies will trigger both on the copy, intended for secure-server@yourdomain.com , as well as for the original message that is encrypted. Should the message is cleared for sending after the content inspection, the original encrypted copy will be relayed further and the carbon copy will be stopped by MailGate.