User Guide
MailMarshal Secure 5.5
THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE SUBJECT TO THE TERMS OF A LICENSE AGREEMENT OR A NON-DISCLOSURE AGREEMENT. EXCEPT AS EXPRESSLY SET FORTH IN SUCH LICENSE AGREEMENT OR NON-DISCLOSURE AGREEMENT, MARSHAL LIMITED PROVIDES THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SOME JURISDICTIONS DO NOT ALLOW DISCLAIMERS OF EXPRESS OR IMPLIED WARRANTIES IN CERTAIN TRANSACTIONS; THEREFORE, THIS STATEMENT MAY NOT APPLY TO YOU.
This document and the software described in this document may not be lent, sold, or given away without the prior written permission of Marshal, except as otherwise permitted by law. Except as expressly set forth in such license agreement or non-disclosure agreement, no part of this document or the software described in this document may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, or otherwise, without the prior written consent of Marshal. Some companies, names, and data in this document are used for illustration purposes and may not represent real companies, individuals, or data. This document could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein. These changes may be incorporated in new editions of this document. Marshal may make improvements in or changes to the software described in this document at any time.
© 2006 Marshal Limited, all rights reserved.
U.S. Government Restricted Rights: The software and the documentation are commercial computer software and documentation developed at private expense. Use, duplication, or disclosure by the U.S. Government is subject to the terms of the Marshal standard commercial license for the software, and where applicable, the restrictions set forth in the Rights in Technical Data and Computer Software clauses and any successor rules or regulations.
Marshal, MailMarshal, the Marshal logo, WebMarshal, Security Reporting Center and Firewall Suite are trademarks or registered trademarks of Marshal Limited or its subsidiaries in the United Kingdom and other jurisdictions. All other company and product names mentioned are used only for identification purposes and may be trademarks or registered trademarks of their respective companies.
Contents
About This Book and the Library ...vii
Conventions ...viii
About Marshal ...ix
Chapter 1
Introducing MailMarshal Secure
1
What is S/MIME? ...1Encryption ...2
Signing ...2
How Does MailMarshal Secure Work? ...2
Options for Using MailMarshal Secure ...3
Online Help ...3
Chapter 2
Configuration
5
Installing MailMarshal Secure ...5Configuring MailMarshal Secure ...6
Server Properties: Secure Email ...7
Security Policies dialog ...9
Server Properties: Internet Access ...13
Setting Up S/MIME Features ...15
S/MIME Repair Functions ...15
Repair Certificates ...15
Repair Certificate Emails ...16
Repair Certificate Key Containers ...16
Chapter 3
Certificates
17
Working with Certificates ... 17
Backing Up Certificates ... 18
Creating a Certificate Folder ... 18
Creating a New Certificate ... 19
General ... 19
Extensions ... 21
Subject Names ... 22
Certificate Usage/Finish ... 24
Certificate Tasks ... 25
Checking Imported Certificates ... 26
Exporting Certificates ... 27
Certificate Search ... 29
Main ... 30
Conditions ... 30
Status ... 31
Trust Search Options ... 31
Certificate Properties ... 32
General ... 32
Usage ... 32
Certificate Details ... 33
Certification Path ... 33
Proxy Certificates ... 34
New Proxy Certificate ... 34
Domain Email Address ... 34
Chapter 4
Private Keys
37
Backing Up Keys ... 37Private Keys Tasks ...38
Export Private Key ...38
Create Key ...39
Private Key Properties ...40
Private Key ...40
Details ...40
Chapter 5
Certificate Requests
41
Creating a Certificate Request ...42Extensions ...44
Subject Names ...45
Finish/Export ...45
Chapter 6
Certificate Revocation Lists
47
CRL Properties ...47General ...48
Parameters ...48
Entries ...49
Chapter 7
Secure Email Rules
51
Basic Secure Email Rules ...51Rule Conditions-Secure Email Rules ... 53
Where message is encrypted and cannot be decrypted ... 53
Where message is encrypted and can be decrypted ... 53
Where encryption certificate is invalid ... 54
Where message is not encrypted ... 54
Where message is signed and cannot be verified ... 55
Where message is signed and can be verified ... 56
Where message is not signed ... 56
Where message cannot be encrypted for any secure recipient: ... 56
Rule Actions-Secure Email Rules ... 57
Copy unknown certificates to database folder ... 57
Sign message with certificate ... 57
Encrypt message with certificate ... 59
Do not decrypt message ... 62
Advanced Secure Email Rules ... 62
Multiple Gateway-to-Gateway Encryption Partners ... 63
Gateway-to-Desktop Encryption Partners ... 63
About This Book and the Library
The User Guide provides conceptual information about MailMarshal SMTP. This book defines terminology and various related concepts.
Intended Audience
This book provides information for individuals responsible for understanding MailMarshal SMTP concepts and for individuals managing MailMarshal SMTP installations.
Other Information in the Library
The library provides the following information resources:
User Guide
Provides conceptual information and detailed planning and installation
information about MailMarshal SMTP. This book also provides an overview of the MailMarshal SMTP user interfaces and the Help.
MailMarshal Secure User Guide
Provides detailed information about how to configure and use the S/MIME secure email functionality in MailMarshal SMTP.
Help
Provides context-sensitive information and step-by-step guidance for common tasks, as well as definitions for each field on each window.
Conventions
The library uses consistent conventions to help you identify items throughout the documentation. The following table summarizes these conventions.
Convention Use
Bold • Window and menu items
• Technical terms, when introduced
Italics • Book and CD-ROM titles • Variable names and values • Emphasized words
Fixed Font • File and folder names
• Commands and code examples • Text you must type
• Text (output) displayed in the command-line interface Brackets, such as [value] • Optional parameters of a command
Braces, such as {value} • Required parameters of a command Logical OR, such as
value1 | value2
About Marshal
With new threats disrupting business, productivity and wrecking reputations every day, Marshal content security solutions take a proactive approach to identifying email and web vulnerabilities to protect over seven million international users in 17,000 companies from the risks of email and Internet-based threats.
Marshal Products
Marshal's Content Security solution, which includes MailMarshal SMTP, MailMarshal Exchange and WebMarshal, delivers a complete email and Web security solution to these risks by acting as a gateway between your organization and the Internet. The products sit behind your firewall but in front of your network systems to control outbound
documents and their content. By providing anti-virus, anti-phishing and anti-spyware protection at the gateway, Marshal's Content Security solution offers you a strategic, flexible and scalable platform for policy-based filtering that protects your network, and as a result, your reputation.
Contacting Marshal
Please contact us with your questions and comments. We look forward to hearing from you. For support around the world, please contact your local
partner. For a complete list of our partners, please see our website. If you cannot contact your partner, please contact our Technical Support team.
Telephone: +44 (0) 1256 848 080 (EMEA) +1 404 564-5800 (Americas) + 64 9 984 5700 (Asia-Pacific)
Sales Email: [email protected]
Support: www.marshal.com/support
Chapter 1
Introducing MailMarshal Secure
MailMarshal Secure is an additional module of MailMarshal SMTP that implements the S/MIME (Secure MIME) standard for encryption and signing of email messages using the Public Key Infrastructure. MailMarshal Secure can communicate securely with any other encryption product that uses the S/MIME standard; communication is not limited to MailMarshal sites.
What is S/MIME?
S/MIME is an industry standard method of protecting email privacy using the Public Key Infrastructure (PKI). MailMarshal Secure interoperates with other S/MIME aware products, whether server-based or workstation-based.
PKI begins with two digital Keys, known as the Public and Private Key. Public Keys are made freely available, while Private Keys are kept secret and secure. The Public Key can be contained in a digital certificate and distributed. A Certificate may be generated within MailMarshal, or issued by a trusted authority. The Keys are known as an “asymmetric pair”; messages encrypted using the Public Key can be read with the Private Key. Public Certificates are maintained in a database such as MailMarshal's Certificate Database. A Certificate may be exported into a file which is made available to sites with which S/MIME email will be exchanged.
PKI allows email to be processed in two ways, known as Encryption and Signing. They are often used together-a message may be both encrypted and signed.
Encryption
Encryption is the “scrambling” of a message so that it is illegible until decrypted. Typically email sent to a site will be encrypted with the recipient's Public Key (which any sender may have); such messages can only be decrypted by the recipient using their Private Key.
Signing
Signing involves processing a message using a Private Key, to generate a unique block of data known as the “signature”. The sender “signs” a message using her Private Key. This signature is sent with the original message. The recipient can verify that the message is unchanged and that it originated from the sender, by testing it using the sender's Public Key.
How Does MailMarshal Secure Work?
MailMarshal Secure allows the email administrator to set and enforce policies for the encryption, decryption, signing, and verification of S/MIME email messages. Within Server Properties, basic policies governing allowable standards of security are set. The policies are applied to email messages using an additional type of Rules, known as Secure Email Rules. These Rules are created and applied in the same way as standard
MailMarshal SMTP Rules.
MailMarshal Secure is also used to create, harvest, and manipulate the digital certificates used for S/MIME email. The security information may be stored in a software
cryptographic provider (such as the one supplied by default with Windows 2000), or optionally in a third-party cryptographic accelerator such as those supplied by nCipher.
Options for Using MailMarshal Secure
MailMarshal Secure can be used to encrypt messages from gateway to gateway, desktop to desktop, or gateway to desktop. Brief explanations of these options are given below. Details of the MailMarshal Rules required to implement these options may be found elsewhere in this Manual.
1. Gateway to Gateway: All encryption and decryption of messages is completed at the server. Internal networks are trusted for security purposes. This mode is easy to set up and run, because all setup and maintenance is done at the server. Users simply send and receive email. MailMarshal can stamp incoming encrypted messages as valid, and can also perform content checks on the messages. The basic rules given in Chapter 7, “Secure Email Rules,” support this method.
2. Desktop to Desktop: Encryption and decryption takes place at the email client (such as Microsoft Outlook). In this case, MailMarshal can still perform content checks if the messages are also encrypted with a certificate for which MailMarshal holds the private key. Messages for which MailMarshal does not hold the key may be passed through unscanned, or rejected, according to local policy.
3. Gateway to Desktop: MailMarshal can sign outbound messages with a “proxy certificate” so that the receiving email client recognizes the message as validly signed from the sending email address. MailMarshal must hold public keys for all external addresses to which messages are to be encrypted. This option is used where MailMarshal performs gateway encryption, but the remote recipient uses desktop encryption software. Example rules to support this method are given in Chapter 7, “Secure Email Rules.”
Online Help
MailMarshal provides online help for assistance during installation and use of the software. Help is accessed through the Help menu or by pressing the [F1] key.
Extended up-to-the-minute support is available on the Marshal website. The website at http://www.marshal.com features news, a support Knowledge Base, Discussion Forum, and maintenance upgrades.
Chapter 2
Configuration
Installing MailMarshal Secure
MailMarshal Secure is available on the MailMarshal CD-Rom or in the downloadable MailMarshal SMTP installation file. The product requires an S/MIME enabled License Key, available from Marshal.
MailMarshal Secure requires Windows 2000, Windows XP Professional, or Windows Server 2003, and MSDE or a Microsoft SQL server to host the Public Certificate Database.
To install the MailMarshal Secure module, run the MailMarshal installer from the Windows Control Panel. If MailMarshal is already installed, on the Welcome page select
Modify. On the Select Setup Type page, choose to install MailMarshal S/MIME Server. (For additional details of the installation process, please see the chapter “Installation” in the MailMarshal SMTP User Guide.)
After installation, open the License Info tab of Server Properties and enter the S/MIME enabled License Key.
Configuring MailMarshal Secure
Once the S/MIME module is installed and licensed, two tabs of Server Properties are used to configure this module: Secure Email and Internet Access.
Notes
It is very strongly recommended, for speed, security, and availability reasons, that the Certificate Database be installed on the MailMarshal Server computer. In some cases (for instance, a cluster installation) the Certificate Database can be created on a different server.
We recommend a 128 Bit Encryption version of the operating system. Some early international releases of Windows 2000 were only 40 bit. To check the encryption level of a machine, within Internet Explorer click on Help > About. The 'Cipher Strength' value shows the encryption level of the machine.
Server Properties: Secure Email
On this tab, check the box Enable Secure Email to enable MailMarshal Secure. .
Certificate Database
Click the button Choose Database to connect to a Certificate Database.
In the Create/Select Database dialog, enter the location of the SQL Server or MSDE computer where the database will reside. It is very strongly recommended for speed, security, and availability reasons that this be the MailMarshal server. The database will not grow large.
Click OK to return to the Secure Email tab.
Cryptographic Service Provider
Select a provider from the list. The Cryptographic Service Provider is the software or hardware used to store and manipulate Private Keys.
Default Key Exchange Algorithm
Select an algorithm from the list. This setting defines the level of encryption used when appending a key to an email message. The available choices may vary depending on the Cryptographic Service Provider selected. Higher encryption levels are more secure but will require additional processing resources.
Default Encryption Algorithm
Select an algorithm from the list. This setting defines the default level of encryption that will be used when Secure Email Rules are created. Select the highest level compatible with the software at other locations with which encrypted email is exchanged. The available choices may vary depending on the Cryptographic Service Provider selected.
Default Hashing Algorithm
Select an algorithm from the list. This setting defines the default hashing or
“thumbprint” that will be used for signing by Secure Email Rules. SHA-1 is preferred but other settings may be used where necessary for compatibility with remote locations.
Note
Changing Cryptographic Service Providers may cause Keys stored in the old Provider to be lost. This will occur if changing between software and hardware Providers, or if changing from a higher to a lower level of encryption. When changing Providers, you should be prepared to restore all Keys from backup (though this will not typically be necessary).
Security & Certificate Policies
Select a security level using the radio buttons. Alternatively, click Policies to view and change the options in force using the Security Policies dialog.
Security Policies dialog
This dialog allows selection of several settings governing the creation and application of Secure Email Rules.
Note
The Strict option selects a restrictive set of security policies, which would typically be used by a site requiring all email to be encrypted and signed with Certificates guaranteed by a third-party Certificate Authority. The Moderate option selects a looser set of policies, which would typically be used by a site using self-signed Certificates to encrypt and sign email for exchange with known and trusted partners. Custom allows a locally created set of policies to be created; however selecting the Strict or Moderate button resets any customizations.
The dialog has three tabs:
General
Permit generation of certificates:
When this option is checked, MailMarshal can create self-signed Certificates and also create “proxy” individual certificates on the fly. De-selecting (unchecking) this option is the more secure choice.
Permit exportable private keys:
Private Keys created when this option is checked can be exported to other products or locations. De-selecting (unchecking) this option is the more secure choice.
Allow manual editing of email addresses:
When this option is checked, email addresses associated with Certificates can be added, changed, and deleted. (Addresses which form part of the original Certificate cannot be edited.) De-selecting (unchecking) this option is the more secure choice.
Continue to use Certificate Revocation Lists:
This option is used to provide a default “grace” period for technical delays in retrieving CRL updates. Enter the grace period. A Certificate will still be usable during the grace period after the replacement time of the CRL. This setting may be overridden in the properties of each CRL (See below).
Algorithms
This tab allows selection of the order of preference in which algorithms will be used or exposed for each function (key exchange, encryption, and hashing). In general, the stronger (higher bit count) algorithms are preferred as more secure, but also require additional processing time and may raise compatibility issues. The selections made here affect the options available during Secure Email Rule creation.
Note
If keys are marked “non-exportable”, they cannot be backed up routinely. MailMarshal Secure offers the option to back up non-exportable keys once, when they are created.
For each algorithm type, select a specific algorithm and use the up and down arrows to set its place in the list. Click Delete to remove it from the list of usable algorithms. Click
Add to add any algorithm available from the selected Cryptographic Service Provider to the list. (Set the default choice for each algorithm using the drop-down boxes on the Secure Email tab of Server Properties.)
Processing
Expose algorithm capabilities on outbound email:
When this option is selected, MailMarshal will encode information on the algorithms it can use within outbound secure email messages. A remote server could use this information to determine the most secure settings to be used on mail between the two servers (See Below).
Mail administrator when private key certificates are due to expire:
When this option is selected, MailMarshal will monitor the upcoming expiry of Certificates and send email warnings to the administrator. Select the number of days prior to expiry when these warnings should start.
Retrieve new certificates from a designated LDAP servers when certificates are due to expire:
When this option is selected, MailMarshal will attempt to retrieve updated public-key Certificates to replace ones which are nearing expiry. Select the number of days prior to expiry when these attempts should start.
To configure groups for which automatic retrieval will occur, use the final page of the Certificate server LDAP connection wizard. See the chapter “LDAP Connections” in the MailMarshal SMTP User Guide.
Server Properties: Internet Access
This tab of Server Properties is used to define the path for HTTP and FTP connection to the Internet. This connection is used by MailMarshal Secure to retrieve certificate revocation and renewal information.
Preset Configuration
MailMarshal uses the configuration settings for the account under which the MailMarshal Controller service is running.
Direct access
No special configuration is required; the Internet is available from this computer without a proxy.
Proxy
MailMarshal connects to the Internet using the proxy server details provided. Only Basic Authentication is supported.
• Proxy Name: The name of the proxy server computer. This may be a local computer name, fully qualified domain name, or IP address.
• Port: The port number on which the proxy server accepts requests (typically port 8080).
• User Name: The user name may include NT domain information in “backslash” format (e.g. ourcompany\username).
• Password: The password associated with the user name (entered twice for confirmation).
Note
By default the Controller service runs under the Local System account. For this selection to be useful the Controller should be run using another account with administrator privilege.
Setting Up S/MIME Features
In addition to the configuration options selected in Server Properties, preparing MailMarshal Secure's S/MIME features for use involves three steps:
1.Create or import a Domain Certificate (also known as a Server Certificate) for each local domain that will use signing and/or encryption. The same certificate may be used to process email for several domains using Gateway-to-Gateway encryption. See Chapter 3, “Certificates.”
2.Exchange certificates with other sites. Since email messages will typically be encrypted and signed in both directions between two or more organizations, each must have the appropriate information to encrypt for, and validate signatures from, the other. See Chapter 3, “Certificates.”
3.Configure Secure Email Rules. A basic set of Secure Email Rules is required to ensure the security of encrypted links with other sites. See Chapter 7, “Secure Email Rules.”
S/MIME Repair Functions
The following functions are available on the All Tasks submenu of the Secure Email node of the Configurator. No harm can come from selecting any of these actions, although they may take some time to complete if a large number of Certificates are present.
Repair Certificates
This action checks the certificate information in MailMarshal's Certificate database against the information in the Certificates (which are stored in the selected Cryptographic Provider). The database is corrected if necessary.
Note
See Chapter 3, “Certificates,” and Chapter 4, “Private Keys,” for more information on these elements.
Repair Certificate Emails
This action checks the email addresses for each certificate in MailMarshal's Certificate database against the email addresses coded in the actual Certificates. The original values are restored.
Repair Certificate Key Containers
This action ensures that the Key references in MailMarshal's Certificate Database point to the correct Key containers in the Cryptographic Provider. This action may be useful where problems are encountered due to a change in Provider.
Repair Private Keys
This action checks the Private Key information for each Certificate in MailMarshal's Certificate database against the information in the Cryptographic Provider. This action may be useful where Private Keys may have been changed or imported into the Provider by other applications.
Chapter 3
Certificates
Certificates are used to store and exchange Public and Private Keys.
Typically certificates containing Private Keys are generated locally or requested from a , then stored securely. They are generally only exported for backup purposes. These Certificates contain the information needed to decrypt email, or to sign email from a site. Certificates containing Public Keys may be imported from other sites, or exported from MailMarshal for use on other sites. These Certificates contain the information needed to encrypt email for sending to a site, or to validate the signature on email from a site.
Working with Certificates
Select the node Certificates in the left pane of the Configurator to work with S/MIME Security Certificates. When the node is selected, a listing of Certificate folders is shown in the right pane.
A certificate is shown with a lock icon if it has an associated Private Key. A certificate shown with a red border indicates that the Private Key cannot be found or is invalid.
Right-click on the Certificates node and click New > Folder to create a new Certificate Folder.
Right-click on the Certificates node or a Certificate Folder and click New > Certificate
to create a new Certificate (if this action is permitted by the Security Policies). Choose
New > Advanced Certificate to see the full range of options. See Creating a New Certificate, below, for details.
Backing Up Certificates
This is very important. Keep a copy of all Certificates and the associated Private Keys. Export a Certificate to a file by right-clicking on it then clicking Export.
The exported information should be kept securely (e.g. on a floppy disk in a safe). If the backup includes a Private Key, the password for the backup file should be kept separate from the file itself.
Creating a Certificate Folder
Right-click on the node Certificates and click New > Certificate Folder to create a Certificate folder, which will appear in the Configurator under the Certificates node. Enter the name of the folder to be created.
Note
When a folder has the status “Held”, certificates in that folder will not be used for email encryption. This allows for importation and storage of certificates which have not yet been verified manually. Once approved for use, Certificates should be moved to other folders.
If the box Certificates placed in this folder will not be considered for use is checked, Certificates placed or imported into this folder will not be available for email processing. This allows for importation and storage of Certificates which have not be manually verified as trustworthy.
If this box is checked when a Folder is created, the Folder will be notated as “Held” when shown in the left pane of the Configurator.
Click OK to create the folder.
Creating a New Certificate
Right-click on the Certificates node or a Certificate Folder and click New > Certificate
to create a new S/Mime Security Certificate (if this action is permitted by the Security Policies). Choose New > Advanced Certificate to see the full range of options. The Certificate may be self-signed. Alternatively, if the MailMarshal certificate database contains a CA certificate with the necessary attributes, the new Certificate may be signed using this CA Certificate.
The General and Usage/Finish pages of the Wizard are always shown. When Advanced Certificate is selected, the Extensions and Subject Names pages are also shown.
General
• Common name (required field): This field typically shows the issuer name or certificate purpose.
• Subject email: This may be an individual email address or a domain email address. The Certificate will be valid to encrypt and sign email related to this address.
Note
In most cases, for the Certificate to be used by MailMarshal the subject email should be a domain email address (see below for a definition). Use the arrow to the right of the field to enter the local part of a domain email address.
• Organization name: the name of the organization which will use this certificate. • Private key: Select a key from the list, or create a new one by clicking Create Key. • Folder: Select the Certificate Folder into which to place this Certificate. (If a folder
was selected earlier, its name will be entered in this field and cannot be changed.) A new folder may also be created - enter a name for it.
• Validity dates: Select starting and ending validity dates for this Certificate. The default is a validity of one year beginning immediately.
Issued by: Select the authority for the new certificate to be issued by. The choices in this list will include self-signing and any Certificates in the database marked as CA certificates that include a Private Key. (See Below).
Note
To allow the Certificate to be used immediately, do not place it in a Folder marked “Held”.
Extensions
This page allows addition of optional information to the Certificate. It is only shown in the Advanced version of the wizard.
• Key Usage: Check the boxes corresponding to the purposes for which this
certificate is to be used. By default the first four boxes are checked as these items are required for MailMarshal to use the Certificate.
• Digital Signature: Certificate can be used to “sign” a message assuring its origin and integrity.
• Non-Repudiation: Certificate can be used to guarantee acceptance of a transaction (e.g. to provide a receipt).
• Key Encryption: Certificate can be used to encrypt a key for inclusion with an email. • Data Encryption: Certificate can be used to encrypt the data in an email.
• Key Agreement: Certificate can be used to agree on a private key over insecure networks.
• Constraints: Select whether this Certificate is to be recognized as coming from a Certificate Authority. If it is, specify the “path length” or number of intermediate certificates in a chain of trust which it can guarantee.
• Email Addresses: This list should contain any email addresses (in addition to the domain email address) for which this Certificate should be valid. Click Add to add an entry to the list. Select an entry and click Delete to remove it from the list. Double-click an entry to edit it. When adding or editing an address, use the arrow to the right of the field to enter the local part of a domain email address.
• CRL Distribution Point: Optionally enter one or more URLs where Certificate Revocation Lists affecting this Certificate may be found.
Subject Names
This page shows a list of all text fields within the “Subject” of the certificate. It is only shown in the Advanced version of the wizard.
Select any existing field to edit or delete it. To edit, click Edit then modify the text in the edit field. To delete the selected field click Delete.
Note
This option must be selected if the Certificate is to be used to generate Proxy Certificates.
To add a new field, choose an available field name from the drop-down list, enter the desired text in the edit field, then click Add.
Certificate Usage/Finish
This page shows several parameters which affect the purposes for which the Certificate may be used.
Trust
Choose the level of trust for the certificate. If the new Certificate is signed by a CA Certificate, typically it should inherit trust from the issuer.
• Always Trusted allows the certificate to be used for encryption or signing of messages (subject to the expiry or revocation of the certificate).
• Never Trusted will cause messages related to this certificate to be rejected.
• Inherits Trust from Issuer (only available for CA issued certificates) bases the trust level on the trust for the root or intermediate certificate to which this certificate is chained (See Below).
Preferred Use
Check the appropriate boxes to indicate whether the certificate is preferred for encryption and/or signing purposes.
For Messages Signed with this certificate:
Choose whether to leave or strip (remove) a signature based on this key when it is found on incoming email.
• Leave the signature: The signature is left on the email delivered to the client. • Strip the signature (default action): The signature is stripped from all incoming email
signed with this certificate.
• Strip the signature when domain signed: The signature is stripped from incoming email signed with this certificate when it is “domain signed” (e.g. signed by another MailMarshal gateway).
The signature should be left in desktop to desktop encryption situations so it can be verified by the client software. Otherwise it may safely be stripped (since MailMarshal will have verified it).
Certificate Tasks
Double-click any Certificate to view and edit its properties in the Certificate Properties dialog.
Right-click a Certificate Folder and click Import to import one or more Certificates into this folder from a file. (This includes CA Certificates which have been requested using MailMarshal's Certificate Request facility.)
Note
If the “preferred” certificate is not usable (e.g. because it is out of date), another certificate for the same domain will be used, if available. This may cause an encrypted message to be undecryptable if the recipient does not have the appropriate key for the other certificate.
When importing a Certificate, you may be prompted to choose whether the certificate is trusted. When importing a Certificate with a Private Key, you will be prompted for a password.
Right-clicking a Certificate presents the following options. Not all options are available for every Certificate.
• Export: Export this certificate to a file. (This action will only be available for some Certificates.) See below for export options.
• New Proxy Certificate: Generate a new Proxy Certificate from a Domain Certificate. This action will only be available for Certificates marked as CA Certificates.
• Proxy Certificates: Search for all Proxy Certificates generated from this Certificate. The results will be shown in the Certificate Search Results.
• Reload Private Key: Attempt to re-synchronize the Private Key for this Certificate with the Encryption Provider.
• Go To Private Key: Find the related Key in the Private Keys node.
• Delete: Delete this certificate. Deleting the Certificate does not affect the Private Key.
Checking Imported Certificates
A certificate contains the encryption key for the related addresses. If the wrong certificate is installed, encryption may not function correctly and security may be broken.
To check that the correct certificate is installed, compare the “thumbprint” of the certificate against the thumbprint of the certificate installed at the other site. In the MailMarshal Certificate Manager, select the certificate to be checked then click View Details. Two versions of the thumbprint, SHA1 and MD5, are given if available. Confirm the thumbprint string with the administrator or user at the other site. Perform this action for both sites' certificates.
Warning
Before deleting a Certificate ensure that no Secure Email Rules use it (i.e. it is not required for decryption or signing of messages).
Exporting Certificates
To export a Certificate (for backup or to exchange with another site), right click on a Certificate and select Export to use the Export Certificate Wizard.
The first page of the wizard gives several important notes and warnings. Click Next to continue.
In the next page (Format), select a file format for the export.
• X.509 format can be used for single certificates without private keys.
• PKCS#7 format can be used for multiple certificates or chains of certificates. • PKCS #12 format can be used to export certificates with their associated private
keys (if the keys are exportable), including chains of certificates.
In the next page (Details), check Base64 Encoding to export the certificate in plain text format. This format may be required by some other software.
To include all certificates in the chain of trust (PKCS#7 and PKCS#12 format only), check the box Include all certificates in certification path. Use this option to ensure that your encryption partner has everything they need to verify the trust of your certificate.
If you selected PKCS #12 format, enter (and confirm) a password for the certificate. This should be a long, non-obvious password.
Note
Private keys should only be exported for backup or other defined need. They should not be sent to ordinary encryption partners. Keep PKCS #12 Certificates and their passwords in separate secure locations.
In the next page (Details), check Base64 Encoding to export the certificate in plain text format. This format may be required by some other software.
To include all certificates in the chain of trust (PKCS#7 and PKCS#12 format only), check the box Include all certificates in certification path. Use this option to ensure that your encryption partner has everything they need to verify the trust of your certificate.
If you selected PKCS #12 format, enter (and confirm) a password for the certificate. This should be a long, non-obvious password.
In the final page of the wizard, information on the certificate to be exported appears in the lower pane.
Enter or browse to a file location and name. Click OK to export the certificate.
Certificate Search
To search for a particular certificate or for all certificates with a certain expiry date, right-click on the Certificates node then select Find to see the Search for Certificates dialog. If a certificate with a particular issuer is selected, the search will be limited to Certificates with that issuer.
When all conditions have been entered, click OK to begin the search. Results will be shown in the Certificate Search Results node (shown in the right pane of the Configurator).
Note
All entries on all tabs of this dialog are optional; however at least one choice must be made for any results to be returned.
Main
• Subject Contains: Fields in the “Subject” area of the certificate will be searched for this string. (This will include the issuer, common name, and other detail fields.) The wildcards * and ? may be used.
• Email Address: Complete addresses (as visible on the General tab of Certificate Properties) will be searched for using this string. The wildcards * and ? may be used. • Expiry date and time (optional): (use the pull-down and spin boxes to change the
entries). Typically this option will be used to find certificates nearing expiry.
Conditions
Select the desired attributes of the certificate to search for by checking the boxes. Where detailed information must be entered, click the red hyperlinks in the lower pane to enter it.
• Trust Type: choose the trust types to search for using the Trust Types dialog. • Private Key: select this option to limit the search to certificates which have a Private
Key.
• Self Signed: select this option to limit the search to certificates which are Self Signed.
• Certificate Authority: select this option to limit the search to certificates which are signed by a Certificate Authority (including MailMarshal self-signed CA certificates). • Proxy: select this option to limit the search to Proxy Certificates (individual address
certificates created from a Domain Certificate).
Status
Limit the certificates to search for by checking any of the boxes. To choose to search on the presence or absence of the attribute, click the red hyperlinks in the lower pane to use the Certificate Status dialog.
• Valid: choose to limit the search to valid or invalid certificates.
• Trusted: choose to limit the search to trusted or untrusted certificates. • Verified: choose to limit the search to verified or unverified certificates. • Revoked: choose to limit the search to revoked or unrevoked certificates.
• Missing CRL: choose to limit the search to certificates which have (or are missing) a CRL.
• Missing Issuer: choose to limit the search to certificates without (or with) a named issuer.
• CRL Expired: choose to limit the search to certificates whose Certificate Revocation List has expired (or not expired).
• CRL Distribution Point: choose to limit the search to certificates which have or lack a CRL Distribution Point.
Trust Search Options
This dialog allows the Certificate search results to be limited to Certificates with
particular trust characteristics. Select one or more trust types by checking the appropriate boxes.
• Trusted: certificates which are marked as implicitly or always trusted.
• Not Trusted: certificates which are marked as never trusted, or implicitly not trusted.
• Inherited: certificates which have been set to inherit their trust level from a “chain of trust” (intermediate and/or root certificates).
Certificate Properties
This dialog has four tabs which allow many properties of a Certificate to be viewed and edited.
General
The issuer and validity dates, type and status, and location of the Certificate are shown. A list of the email addresses for which the Certificate can be used is given.
If the Certificate is used for domain encryption or signing, a domain email address will be shown in the list. If permitted by the Security Policies, this list can be edited. Click Add to add a new address to the list. Double-click any address to edit it. Highlight an address and click Delete to remove it. Addresses which cannot be edited (because they are
permanently encoded in the Certificate) are indicated by a “no writing” icon. Use the arrow to the right of the field to enter the local part of a domain email address.
Usage
This tab shows several parameters which affect the purposes for which the Certificate may be used.
Trust
View or choose the level of trust for the certificate. Note that the trust level for some individual and domain certificates may depend on the level of trust granted to intermediate certificates.
• Always Trusted allows the certificate to be used for encryption or signing of messages (subject to the expiry or revocation of the certificate).
• Never Trusted will cause messages related to this certificate to be rejected.
• Inherits Trust from Issuer (only available for CA issued certificates) bases the trust level on the trust for the root or intermediate certificate to which this certificate is chained.
Preferred Use
Check the appropriate boxes to indicate whether the certificate is preferred for encryption and/or signing purposes.
For Messages Signed
Choose whether to leave or remove a signature based on this key when it is found on incoming email. Typically the signature will be removed in gateway to gateway encryption situations (since MailMarshal has verified it). The signature should be left in desktop to desktop encryption situations so it can be verified by the client software.
Certificate Details
This tab of Certificate Properties shows detailed information about the certificate. Select any item on the top pane to see details in the bottom pane.
Certification Path
The upper pane of this tab shows the “chain of trust” through which this certificate is issued. The chain may include intermediate and root certificates from a Certificate Authority, as well as the certificate itself.
For instance, MailMarshal Proxy Certificates are chained to the appropriate Domain Certificate.
If other certificates appear in the chain of trust, select one and click Properties to view its details in a new Certificate Properties dialog.
Note
If the “preferred” certificate is not usable (e.g. because it is out of date or revoked), another certificate for the same domain will be used, if available. This may cause an encrypted message to be undecryptable if the recipient does not have the appropriate key.
Proxy Certificates
A Proxy Certificate is a S/MIME Security Certificate for a specific user in a domain which has a Domain Certificate. These certificates may be used in desktop-to-desktop encryption for the specific user. A Proxy Certificate can be generated from any Domain Certificate which is marked as a CA Certificate.
See the information on Secure Email Rule Actions for uses of Proxy Certificates.
New Proxy Certificate
In order to be used to create a Proxy Certificate, the parent Certificate must be marked as a CA certificate and must contain one of the domain email addresses for the domain. Enter an email user name to be used as the subject of this Certificate and click OK. The Proxy Certificate will be placed in the Certificate folder Proxy Certificates (which will be created if necessary).
The error “Invalid ascendant email address” indicates that the parent Certificate is not a valid domain Certificate for the email address entered.
Domain Email Address
In order for a Certificate to be fully usable for Domain Encryption, Domain Signing, and creation of Proxy Certificates, it must have a special subject email. The three acceptable email addresses for these purposes are:
Note
MailMarshal Secure will generate Proxy Certificates on the fly and retain them for future use. It is not normally necessary to create Proxy Certificates manually. Proxy Certificates require a specific Domain Certificate for each domain supported.
Domain-Confidentiality-Authority@domain
Domain-Signing-Authority@domain
Review-Authority@domain
Note
When adding or editing an email address, use the arrow to the right of the field to enter the local part of a domain email address. Add the appropriate domain portion. Within MailMarshal's Certificate dialogs, the local part of these email addresses may also be entered in abbreviated form as <dca>, <dsa>, and <ra>. MailMarshal will use these
shorthand versions of the email addresses when displaying the Certificate in the main Configurator view. The full addresses are shown in the Certificate Properties dialog. If a Domain Certificate has been created without a suitable email address, it may be possible to add the address later. See “Certificate Properties” on page 32.
Chapter 4
Private Keys
This node of the Configurator shows all Private Keys which have been created or imported in MailMarshal, and other keys found in the Cryptographic Service Provider. Private Keys are used to sign and decrypt email.
Backing Up Keys
This is very important. Keep a copy of all Private Keys and the associated Certificates. Export a Private Key to a file by right-clicking on it then clicking Export.
The exported information should be kept securely (e.g. on a floppy disk in a safe). The file password should be kept in a separate secure location.
IMPORTANT
The security of your encrypted email depends on keeping Private Keys secure.
Note
By default MailMarshal creates Private Keys marked “non-exportable” (for security reasons). When a non-exportable key is created by MailMarshal, you are given the option to make a backup immediately after creating the Key. There is no other opportunity to back up non-exportable keys. The choice to create exportable Private Keys is made on the Security Properties dialog reached from the Secure Email tab of Server Properties.
Private Keys Tasks
A Key shown in red indicates that the Key is not validly present in the current Cryptographic Provider.
A key shown in blue indicates that the Key is present in the Cryptographic Provider but is used only by other applications and not by MailMarshal. (These Keys are available for use by MailMarshal.)
Double-click any key in the right pane (or in a sub-node) to see a list of all Certificates which use this key.
Right-click on the node then choose New > Private Key to open the Create Key dialog. Choose Import to import a Key created elsewhere.
Right-click on any private key to select from the following options: • Properties: See detailed information about this Key.
• New > Certificate: Create a certificate using this Key. • Delete: Delete the Key.
Export Private Key
This dialog is used to export Private Key information to a file. The file may be used as a backup. There is normally no reason to share this file with anyone inside or outside the organization.
Select a location and name for the export file. Enter a password (used to import the file).
Warning
Deleting a private key will render any Certificates based on it useless. MailMarshal will raise a warning if any Certificates depend on the Key.
The exported information should be kept securely (e.g. on a floppy disk in a safe). The file password should be kept in a separate secure location.
Create Key
Use this dialog to create a new Private Key for use with S/MIME Certificates (See Below).
A unique name is provided. You may edit it but for clarity it should not be the same as any other Private Key name in the database.
Select a key size from the list. Larger keys are more secure in general, but may cause compatibility problems.
Enter a description for the key if desired.
The checkbox Key is not exportable controls whether the Key can be exported to a file later. If the Security Policies allow exportable private keys, this box will be enabled so that you can chose whether to make the key exportable. If the Security Policies do not allow exportable private keys, this box will be disabled and the new key will not be exportable.
Note
For security reasons, MailMarshal creates Private Keys marked “non-exportable” by default. When a non-exportable key is created by MailMarshal, you have the option to make a backup immediately after creating the Key. There is no other opportunity to back up non-exportable keys. The choice to create exportable Private Keys is made on the Security Properties dialog reached from the Secure Email tab of Server Properties.
Click OK to create the key. It will be stored using the selected Cryptographic Service Provider and will appear in the list of Private Keys.
Private Key Properties
This two tabs of this dialog shows information about a Private Key held by MailMarshal.
Private Key
This tab allows the name and optional description of the key to be viewed and changed. The date of creation, the number of certificates using the key, and whether the key can be exported are also shown.
Details
The key algorithm, unique container name, and associated public key are shown.
Important
If Security Policies have been set to mark Private Keys “not exportable”, you are given the option to back up the key to a file. This will be the only opportunity to make a copy of the key. Best practice is to make a backup and store it securely (e.g. on a floppy disk in a safe).
Chapter 5
Certificate Requests
Certificate Requests (also known as Certificate Signing Requests) are used to provide information to a Certificate Authority (CA). The CA undertakes to guarantee the identity of the organizations using Certificates it has issued. This may be desired to guarantee message security against spoofing.
To obtain a Certificate from a CA, generate a Certificate Request. Send the Request (along with any other required information) to a CA. Be sure to indicate to the CA that the intended purpose of the Certificate is domain email encryption and signing. The Certificate Requests node of the Configurator shows any outstanding requests for new Certificates which have been generated through MailMarshal.
Right-click and select New > Certificate Request or New > Advanced Certificate Request to generate a request for a new certificate.
When the new Certificate is received, import it into a certificate folder. For details of this procedure, see Chapter 3, “Certificates.”
In the right pane, double-click on any Certificate Request to view its properties.
Right-click on a Certificate Request and click Export to send it to a file or the Windows clipboard.
Creating a Certificate Request
Right-click the Certificate Requests node and select New > Certificate Request or
Before creating the request, review the requirements and costs to have the request processed by the CA.
• Common name (required field): Typically this name shows the user and intended function of the Certificate.
• Subject email: This may be an individual email address or a domain email address. The Certificate will be valid to encrypt and sign email related to this address. See “Domain Email Address” on page 34.
• Organization name: the name of the organization which will use this certificate. (By default MailMarshal inserts the organization name entered in the configuration wizard.)
• Private key: Select a key from the list, or create a new one by clicking New Key.
Note
In many cases (where S/MIME email is to be exchanged between a limited number of sites which trust each other), a self-signed Certificate is adequate. Self-signed Certificates can be created quickly and at no charge using MailMarshal's Certificate system - see Chapter 3, “Certificates.” MailMarshal's proxy certificate capabilities can only be used with self-signed Certificates.
Extensions
This page of the Advanced Certificate Request wizard allows selection of some parameters which determine how the certificate can be used.
Key Usage
Check the boxes corresponding to the purposes for which this certificate is to be used. By default the first four boxes are checked as these items are required for MailMarshal to use the Certificate.
• Digital Signature: Certificate can be used to “sign” a message assuring its origin and integrity.
• Non-Repudiation: Certificate can be used to guarantee acceptance of a transaction (e.g. to provide a receipt).
• Data Encryption: Certificate can be used to encrypt the data in an email.
• Certificate Signing: Certificate can be used to verify the trust of another Certificate. • Key Agreement: Certificate can be used to agree on a private key over insecure
networks.
Email Addresses
This list should contain any email addresses (in addition to the domain email address) for which this Certificate should be valid. Click Add to add an entry to the list. Select an entry and click Delete to remove it from the list. Double-click an entry to edit it.
Subject Names
This page of the wizard shows a list of all text fields within the “Subject” of the certificate.
Select any existing field to edit or delete it. To edit, click Edit then modify the text in the edit field. To delete the selected field click Delete.
To add a new field, choose an available field name from the drop-down list, enter the desired text in the edit field, then click Add.
Finish/Export
The Certificate Request is now ready to be sent to a Certificate Authority. Choose whether to copy your request to the Windows clipboard (e.g. for transfer to a Web form) or to a file (e.g. for later submission or attachment to an email).
If copying the request to a file, select the file format. Enter or browse to the file name to be used.
Chapter 6
Certificate Revocation Lists
Certificate Revocation Lists (CRLs) are issued by Certificate issuers to invalidate
Certificates before their expiration date. Generally this happens when the Certificate is no longer trustworthy (e.g. because it has been stolen). Best practices for strict security require each Certificate to have a CRL which has regular updates and can be accessed from one or more CRL Distribution Points.
This node is used to import and manage CRLs for use by MailMarshal's Secure Email Rules.
For each CRL, MailMarshal displays the name, issue date, next issue date, and automatic reload status.
To view additional information and settings, double-click on any CRL to view the CRL Properties dialog.
CRL Properties
General
This tab shows the issuer information, date received, date of update, date of next update, and expiry date for this CRL.
Parameters
This tab shows information about updating of this CRL.
The expiry delay defines the length of time for which a Certificate will still be usable after the replacement time of the CRL. This option is used to provide a “grace” period for technical delays in retrieving CRL updates. Enter a grace period.
• Auto Update: The CRL will attempt to update from the distribution point automatically. Click Update Now to attempt update immediately.
• Distribution point URLs: These URLs will be used by the update process to retrieve CRL updates. If a CRL distribution point URL is included in a certificate, it will be entered in the list automatically when the certificate is imported. Additional distribution points may be entered by hand using the Add button.
Where more than one distribution point URL is entered, use the checkbox next to each URL to determine which URL is used.
Entries
This tab shows a list of the serial numbers of Certificates which have been revoked by this CRL.
Note
The setting entered here overrides the default setting entered on the General tab of Security Policies. If the setting here is 0 (zero), the default value from Security Policies will be used.
Chapter 7
Secure Email Rules
MailMarshal controls S/MIME encryption and signing using Rules which are maintained in the same way as content checking rules. When MailMarshal Secure is installed and enabled, creation of Secure Email Rules is enabled in the Rule Wizard.
Please refer to the chapter “Rulesets and Rules” in the MailMarshal User Guide for basic information on creating and editing Rules.
Basic Secure Email Rules
The following Ruleset entitled “Encryption with OtherCompany” contains a basic set of rules required to ensure that all email between the two sites is encrypted, signed, and verified. More complex rules are possible (especially if third-party CA Certificates are in use), but this set should be regarded as a minimum for secure communications.
The Ruleset is created with no common User Matching entries.
1.The first two rules specify that outgoing messages are to be encrypted and signed, and state what should happen if encryption cannot be completed:
When a message arrives
Where addressed to 'othercompany.com'
Sign message with an opaque domain certificate
When a message arrives
Where addressed to 'othercompany.com'
Where message cannot be encrypted for any secure recipient Send a 'Can't Encrypt' notification message
and move the message to 'Encrypt Problems'
2.The next three rules check that incoming messages are validly encrypted and signed, and warn the user (or other appropriate person) if they are not. Warning could be by stamping or by email notification.
When a message arrives
Where addressed from 'othercompany.com'
Where message is not encrypted
Send a 'Not Encrypted' notification message
and pass the message to the next rule for processing When a message arrives
Where addressed from 'othercompany.com'
Where message is not signed
Stamp message with 'Message NOT signed'
and pass the message to the next rule for processing When a message arrives
Where addressed from 'othercompany.com'
Where message is signed and cannot be verified due to 'no certificate' or 'altered' or 'not trusted' or 'revoked'
Stamp message with 'Message NOT signed'
and pass the message to the next rule for processing
3.The next rule blocks any email that MailMarshal can't decrypt. If MailMarshal cannot decrypt the message it will be unable to check the contents.
When a message arrives
Where addressed from 'othercompany.com'
Where message is encrypted and cannot be decrypted Send a 'Can't Decrypt' notification message and move the message to 'Encrypt Problems'
Note
Rule Conditions-Secure Email Rules
This section includes detailed information on the Rule Conditions available within Secure Email Rules. User Matching conditions are the same as those available in Standard Rules.
Where message is encrypted and cannot be decrypted
By default, MailMarshal attempts to decrypt all encrypted messages. Use this condition to detect and block messages that MailMarshal cannot decrypt and check. This condition triggers when both of the following are true:
• firstly, a message has been encrypted by someone else. In the case of an incoming message that “someone else” may be another MailMarshal server. In the case of an outgoing message it may be a user within your company, possibly using the
encryption features in an email client such as Microsoft Outlook
• secondly, MailMarshal cannot decrypt the message (this occurs when the message was encrypted using a certificate for which MailMarshal does not hold the Private Key). Typically, MailMarshal has private decryption keys only for the site's server certificates..
Where message is encrypted and can be decrypted
This condition can be used in conjunction with the previous condition (e.g. when the site wants to stamp incoming encrypted email to indicate its secure status). The condition will trigger when
• a message has been encrypted using the S/MIME protocol, and • MailMarshal has a private key for the message and can read it.
Note
If MailMarshal cannot decrypt a message, then it cannot scan it to check its content. Most companies will want to block email that cannot be decrypted by the
Where encryption certificate is invalid
This condition will trigger when a message can be decrypted, but the Certificate used does not meet best security criteria. The criteria which may trigger this condition are:
• Certificate Expired: The validity period of the Certificate has passed, or has not yet started.
• Certificate Revoked: The Certificate has been revoked by the issuer (included in a Certificate Revocation List).
• Certificate Not Trusted: The Certificate (or a Certificate above it in the chain of trust) has been marked as “not trusted” by the administrator.
• Certificate Not Verified: The Certificate cannot be determined to be valid. E.g. a certificate above it in the chain of trust may be missing, or it may be farther down the chain of trust than is allowed.
• Certificate Invalid: Several issues may trigger this factor. E.g. if strict policies are enabled, it may not have a CRL or the CRL may have expired.
If a message triggers this condition, typically the sender would be notified. The message could be refused, or stamped with a notice about the invalid certificate and delivered.
Where message is not encrypted
This condition is often used to double-check that all email from another site is secure. For example, another site may accidentally stop encrypting the email that it is sending, or the unencrypted email might be spoofed.
Where message is signed and cannot be verified
This condition will trigger when the signature in the message matches the options set in the Signature Verification dialog box.
A number of sub-conditions are available within this condition. More than one Rule could be implemented to inform administrators and recipients about the various outcomes.
• No certificate to verify with: The signature on a message cannot be checked because no matching certificate was found.
• Message has been altered: The content of the message has been changed since it was signed. (This may have occurred intentionally or accidentally.)
• Signing certificate has expired: The message has no valid signature. The signing certificate, or a certificate in the chain of trust, has expired (or has a starting validity date in the future).
• Signing certificate is not trusted: The certificate, or a certificate in the chain of trust, has been marked as distrusted by the administrator.
• Signing certificate could not be verified: MailMarshal has been unable to check the trust of the certificate (e.g. the certificate or its root are not in the database, or the email address for the sender does not match the address set up for the certificate).
