So you want to do Secure Web Mail on your MEG appliance. Excellent! This will help to ensure that mail leaving your environment will be secured appropriately. But wait! Why to customers receiving those messages receive a little icon on their outlook claiming that the message shouldn't be trusted?
This is because of S/MIME signing of the message. This is the same reason messages sent by the SWM service *MUST* come from a particular postmaster-esque address on the appliance. Basically, there is a setting in the MEG appliance to sign all SWM messages going outbound. This setting could be considered to be both a blessing and a curse, but I personally feel that it's really useful.
Consider the advice we give people every single day. Every day, as IT professionals, we tell our users to never click on an attachment in email that they don't expect to receive. Now, here we are sending messages to recipients who know nothing about our systems which basically say "click on this link to get the email I was trying to send you". Does this seem rather suspicious to anyone other than me?
In the interest of making these messages somewhat less suspicious, we made it possible to digitally sign these messages. This way, the message comes from an organization and can be proven to have come from that organization. Of course, this is where S/MIME certificates come in. In order to do this digital signing, the MEG *MUST* have a certificate with which to sign the message. And that certificate has to be a special certificate. Although it's basically identical to the certificate your web server uses to secure connections to itself, an S/MIME certificate has to secure email.
Thus, I make the following recommendations as a best practice recommendation to customers:
1. If you are going to use SWM, sign the SWM message notifications. This helps users to be certain that the messages came from a legitimate source and not from someone spoofing your domain/email addresses.
2. If you are going to sign message notifications, get a S/MIME certificate from your favorite CA. This one is the tough part. Not all CAs provide S/MIME certificates. However, many do, and anyone who does should make it possible to generate a CSR and send it to them to get a S/MIME certificate. That may then be loaded into the MEG appliance for signing of the SWM notifications.
3. If you are not going to get a signed S/MIME certificate, DON'T sign SWM notifications. I know this goes against best practice #1 above, but this will save you headaches down the road. If you sign your notifications with the default S/MIME certificate on the box, it shows up as a bad certificate on the remote end. Not only does this confuse the recipient, it actively degrades the confidence of the recipient in the message. If you received a message telling you to click a link to receive your email message and that message showed as having a broken signature, would you click it? I would hope not.
To load an S/MIME certificate into your SWM appliance:
1. go to Email -> Encryption -> Certificates
2. In the section entitled "Notification Signing Certificate" at the bottom of the page, fill in all the fields with appropriate settings.
3. Click the green check at the top of the screen to save the settings.
4. Click the button to Generate Certificate Signing Request.
5. Submit the CSR to your favorite certificate authority and ask for an Email Signing Certificate. Specifically, you want the Email Protection feature on your certificate. Without this, all you have is a standard SSL certificate.
6. When they send you back the S/MIME certificate, go to Email -> Encryption -> Certificates and click Import under the Notification Signing Certificate section. Follow the prompts to select your certificate file from your machine.
You now have a certificate loaded for signing email.
If you choose not to get a publicly-signed certificate, do yourself a favor and do the following (in keeping with Best Practice #3 above):
1. navigate to Email -> Encryption -> User Account Settings.
2. Under Enrollment and Notification, uncheck the box next to "Digitally Sign Outgoing Notifications".
3. Click the green check to save and apply the changes.
This ensures that, if you're not going to be signing the messages with a publicly-signed certificate, you're at least not signing them with an untrusted one either.