ciphermail email encryption gateway administration guide · openpgp and pdf encryption. s/mime and...

CIPHERMAIL EMAIL ENCRYPTION

Ciphermail GatewayAdministration Guide

December 13, 2016, Rev: 10215

Copyright © 2008-2016, ciphermail.com.

Acknowledgements: Thanks goes out to Andreas Hödle for feedback.

CONTENTS CONTENTS

Contents

1 Introduction 6

2 Setup 6

3 Network 73.1 Network interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Hostname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.3 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.4 Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.5 NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 MTA setup 114.1 Main settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2 Advanced settings . . . . . . . . . . . . . . . . . . . . . . . . . . 144.3 sasl passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.4 MTA config file . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.5 RBL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.5.1 Static black-list . . . . . . . . . . . . . . . . . . . . . . . . 174.5.2 Static white-list . . . . . . . . . . . . . . . . . . . . . . . . 18

4.6 Email forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.7 Header checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.8 SMTP transports . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 Users 215.1 User preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.1.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.1.2 S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.1.3 PGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.1.4 PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.1.5 Password (R) . . . . . . . . . . . . . . . . . . . . . . . . . 275.1.6 Encryption subject trigger . . . . . . . . . . . . . . . . . . 285.1.7 Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2 Advanced settings . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2.2 S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2.3 PGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2.4 PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.2.5 Encryption header trigger . . . . . . . . . . . . . . . . . . 355.2.6 Signing header trigger . . . . . . . . . . . . . . . . . . . . 365.2.7 Signing subject trigger . . . . . . . . . . . . . . . . . . . . 375.2.8 Password . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.2.9 One time password (OTP) . . . . . . . . . . . . . . . . . . 385.2.10 Security info . . . . . . . . . . . . . . . . . . . . . . . . . 385.2.11 Subject filter . . . . . . . . . . . . . . . . . . . . . . . . . 385.2.12 CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.2.13 Other . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.3 Global advanced settings . . . . . . . . . . . . . . . . . . . . . . 395.3.1 Security info . . . . . . . . . . . . . . . . . . . . . . . . . 39

2

CONTENTS CONTENTS

5.3.2 Subject filter . . . . . . . . . . . . . . . . . . . . . . . . . 405.4 Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.5 SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.6 Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.7 PDF settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.7.1 Cover page . . . . . . . . . . . . . . . . . . . . . . . . . . 445.7.2 Attachments . . . . . . . . . . . . . . . . . . . . . . . . . 445.7.3 Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.7.4 Other settings . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.8 Webmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.8.1 Webmail settings . . . . . . . . . . . . . . . . . . . . . . . 465.8.2 Webmail tunnel certificate . . . . . . . . . . . . . . . . . . 47

6 Domains 48

7 Templates 48

8 Certificates 518.1 Importing Certificates . . . . . . . . . . . . . . . . . . . . . . . . 538.2 Importing keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538.3 Download certificates and keys . . . . . . . . . . . . . . . . . . . 55

9 S/MIME 559.1 PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559.2 X.509 certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . 559.3 Revocation checking . . . . . . . . . . . . . . . . . . . . . . . . . 58

10 Certificate selection 5810.1 Encryption certificate selection . . . . . . . . . . . . . . . . . . . 5810.2 Signing certificate selection . . . . . . . . . . . . . . . . . . . . . 6010.3 Additional certificates . . . . . . . . . . . . . . . . . . . . . . . . 60

11 Certificate Revocation List (CRL) 61

12 Certificate Trust List (CTL) 62

13 Certificate Authority (CA) 6413.1 Create new CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6513.2 CA settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6713.3 Certificate Request Handlers . . . . . . . . . . . . . . . . . . . . 68

13.3.1 built-in certificate request handler . . . . . . . . . . . . . . 6913.3.2 delayed built-in certificate request handler . . . . . . . . . 69

13.4 Create new end-user certificate . . . . . . . . . . . . . . . . . . . 6913.5 Select default CA . . . . . . . . . . . . . . . . . . . . . . . . . . . 7113.6 Pending requests . . . . . . . . . . . . . . . . . . . . . . . . . . . 7213.7 Bulk request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7213.8 Create CRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7213.9 Send certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

3

CONTENTS CONTENTS

14 OpenPGP 7714.1 Importing keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7714.2 Creating keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7814.3 Search keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7814.4 Key servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8014.5 Key details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8014.6 Key trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8014.7 Publish public key . . . . . . . . . . . . . . . . . . . . . . . . . . 8014.8 Email addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

14.8.1 domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8114.9 Revoke key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8114.10Key selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

14.10.1Email encryption key . . . . . . . . . . . . . . . . . . . . . 8214.10.2Email signing key . . . . . . . . . . . . . . . . . . . . . . . 83

15 PDF encryption 8515.1 Encrypted PDF message . . . . . . . . . . . . . . . . . . . . . . 8615.2 Replying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

16 DomainKeys Identified Mail (DKIM) 89

17 Data Leak Prevention (DLP) 91

18 SMS gateway 9118.1 Clickatell transport . . . . . . . . . . . . . . . . . . . . . . . . . . 91

19 Mail Queues 92

20 Logging 94

21 Administrators 9421.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

22 Backup and restore 9722.1 System backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9722.2 Backup configuration . . . . . . . . . . . . . . . . . . . . . . . . . 97

22.2.1 SMB share settings . . . . . . . . . . . . . . . . . . . . . 9722.2.2 Automatic backup . . . . . . . . . . . . . . . . . . . . . . 9822.2.3 Other . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

23 Log export 9823.1 Log export config . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

23.1.1 SMB share settings . . . . . . . . . . . . . . . . . . . . . 10023.1.2 Automatic log export . . . . . . . . . . . . . . . . . . . . . 10023.1.3 Other . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

24 Reporting 10224.1 Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

4

CONTENTS CONTENTS

25 SSL/TLS 10225.1 Web GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10225.2 SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10425.3 CSRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

25.3.1 CSR manager . . . . . . . . . . . . . . . . . . . . . . . . 10525.3.2 Certificate request procedure . . . . . . . . . . . . . . . . 105

26 Remote monitoring 10726.1 Monitoring configuration . . . . . . . . . . . . . . . . . . . . . . . 107

27 Certificate request by mail 10827.1 Certificate request by mail reply templates . . . . . . . . . . . . . 109

28 Proxy 109

29 Fetchmail 11029.1 Fetchmail manager . . . . . . . . . . . . . . . . . . . . . . . . . . 110

29.1.1 Global settings . . . . . . . . . . . . . . . . . . . . . . . . 11129.1.2 Applying changes . . . . . . . . . . . . . . . . . . . . . . 11129.1.3 Adding a new account . . . . . . . . . . . . . . . . . . . . 111

30 System runtime control 112

31 Compose test email 115

32 Extract text from a MIME message 115

A SMTP HELO/EHLO name 116

B SASL authentication 117

C Content and virus scanning 118

D Cron Expressions 121

E MPA mail flow 122

F Comodo certificate request handler 142F.1 Tier details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

G Bulk import 142G.1 Examples CSV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

5

2 SETUP

1 Introduction

Ciphermail email encryption server is an email gateway (MTA) that encryptsand decrypts your incoming and outgoing email. Because the Ciphermail gate-way functions as a general SMTP email server, it is compatible with any exist-ing email infrastructure and can easily be placed before or after existing emailservers. The gateway is typically installed as a “store and forward” server.Email is therefore only temporarily stored until it is forwarded to it’s final desti-nation.

The Ciphermail gateway currently supports three encryption standards: S/MIME,OpenPGP and PDF encryption. S/MIME and OpenPGP provides authentica-tion, message integrity and non-repudiation and protection against messageinterception (using encryption). S/MIME and OpenPGP uses public key en-cryption (PKI) for encryption and signing. PDF encryption can be used as alight-weight alternative to S/MIME and OpenPGP. The PDF standard allowsPDF documents to be password encrypted. PDF documents can also containattachments embedded within the encrypted PDF.

Certain features are only available with the enterprise edition of the Ciphermailgateway. Where applicable, it will be clearly indicated whether a feature is anenterprise only feature.

Note

This guide provides in-depth information about the gateway appliance.For a quick setup guide of the gateway appliance, see the “CipherMailquick setup guide”.

2 Setup

This guide assumes that Ciphermail gateway has already been installed. Forinstallation instructions see the “installation guide”. The administrator can loginto the administration page by opening the following URL in a browser:https://192.168.1.1 (change the IP address to to match the address of thegateway).

Note

If the Ciphermail gateway was manually installed (i.e., not using theVirtual Appliance) the URL should probably be https://192.168.1.1:8443/ciphermail.

The login page should appear (See figure 1). After logging in with the correctcredentials, the “users” page will be opened.

6

https://192.168.1.1

https://192.168.1.1:8443/ciphermail

https://192.168.1.1:8443/ciphermail

3 NETWORK

Figure 1: Login dialog

Login credentials: Use the following default credentials:

username: adminpassword: admin

Note

it can take some time to login after a restart because the web applicationmust be initialized upon first login.

3 Network

Note: The network settings page is only available for the Ciphermail VirtualAppliance. If the gateway has been manually installed, the network should beconfigured with the tools provided by the operating system.

Since the gateway needs to relay email to external recipients, the DNS serversshould be configured. The network settings can be configured from the WEBGUI. The network info page can be opened by clicking Admin→ network. The“Network info” page will be opened which provides all the relevant networkinformation like DNS servers, network interfaces etc. (see figure 2).

7

3.1 Network interfaces 3 NETWORK

Figure 2: Network info

Note

Since most network settings should be configured from the WEB GUI,the WEB GUI should have a valid IP before the WEB GUI can be ac-cessed. A valid IP address can be setup with the console system ap-plication by logging into the console. See the “Virtual Appliance Guide”for more information.

3.1 Network interfaces

The available network interfaces can be configured by clicking “interfaces”. Thisopens the interfaces page (see figure 3). A network interface can be config-ured by clicking the “gear” icon of the interface. The network interface can beconfigured for a dynamic IP address (DHCP) or for a static IP address (seefigure 4

3.2 Hostname

With the hostname page, the hostname of the gateway can set (see figure5. The hostname is used by many of the networking programs to identify themachine.

8

3.3 DNS 3 NETWORK

Figure 3: Network interfaces

Figure 4: Network interface

Note: It’s advised to use a fully qualified hostname.

Figure 5: Hostname

3.3 DNS

The gateway requires at least one DNS server. The DNS server can be config-ured with the DNS page (see figure 6)

9

3.4 Hosts 3 NETWORK

Figure 6: DNS

3.4 Hosts

The hosts table is a static lookup table for hostnames (see figure 7. In mostsetups, there is no need to add a static hostname to the hosts table. When thehostname (see hostname setting) is changed, the hosts table is automaticallyupdated.

Figure 7: Hosts

10

3.5 NTP 4 MTA SETUP

3.5 NTP

The gateway uses the Network Time Protocol (NTP) to keep the system clocksynchronized with the real time. By default it uses the NTP servers from de-bian.pool.ntp.org (see figure 8. If you are running your own NTP server, changethis to match the IPs or hostnames of the NTP servers.

Figure 8: NTP

4 MTA setup

The Ciphermail gateway uses Postfix as the “Mail Transfer Agent” (MTA). TheMTA is responsible for sending and receiving email. Encryption and decryptionof email is handled by the “Mail Processing Agent” (MPA). The “MTA config”page can be used to configure most of the relevant Postfix parameters.

The “MTA config” page can be opened from the Admin menu. The “MTAconfig” page (see figure 9) contains most of the relevant Postfix parametersfor a “store and forward” email server. Postfix parameters which cannot beset with the “MTA config” page should be set with the “MTA raw config page”(or alternatively by directly editing the Postfix configuration files). The relevantPostfix settings will be explained in the following section. For a more thoroughexplanation of all the Postfix settings see the Postfix documentation (http://www.postfix.org/documentation.html).

4.1 Main settings

Relay domains Relay domains are domains for which the gateway needsto receive email. These are the domains for which the internal users receiveemail. A “store and forward” server normally has one or more relay domains(unless the Ciphermail gateway is only used for sending email).

11

http://www.postfix.org/documentation.html

http://www.postfix.org/documentation.html

4.1 Main settings 4 MTA SETUP

Figure 9: MTA config

12

4.1 Main settings 4 MTA SETUP

Note: If “Match Subdomains” is selected (see other settings), subdomains ofthe relay domains are matched as well. If “Match Subdomains” is not selected,subdomains of the relay domains only match if the subdomains are explicitlyadded to the relay domains. For most setups, it is advised to explicitly add allthe subdomains for which email should be received and leave “Match Subdo-mains” off.

Example: if “Match Subdomains” is selected, and example.com is added tothe relay domains, then incoming email for the domain subdomain.example.comis accepted as well even if subdomain.example.com is not explicitly added tothe relay domains.

My networks Most email senders (users and other internal email servers)are not allowed to send email to domains not specified as a “relay domain”.To allow outgoing email to be sent to external domains, the sender IP addressshould be “white-listed”. The “My networks” list contains all the networks thatare allowed to send email to external domains. The networks must be specifiedin CIDR notation. Example: 192.168.1.1/32, 10.1.2.0/24.

Warning

Only allow IP ranges under your control to relay email to external recip-ients. If IP ranges not under your control are allowed, the gateway willbe an open relay and misused for sending spam.

My Hostname This should be the fully qualified domain name of the emailserver and is used as the default value for many other configuration param-eters. For example “My Hostname” is used as the default domain for emailmessages sent with a missing domain name and is used for the default SMTPhelo/ehlo name (see “SMTP helo name” setting below).

If the gateway directly delivers email to external recipients (i.e., not usingan external relay host) it is important that the helo/ehlo name of the gateway isequal to the reverse lookup of the external IP address. If not, outgoing emailcan be flagged as spam. See Appendix A for more information.

External relay host The external relay host is used when email should besent to an external domain (i.e., a domain which is not a relay domain). Thiscan be the ISPs email server or some internal email server responsible forsending email to external domains.

If “External relay host” is not specified, email will be delivered using DNSMX-records. “External relay host” can be an IP address or a domain name. Ifthe option “mx” is checked, the MX-records of the “External relay host” will beused instead of the A-record (this setting is only used when the “External relayhost” is specified). The “port” setting is the port the “External relay host” serverlistens on (which in most cases should be the default SMTP port 25).

13

4.2 Advanced settings 4 MTA SETUP

Figure 10: MTA advanced config

Internal relay host The internal relay host is used when email should besent to an internal domain (i.e., sent to a relay domain). Typically this will bethe companies internal email server hosting the users email boxes.

If “Internal relay host” is not specified, email will be delivered using DNSMX-records. “Internal relay host” can be an IP address or a domain name. Ifthe option “mx” is checked, the MX-records of the “Internal relay host” will beused instead of the A-record (this setting is only used when the “Internal relayhost” is specified). The “port” is the port the “Internal relay host” server listenson (which in most cases should be the default SMTP port 25).

Match Subdomains If “Match Subdomains” is selected, all subdomains ofthe “Relay domains” will also be relayed.

4.2 Advanced settings

The advanced settings can be set when the “advanced settings” checkbox isselected (see figure 10).

14

4.2 Advanced settings 4 MTA SETUP

Before filter message size limit This is the maximum size of a message (inbytes) that the MTA accepts. A message that exceeds the maximum size isrejected by the MTA.

Note

Because of Base64 encoding, binary attachments (for example worddocuments) will be 4/3 times larger when sent by email. The maximumsize limit, limits the total number of bytes including encoding. For ex-ample, if the limit is set to 10 MB, the total size of all the attachmentscannot exceed 7.5 MB.

After filter message size limit The mail processing agent of the gateway isresponsible for encryption and decryption of messages. The size of a messageafter encryption or decryption (or after signing) can be larger than the size ofthe message before encryption or decryption. The “after filter message sizelimit” should therefore be larger than the “before filter message size limit” oth-erwise the MTA will refuse to send the message after the MPA has handledthe message. It is advised that the “after filter message size limit” should be atleast 2 times larger than the “before filter message size limit”.

Mailbox size limit If mail is locally stored (only when “Local domains” arespecified) the “Mailbox size limit” will be the maximum size (in bytes) of anindividual mailbox. The “Mailbox size limit” should not be smaller than the “afterfilter message size limit”. This setting is only required when Postfix receivesemail for a local domain. By default the gateway does not enable the option todirectly specify local domains.

SMTP helo name The “SMTP helo name” is the hostname used for theSMTP “EHLO” or “HELO” command. If “SMTP helo name” is not explicitlyspecified, “My Hostname” is used as the SMTP helo name.

Note

If the gateway directly delivers email to external recipients (i.e., not usingan external relay host) it is important that the helo/ehlo name of thegateway is equal to the reverse lookup of the external IP address. Ifnot, outgoing email can be flagged as spam. See Appendix A for moreinformation.

Reject unverified recipient Normally an email server should know which in-ternal email addresses are valid addresses (i.e., email addresses for which aninbox exists). When an email server is setup to relay email for certain domainsthe email server should know which recipients will be accepted by the server itrelays to (in other words it should be a smart relay host). If all email is acceptedfor relay without knowing whether the next email server will accept the email,

15

4.3 sasl passwords 4 MTA SETUP

there is a risk of generating “backscatter” bounces. Backscatter bounces, oc-cur when an intermediate email server accepts a message without checkingwhether the next email server accepts the message. Because the intermediateemail server accepted the message, it has to be bounced back to the originalsender when the next server does accept the forwarded email. If the emailwas a spam message using a forged sender, the sender will be flooded withbounced messages.

There are multiple ways for an email server to known which recipient ad-dresses are acceptable and which are not. One solution is to let the gatewayserver “learn” which recipient addresses are acceptable by querying the serverit relays to. When an email is received for a yet unknown recipient, the server“asks” the server it relays to whether the recipient is a valid recipient or not. Themessage is only accepted when the next email server reports that the recipientis a valid recipient. The result of this verification process is cached.

The verification procedure is enabled by checking “Reject unverified recip-ient”. The “reject code” is the SMTP result code used when the email is notaccepted. This should initially be set to “450” (which tells the connecting SMTPserver that the message is not accepted because of a temporary error). Itshould be changed to “550” (permanent error) when the verification procedureworks correctly. See the Postfix documentation for more information on ad-dress verification1.

There are other ways for the email server to know which recipients are valid,for example using LDAP queries or by specifying relay_recipient_maps. Theseother options are however not directly supported by the “MTA config” page andshould therefore be configured using the “MTA raw config” page or by directlyediting the Postfix configuration files.

Applying changes By clicking the “Apply” button, the changes will be checkedand Postfix will be configured with the new settings. Clicking the “Close” buttonwill redirect the browser to the “Admins” page.

4.3 sasl passwords

In cases where the “external relay host” or “internal relay host” requires SMTPauthentication, a SASL account should be added. For example, if Gmail is usedas the “external relay host”, the Gmail smtp server requires that the senderauthenticates itself with the correct Gmail credentials. SMTP credentials for aspecific host can be added by clicking sasl passwords. This opens the SASLpasswords page (see figure 11).

SMTP password authentication is only active when SASL is enabled. Formore information on how to enable SASL see Appendix B.

4.4 MTA config file

Postfix has a large number of settings. The “MTA config” page only supportsa small number of the relevant Postfix settings. For settings not supportedby the “MTA config” page, the “MTA config file” page can be used to directly

1See http://www.postfix.org/ADDRESS_VERIFICATION_README.html

16

http://www.postfix.org/ADDRESS_VERIFICATION_README.html

4.5 RBL 4 MTA SETUP

Figure 11: SASL passwords

edit the Postfix main config file (main.cf). The configuration file contains somespecific Ciphermail gateway settings (settings that start with “djigzo_”). Thesesettings are modified by the “MTA config” page when applying the changes.These settings should therefore not be manually changed because they canbe overwritten by the “MTA config” page. Ciphermai specific settings are usedby other Postfix settings (they are referenced as “${djigzo_...}”).

Warning

The gateway does not validate any changes made to the “MTA configfile” so care must be taken when modifying the Postfix config file di-rectly. If the Postfix configuration file contains errors, the MTA might notfunction properly.

4.5 RBL

only available with the enterprise edition

A Real-time Blackhole List (RBL) is a list of black-listed IP addresses publishedby a DNS server. The MTA dynamically checks whether an external client isblack-listed by querying a DNS server. The MTA rejects the request if the clientIP address is listed in the DNS server. The list of RBL servers is shown in theRBLs section (see figure 12)

The RBL server should be specified as dns-server[=d.d.d.d]. The “=d.d.d.d”part is optional and depends on the used RBL whether or not the optional partshould be specified.

4.5.1 Static black-list

The static black-list contains a list of black-listed clients. The difference be-tween the static black-list and the RBL list is that the RBL dynamically checkswhether a server is black-listed by querying an external DNS server. The staticblack-list is a list of IP addresses (or IP ranges) that are black-listed (see figure

17

4.6 Email forwarding 4 MTA SETUP

Figure 12: RBLs

13.

A range of IP addresses can be specified by leaving out the last octets from anIP address. For example: 192.168.88 will black-list all the IP addresses from192.168.88.0 - 192.168.88.255. An optional rejection reason can be specifiedlike for example “your IP was black listed because it is being used for sendingspam”.

4.5.2 Static white-list

Static white-list list contains a list of white-listed IP addresses. An externalclient should be white-listed if incoming email should be accepted even thoughthe client is black-listed by one of the configured RBL servers.

4.6 Email forwarding


Forwarding of local system accounts to external email addresses can be con-figured on the email forwarding page (see figure 14). If root@domain forwardis not set, system generated email will be sent to root@“My Hostname” (seeMTA config for “My Hostname”).

Note

RFC 2142 requires that Internet facing SMTP servers accept email forthe local postmaster and abuse account. If left empty, email for post-master and abuse will be forwarded to the root account.

18

4.6 Email forwarding 4 MTA SETUP

Figure 13: Static black-list

Figure 14: Email forwarding

19

4.7 Header checks 4 MTA SETUP

Figure 15: Header checks

4.7 Header checks


With header checks, each message header is matched against the list of de-fined patterns (see figure 15). If a pattern matches, the action for the pattern isexecuted. For the matching and action syntax, see the Postfix header checksdocumentation (http://www.postfix.org/header_checks.5.html)

Example: The following rule will reject the email if the subject line of the emailstarts with “make money fast”:

/^Subject: make money fast/ REJECT spam detected

4.8 SMTP transports


By default all email sent to external recipients (i.e., email addresses not match-ing any relay domain) will be delivered to the “External relay host” or, if “Externalrelay host” is not configured, it will be delivered using MX records. In a similarway, email sent to one of the relay domains will be delivered to the “Internalrelay host” or, if “Internal relay host” is not configured, it will be delivered usingMX records. SMTP transports allow the administrator to override the defaultmail delivery. For example, if CipherMail Secure Webmail is used, email for thewebmail domain should be delivered directly to the Secure Webmail server.Although it’s possible to configure an MX record for the webmail domain, inmost cases it’s easier to configure an SMTP transport for the webmail domain.The list of SMTP transports can be managed on the SMTP transport page (seefigure 16.

20

http://www.postfix.org/header_checks.5.html

5 USERS

Figure 16: SMTP transports

Figure 17: Users

5 Users

A user is a sender or receiver of email and is uniquely identified by his/heremail address. Every user has a set of preferences that determine how emailis handled for that particular user. The users page gives an overview of all theusers (see figure 17).

Specific users can be searched for using the filter. Users can be removed byclicking the ’cross’ icon or by selecting the users and clicking “delete selected”.New users can be added by clicking “Add user” on the left hand side menu.Clicking a user opens the user preferences page (see next section). Internalusers are marked with a green star icon (see “Locality property” on page 24for more info on the difference between internal and external users). Clickingthe user certificate icon opens the certificate selection page for the user. If theuser is an internal user, the “Select signing certificate” page is opened. If theuser is an external user, the “select encryption certificates” page is opened.

21

5.1 User preferences 5 USERS

5.1 User preferences

Every user has a set of preferences which determine how email is handled forthat particular user. User preferences can inherit some or all of the preferencesfrom higher level preferences.

Users inherit their preferences from domain preferences, domain prefer-ence inherit from the global preferences and the global preferences inherit fromthe factory preferences:

user← domain← wild-card domain2 ← global← factory.

The preferences for a user can be edited by clicking on the users email address(see figure 18). The user preference page links to sub-pages “select encryptioncertificates”, “select signing certificate”, “templates” and “global preferences”which can be used to edit additional preferences. Whether a preference is in-herited or not is determined by the associated “inherit” checkbox. If checked,the preference is inherited.

Sender and receiver preferences Some preferences are only relevant forthe sender of a message and some preferences are only relevant for the re-ceiver of a message. Most preferences however are relevant for both thesender and receiver. The MPA mail flow in Appendix E shows exactly whenand how preferences are used by the MPA.

Note

“S” or “R” indicates that a preference is a sender preference or a receiverpreference. Some settings are used as a sender and receiver setting.A setting which is used as a sender or recipient setting is written as (S |R). A setting which is used as a sender and recipient property is writtenas (S & R).

Message originator The Ciphermail gateway uses the “From” header as theidentity of the sender and not the “envelope sender”. It is important to under-stand the difference between the from and the envelope sender because theidentity of the sender determines which settings and certificates will be usedby the sender. Because sender is such a confusing term, the term “originator”will be used instead when referring to the identity of the sender (i.e., the fromheader).

The rationale for using the “From” for the identity of the sender is that theenvelope sender is more or less similar to the postman and is therefore onlyresponsible for the message delivery and not for the message content whereasthe “From” identifies the actual originator of the email. The user identified bythe “From” is responsible for the message content. In most cases however, theenvelope sender is the same as the “From”.

Another important reason why the from header is used, is that S/MIME usesthe from header as the identity of the sender, i.e., an S/MIME client compares

2An example of a wild-card domain is *.example which matches test.example.com.

22


Figure 18: User preferences

23


the email address of the signing certificate with the from header of the mes-sage. While the identity of the sender is determined by the from header, theidentity of the recipient is determined by the recipient of the SMTP envelopeand not the “To” header.

Next, a brief overview of the all the user preferences will be given.

5.1.1 General

Comment This field is a free form text field in which the administrator canadd some comments related to this user.

Locality (R) The “locality” of a user can be external or internal. The “locality”preference is a very important preference because it determines whether emailcoming into the gateway should be encrypted or decrypted. If the recipient ofan email is an internal user, the email should be decrypted. If the recipient ofan email is an external user, the message should be encrypted (whether themessage will actually be encrypted depends on other user settings). Typicallyusers for which the gateway receives email will be internal users (i.e., usersbelonging to one of the relay domains) and all other users will be externalusers. The domain of a recipient is based on the SMTP envelope recipient.The domain of the sender is based on the “From” header3.

Note

because the locality is such an important preference, it should be con-figured correctly. In most installations all domains for which the gatewayreceives email (i.e., the relay domains) should be internal domains.

Encrypt mode (S & R) Encrypt mode determines whether a message sent toan external user (i.e., a user with external locality) should be encrypted or not.The possible encrypt modes are: “No Encryption”, “Allow”, “Mandatory” and“Allow (sender or recipient”. Encrypt mode is used for the sender and recipient(with the exception of Allow (sender or recipient)). If encrypt mode is “No en-cryption”, the message will not be encrypted by default (unless being overruledby the “subject trigger”). If mode is “Allow” the message is only encrypted if itis possible to encrypt the message (i.e., a valid recipient certificate is availableor PDF encryption is setup for the recipient). With “Mandatory” mode, the mes-sage must be encrypted and if it is not possible to encrypt the message, themessage will not be sent and the sender will be notified.

Encrypt mode (except if the mode is Allow (sender or recipient)) is a senderand receiver preference. This means that the settings for both the sender andreceiver must allow encryption. If for example the sender has encrypt mode“Mandatory” and the recipient has encrypt mode “No Encryption”, the messagewill not be encrypted and will therefore not be sent (because the sender encrypt

3If there is no “From” header, the “Sender” header will be used. If the “Sender” header is alsomissing, the envelope sender will be used.

24


mode was “Mandatory”). If the sender (or recipient) has encrypt mode “Allow(sender or recipient)”, the other encrypt mode is ignored and encryption isallowed. “Allow (sender or recipient)” encrypt mode is for example used whenall email sent to an external recipient should always be encrypted regardlessof the “Encrypt mode” of the sender.

Encryption notification (S) If set, the sender of the message will be noti-fied (with an email) when the message is encrypted (see template “successfulencryption” on page 51 for the notification message template).

5.1.2 S/MIME

Enabled (S & R) If checked, digital signing and encryption of outgoing emailwith S/MIME is supported.

Strict mode (R) By default, the gateway tries to decrypt every incoming S/MIMEencrypted message even if the recipient of the message does not have an as-sociated private key with which the message can be decrypted. In other words,the gateway tries to decrypt the message with any suitable key (“decrypt ifpossible”). There are a couple of advantages when decrypting every incomingemail irrespective of the recipient: a) it makes it easier to manage domain todomain encryption; b) forwarded email can be decrypted and, c) email handlingwith multiple recipients is faster because only one key is required for decryp-tion.

Even though non-strict mode is easier from a management perspective, it isnot as secure as “strict” mode. In non-strict mode, if an external attacker getshold of an encrypted message, the attacker can resend the message to aninternal accomplice, i.e., someone from inside the company who has accessto an internal mail box and who works closely with the attacker. Because themessage will decrypted with any available key, the message will be delivereddecrypted to the insider even though the insider was not the original recipient.

In “strict” mode, additional checks will be done to make sure that the messagewill only be decrypted if the recipient has a valid decryption key. A message willonly be decrypted for a recipient if the certificate associated with the private keyfor decryption is valid, trusted, not revoked and if one of the following is true:

(a) the recipient has a certificate and private key with a matching email addressand the message can be decrypted with this private key or,

(b) the recipient has a certificate and private key and the certificate is explicitlyassociated with the user and the message can be decrypted with theprivate key or,

(c) the recipient is from a domain and the domain has an explicitly associatedcertificate and private key and the message can be decrypted with thisprivate key.

If in strict mode, every recipient for which none of the above rules apply, willreceive the message in encrypted form.

25


Whether or not to use strict mode depends mostly on whether you trust yourinternal users. If you do not trust all internal users, it’s better to enable strictmode. If all internal users can be trusted, running in non-strict mode might besomewhat easier to manage.

Note: strict mode can be enabled and/or disabled per domain and per recip-ient. Although it’s advised to only change the global strict settings, there aresituations where it can be helpful to enable or disable strict mode per recipient.For example, suppose the global strict mode is enabled. However, becauseof email archiving purposes, the front-end SMTP server sends a copy (bcc)of every incoming email to the email archiver. Since the gateway is in strictmode, encrypted message won’t be decrypted by the gateway when deliveredto the email archiver. By disabling strict mode for the email archiver recipient,incoming email delivered to the email archiver will be decrypted.

Max. message size (S | R) If the email message is larger than the speci-fied maximum message size (in bytes) the message will not be S/MIME signedor encrypted. Large S/MIME messages can sometimes not be handled byS/MIME email clients. Another reason for limiting the size of S/MIME mes-sages is that encrypting and signing of large email messages can be resourceintensive.

5.1.3 PGP

PGP enabled (S & R) If checked, PGP for outgoing email is supported.

PGP encoding to external (R) The PGP encoding used for outgoing email.Two encodings are supported: PGP/MIME and PGP/INLINE. PGP/MIME is ad-vised because it secures the complete message MIME message and supportsHTML email. With PGP/INLINE, every MIME part is individually PGP encoded.PGP/INLINE support for HTML email is limited and is not supported by all emailclients.

Note

You are strongly advised to use PGP/MIME whenever possible.PGP/MIME has full support for HTML email and is less resource in-tensive.

Enable PGP/INLINE to internal (R) PGP supports two types of encoding:PGP/MIME and PGP/INLINE. With PGP/MIME, the complete MIME messageis protected as one object. A PGP/MIME protected message can be easilyrecognized without having to scan the complete message because it containsa PGP/MIME specific header. With PGP/INLINE, every individual part of themessage (attachments and message bodies) is individually protected (signedand/or encrypted). To determine whether or not a message is PGP/INLINEprotected, the complete message must be scanned. A PGP/INLINE message

26


does not contain a specific header which can be used to determine whetherthe message is PGP/INLINE protected. Scanning every incoming email com-pletely from top to bottom can be resource intensive, especially for very largeattachments. It is therefore advised to leave “Incoming PGP/INLINE enabled”unchecked (i.e., disabled) unless PGP/INLINE support for incoming email is arequirement.

Note

leave “Incoming PGP/INLINE enabled” unchecked unless PGP/INLINEsupport for incoming email is a requirement.

Max. message size (S | R) If the email message is larger than the specifiedmaximum message size (in bytes) the message will not be PGP signed orencrypted. Large PGP messages can sometimes not be handled by PGP emailclients. Another reason for limiting the size of PGP messages is that encryptingand signing of large email messages can be resource intensive.

5.1.4 PDF

Enabled (S & R) If checked, PDF encryption is supported.

OTP enabled (S & R) With the one time password mode, passwords for PDFencryption will be generated based on the “Client Secret” and on the “PasswordID”. For more information on the OTP mode, see the PDF encryption guide). Ifselected, the one time password mode is enabled for the user.

Generate password to originator (S & R) If checked, generated passwordswill be sent to the originator of the message (i.e., the sender) as a notificationmessage. The notification message will contain the generated passwords (seetemplate “passwords” on page 51 for the notification message template). Theoriginator is responsible for delivering the generated passwords securely to therecipients of the encrypted message.

Max. message size (S | R) PDF encryption not only encrypts the messagebody but also encrypts the message attachments. To prevent the PDF frombecoming too large, the PDF is not encrypted if the total size of body text andattachments exceeds the maximum message size (in bytes).

5.1.5 Password (R)

Password The password for the user. Currently this is only used for PDFencryption. The password can be set by the administrator or can be randomlygenerated. If the current password has expired (see “Validity interval”) a newpassword will be generated when the password is used. If a static passwordshould be used, password expiration should be disabled by setting “Validityinterval” to -1.

27


Password ID (R) The “Password ID” identifies the password used for PDFencryption. The “Password ID” is required when the "One Time Password"(OTP) mode is used or when the password is delivered by SMS Text.

With the OTP encryption mode, a password will be generated based on asecret key and on a unique identifier (the “client secret” and the “Password ID”).The “Password ID” is used by the recipient of the encrypted PDF message toregenerate the password (for more information about the OTP mode, see thePDF encryption guide). With the SMS Text mode, the randomly generatedpassword will be delivered to the recipient via an SMS text message. Becausethe recipient can receive multiple passwords via SMS Text, the recipient hasto know which password belongs to which encrypted PDF. The encrypted PDFmessages therefore contain a password identifier which can be used to find thematching password. Every time a new password is generated, a new uniquepassword ID is generated. The “Password ID” property shows the last gener-ated password ID for the user.

Validity interval (R) The time (in minutes) the password is valid. If the pass-word is no longer valid (expired) a new password will be generated when thepassword is used. If the “Validity interval” is 0 a new password will be gen-erated every time a message is PDF encrypted. If “Validity interval” is -1 thepassword never expires.

5.1.6 Encryption subject trigger

A subject trigger can be used to force encryption if the subject contains a cer-tain keyword. This is useful when the default setting for a sender or recipient is“No encryption” but the sender wants to force encryption of a particular mes-sage (“on demand encryption”).

Trigger (S) If the subject contains the provided trigger keyword and the sub-ject trigger is enabled, encryption is forced for this message. Whether themessage is really encrypted depends on the availability of valid certificates forthe recipients. If encryption is triggered but the message cannot be encrypted,the message will not be sent and the sender will be notified.

Enabled (S) The subject trigger functionality will only be functional if “En-abled” is checked.

Regular expr. (S) If checked, “Trigger” is interpreted as a regular expressionand the subject is matched against this regular expression.

Example: (?i)(\[secure\]|\[encrypt\]).

With the above subject trigger, encryption will be forced if the subject contains[secure] or [encrypt]. (?i) makes the check case insensitive.

Remove match (S) If checked, the matching part will be removed from thesubject.

28

5.2 Advanced settings 5 USERS

Example: Suppose the trigger is set to "[encrypt]" and the subject of the in-coming message is “your bank statement [encrypt]” the subject after encryptionis “your bank statement”.

5.1.7 Signing

Only sign when encrypt (S & R) If checked, messages will only be digitallysigned when they are S/MIME or PGP encrypted. If not checked, all messageswill be digitally signed. The sender of a message must have a valid signing cer-tificate or PGP key before a message can be digitally signed. S/MIME signingis tried before PGP signing, i.e., if a sender has a valid S/MIME signing key, themessage will be S/MIME signed. If the sender does not have a valid S/MIMEsigning key but has a valid PGP signing key, the message will be PGP signed.

5.2 Advanced settings

The advanced settings sub page contain settings which are only used in spe-cialized setups (see figure 19). Some settings can only be set for the globalsettings. See 5.3 for more information on the global specific settings.

5.2.1 General

Skip calendar messages (S | R) If checked, calendar messages4 (for ex-ample Outlook meeting requests) are not digitally signed or encrypted. Someemail clients, for example Outlook, cannot handle meeting requests if the meet-ing requests are digitally signed or encrypted.

Note: Enabling “Skip calendar messages” does not result in skipping DLP.

5.2.2 S/MIME

Encryption algorithm (R) The encryption algorithm to use when encryptingthe message. The following encryption algorithms can be selected: “AES256”,“AES192”, “AES128”, “3DES”, “RC2”, “CAST5”, “CAMELLIA256”, “CAMEL-LIA192”, “CAMELLIA128” and “SEED”.

Note

some S/MIME clients only support a subset of the available algorithms.For example Outlook only supports “AES256”, “AES192”, “AES128”,“3DES” and “RC2”. “3DES” is supported by all S/MIME clients.

4Messages with the content-type “text/calendar”

29


Figure 19: Advanced user preferences30


Signing algorithm (R) The signing algorithm to use when signing the mes-sage. The following signing algorithms can be selected: “SHA1”, “SHA256”,“SHA512” and “RIPEMD160”.

Note

some S/MIME clients only support a subset of the available algorithms.In order to validate SHA2 (SHA256 and SHA512) messages, WindowsVista with Outlook 2003 (or newer) is needed. In order to both signand validate SHA2 messages, Windows Vista or 7 with Outlook 2007or 2010 is needed (see http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx).

Auto select certificates (R) If checked, encryption certificates will be auto-matically selected for the recipient.

Always use freshest signing certificate (R) The first time a message mustbe signed, the gateway automatically searches for a valid signing certificate forthe sender. Once a signing certificate has been selected, the signing certificatewill be used for all signing operations until the certificate is no longer valid.If however “Always use freshest signing certificate” is selected, every time amessage is signed, the newest signing certificate (i.e., a valid certificate withthe latest "not before") is used.

Auto request certificate (S) If checked and the sender does not yet havea valid signing certificate, a new certificate and private key will be automati-cally requested for the sender using the default Certificate Authority (see CASettings on page 67).

Add user (R) If checked and a certificate is available for the recipient, a userobject will be created if a message is S/MIME encrypted.

Encrypt headers (R) If checked, certain headers (“Subject”, “To”, “Cc”, “Reply-To” and “From”) are added to the encrypted message. This option is normallyonly used when encrypting email to a Ciphermail for Android user (it providesaccess to all the relevant headers from the smime.p7m attachment).

Note: the headers are added to the encrypted binary blob and are “not” re-moved from the message. Do not select this option if the recipient uses Outlookbecause Outlook does not support encrypted headers.

Remove signature (R) If checked and an incoming message is signed, thesignature will be removed from the message. This can be helpful when theemail client used by internal users or some email handling software cannothandle digitally signed messages.

31

http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx

http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx


Skip calendar messages (S | R) If checked, calendar messages5 (for ex-ample Outlook meeting requests) are not digitally signed or encrypted. Someemail clients, for example Outlook, cannot handle meeting requests if the meet-ing requests are digitally signed or encrypted.

Skip signing calendar messages (S | R) If checked, calendar messages(for example Outlook meeting requests) are not digitally signed. Some emailclients, for example Outlook, cannot handle meeting requests if the meetingrequests are digitally signed. The difference between “Skip signing calendar”and “Skip calendar” is that when “Skip signing calendar” is checked but “Skipcalendar” is not, messages can still be encrypted. This can be helpful whenall email, including calendar messages, sent to a specific domain must be en-crypted with a domain certificate.

Add additional certificates (S | R) If checked and the message is S/MIMEencrypted, the message will also be encrypted with the additional certificates.See 10.3 for more information.

Auto import certificates from email (S) If checked, certificates from re-ceived digitally signed emails will be automatically extracted and stored in thecertificates store.

Skip import of untrusted certificates (S) If checked, extracted certificates(see “Auto import certificates from email”) will only be imported if the certifi-cates are trusted.

5.2.3 PGP

The PGP advanced options are shown in Figure 20.

Signing algorithm (R) The signing algorithm to use when signing the mes-sage. The following signing algorithms can be selected: “SHA1”, “SHA256”,“SHA512” and “RIPE-MD/160”.

Encryption algorithm (R) The encryption algorithm to use when encryptingthe message. The following encryption algorithms can be selected: “AES256”,“AES192”, “AES128”, “3DES”, “CAST5”, “Blowfish” and “Twofish”.

Compression algorithm (R) The compression algorithm to use when en-crypting the message. The following compression algorithms can be selected:“UNCOMPRESSED”, “ZIB”, “ZLIB”, “BZip2”. If “UNCOMPRESSED” is selected,the message is not compressed before encryption.

5Messages with the content-type “text/calendar”

32


Figure 20: PGP advanced user preferences

Convert HTML to text (R) This option is only used if the message is PGP/INLINEencoded. Because there is no standard way to handle HTML email with PGP/INLINE,if “Convert HTML to text” is selected, HTML parts will be converted to text. Thisoptions is not used if the message is PGP/MIME encoded.

Add integrity packet (R) If set, an integrity packet will be added to the PGPencoded message.

Key size (S) The key size (in bits) of automatically generated secret PGP keypairs (see “Auto request” option). The following key size can be selected: 1024.2048, 4096.

Auto publish (S) If checked, automatically generated PGP secret keys willbe automatically published to the registered PGP key servers.

Auto request (S) If a message needs to be PGP encrypted and the senderdoes not yet have a valid PGP secret key, and auto request is set, a new PGPsecret key will be generated for the sender.

Remove signature (R) If true, the PGP signature is removed from the mes-sage.

Import keys from email (R) If true, and a PGP key is attached with the con-tent type set to "application/pgp-keys", the key will be imported.

Note: Inline attached keys are not currently not supported.

33


Remove keys from email (R) If true, and a PGP key is attached with thecontent type set to "application/pgp-keys", the key will be removed from theemail.

Note: Inline attached keys are not currently not supported.

Auto update email addresses (S | R) If “Auto update email addresses” isselected, all the email addresses found in a valid User ID of a PGP key will beautomatically associated with the key. Only User IDs with a valid self signedsignature will be used. If “Auto update email addresses” is not selected, emailaddresses should be manually associated with the key. This is a global onlyoption.

Note

A key owner can add any email address to a key (it is only checkedwhether the User ID contains a valid self signature). If you want tomake sure that only email addresses are added which you know arevalid for the user, disable “Auto update email addresses” and manuallyassociate the email addresses.

5.2.4 PDF

A brief explanation of the advanced PDF preferences will be given. See the“PDF Encryption Guide” for more information on how to setup PDF encryption.

Only if mandatory (S | R) If checked, PDF encryption will only be enabledif encryption is mandatory (for example, if encrypt mode is mandatory, or en-cryption is triggered using the subject trigger).

Sign email (S & R) If checked and the sender has a valid signing certificate,the email containing the encrypted PDF will be S/MIME digitally signed6.

Reply allowed (S & R) If checked, the encrypted PDF will contain a “Reply”link which can be used by the recipient of the encrypted PDF to securely replyto the message using the built-in portal.

Send CC to replier (S & R) If checked, a CC of the PDF reply will be sent tothe replying user.

Note

To make sure that the CC sent to the replier is encrypted, set “Encryptmode” of the “Reply sender” (see setting below) to “Mandatory”.

6The email containing the PDF is signed, not the PDF itself.

34


Validity interval (R) If checked, the “Validity interval” determines how long(in minutes) a reply link is valid.

Reply URL (S) A recipient can securely reply to the PDF by clicking the replylink in the PDF. The reply link opens the reply page of the built-in portal usingthe default web browser. The reply URL should be setup to link to the externalURL of the PDF reply page. The default reply URL is based on the portal “BaseURL” (see 5.6). It is therefore advised to change the “Base URL” of the portaland only change the “Reply URL” if the PDF reply page runs separately fromthe portal.

Reply sender (S) The envelope sender of the PDF reply message will be setto “Reply sender”. The local name part of the “From” header of the reply mes-sage will be set to the email address of the replying user prefixed with “in nameof”.

Example:If the user [email protected] replies to the encrypted PDF us-ing the reply portal page, the reply will contain the following from:

"in name of [email protected]" [email protected]

(where [email protected] is the “Reply sender” address and [email protected] the email address of the user that replies).

The “Reply-To” header is set to the email address of the replier to make surethat a reply is sent to the correct recipient.

A reply using the reply portal page is always sent using the same sender be-cause:

(a) The reply sender is always a known address. The encryption rules for thereply sender can therefore be specified. For example, it’s possible to forceall PDF reply messages to be encrypted.

(b) If for some reason the reply message is bounced, the bounce will not besent to the original sender but to the “Reply sender”. This prevents thebounced message from accidentally being sent over the Internet withoutencryption.

(c) Using the real email address of the replying user as the envelope senderrequires the gateway to “spoof” the sender address. If the sender do-main of the replying user has defined any SPF records, the reply can beflagged as a forgery and therefore blocked by spam filters.

5.2.5 Encryption header trigger

Force encrypt allowed (S) If checked, senders are allowed to trigger encryp-tion of messages with a specific header (see “Force encrypt trigger”).

35


Force encrypt trigger (S) The “Force encrypt trigger” can be used to triggerencryption of a message using a specific email header. All headers of anoutgoing email are matched against the “Force encrypt trigger” and if there isa match, encryption is forced. If the header is present but the message cannotbe encrypted, the message will be bounced back to the sender to notify thatthe message could not be encrypted.

Force encrypt trigger, for example, can be used when an automated systemsends email to external recipients and some, but not all, emails should beencrypted. By adding a header to an outgoing email, the external system canspecify whether the email should be encrypted or not.

The trigger is specified as: HEADER[:REG_EXPR], where “HEADER” is the nameof the header and “REG_EXPR” is the optional header value specified as aregular expression. If “REG_EXPR” is not specified, all header values areaccepted. If “REG_EXPR” is specified, only those header values that matchthe regular expression will trigger encryption.

Examples: The following examples trigger encryption when the messagescontains the X-Encrypt header. The header values are ignored (i.e., all headervalues are accepted).

X-EncryptX-Encrypt:X-Encrypt:*.

The following example triggers only when the message contains a headernamed X-Encrypt with a header value of “true” (whitespace is ignored andchecks are case insensitive).

X-Encrypt:(?i)^\s*true\s*$

5.2.6 Signing header trigger

Force signing allowed (S) If checked, senders are allowed to trigger signingof messages with a specific header (see “Force signing trigger”).

Force signing trigger (S) The “Force signing trigger” can be used to triggerS/MIME signing of a message using a specific email header. All headers of anoutgoing email are matched against the “Force signing trigger” and if there is amatch, S/MIME signing is forced.

This can for example be used when an automated system sends email toexternal recipients and some, but not all, emails should be digitally signed. Byadding a header to an outgoing email, the external system can specify whetherthe email should be signed or not.

The trigger is specified as: HEADER[:REG_EXPR], where “HEADER” is the nameof the header and “REG_EXPR” is the optional header value specified as aregular expression. If “REG_EXPR” is not specified, all header values are

36


accepted. If “REG_EXPR” is specified, only those header values that matchthe regular expression will trigger signing the message.

Examples: The following examples trigger signing when the messages con-tains the X-Sign header. The header values are ignored (i.e., all header valuesare accepted).

X-SignX-Sign:X-Sign:*.

The following example triggers only when the message contains a headernamed X-Sign with a header value of “true” (whitespace is ignored and checksare case insensitive).

X-Sign:(?i)^\s*true\s*$

5.2.7 Signing subject trigger

A subject trigger can be used to force signing of a message if the subject con-tains a certain keyword. This is useful if the default setting for a sender orreceiver is “Only sign when encrypt” (which means that the message won’t besigned by default), but the sender wants to force signing of the message (“ondemand signing”).

Trigger (S) If the subject contains the provided trigger keyword and the sub-ject trigger is enabled, signing is forced for this message. Whether the messageis really signed depends on the availability of a valid signing certificate for thesender. If signing is triggered but the message cannot be signed for whateverreason, the message will not be signed.

Enabled (S) The subject trigger functionality will only be functional if “En-abled” is checked.

Regular expr. (S) If checked, “Trigger” is interpreted as a regular expressionand the subject is matched against this regular expression.

Example: (?i)\[\s*sign\s*\]

With the above subject trigger, signing will be forced if the subject contains[sign]. (?i) makes the check case insensitive.

Remove match (S) If checked, the matching part will be removed from thesubject.

37


Example: Suppose the trigger is set to "[sign]" and the subject of the incom-ing message is “your bank statement [sign]” the subject after encryption is “yourbank statement”.

5.2.8 Password

Generated length (R) The length (in bytes) of the randomly generated pass-words. This is used when a new password for PDF encryption is automaticallygenerated.

Date last generated (R) The date the password was generated. This is usedin combination with the “validity interval” to determine whether the password isstill valid. If “Date last generated” is empty, the password will never expire.

5.2.9 One time password (OTP)

OTP URL (R) The recipient of an OTP encrypted PDF, needs to access theportal to generate the password for the PDF. The default external URL for theOTP password generator is based on the portal “Base URL” (see 5.6).

Note

You are advised not to change the “OTP URL” but to change the “BaseURL” of the portal. The only reason to change the “OTP URL”, is if theOTP generator runs separately from the portal.

5.2.10 Security info

Add security info (R) If checked and an incoming email is S/MIME encryptedor signed, information about the encryption or signature will be added to thesubject. For more information see 5.3.1.

5.2.11 Subject filter

If enabled, the subject of incoming email will be filtered with the filter setup onthe global settings (see 5.3.2 for more information).

5.2.12 CA

Last used pfx password If a pfx file was generated, “Store password” wasselected when generating the pfx and the pfx was sent by email to the user, thepassword for the pfx file will be stored in the “Last used pfx password” setting(see 13.4 for more information).

The user preference sub-pages “select encryption certificates”, “select sign-ing certificate”, “templates” and “global preferences” will be explained in laterparagraphs.

38

5.3 Global advanced settings 5 USERS

Figure 21: Global advanced user preferences

5.2.13 Other

Server secret (R) The server secret is used to protect external resourcesagainst tampering (using the HMAC algorithm). For example the reply link inan encrypted PDF message is protected to make sure that a recipient can onlyreply to a message that was generated by the server. A global server secret willbe automatically generated the first time the server starts. The server secretis a required setting. In most setups there is no need to override the inheritedserver secret.

Client secret (R) The “Client secret” is used to generate the one time pass-word for the recipient.

Auto create client secret (R) If OTP mode is enabled and the recipient doesnot yet have a “Client secret” and “Auto create client secret” is enabled, a newrandomly generated client secret will be automatically created for the recipient.

5.3 Global advanced settings

Certain settings can only be set for the global settings (see figure 21 for theglobal specific settings).

5.3.1 Security info

Add security info If checked and an incoming email is S/MIME encryptedor signed, information about the encryption or signature will be added to thesubject. The actual text that will be added to the subject depends on whetherthe message is encrypted or signed and whether the signature is valid.

Decrypted tag If an incoming message is encrypted, the “Decrypted tag” willbe added to the subject.

39

5.4 Mobile 5 USERS

Signed tag If an incoming message is signed and the signature is valid, the“Signed tag” will be added to the subject.

Signed by tag If an incoming message is signed and the signature is validbut the email address of the sender (the from header) is not the same as theemail address of the signing certificate, the “Signed by tag” will be added to thesubject with %s replaced by the email address of the signing certificate.

Invalid signature tag If an incoming email is signed but the signature is notvalid (for example the signing certificate is not trusted), the “Invalid signaturetag” will be added to the subject.

Note: since an external sender can add these tags to an existing message(i.e., “spoof” that the message was protected), the existence of any of these se-curity info tags should not be used as a proof that the message was encryptedand/or signed. Whether or not the message was really signed and/or encryptedcan only be checked with 100% certainty by looking at the X-Djigzo-Infoheaders (see Appendix A of the Ciphermail S/MIME setup guide for more infor-mation on the X-Djigzo-Info headers). The “Subject filter” (see next section)can be used to remove all of the security info tags of incoming email to makesure that an external sender cannot “spoof” that the message was encryptedand/or signed.

5.3.2 Subject filter

Enabled (S & R) If checked, the subject of incoming email will be filtered.

Filter (S) The filter with which the subject will be filtered. The filter should bespecified as:

/REG-EXP/ VALUE

where REG-EXP is the regular expression that will be used to match part of thesubject and VALUE is the string that will replace the matched part. If VALUEis not set, the matched part will be removed from the subject (i.e., it will bereplaced with an empty value)

Example: the following subject filter can be used to remove the default secu-rity info tags from incoming email:

/\[(decrypted|signed|signed by:.*|invalid signature!)\]/

5.4 Mobile

The mobile sub settings page contains settings which are only required whenusing “Ciphermail for BlackBerry”. See “Ciphermail for BlackBerry administra-tion guide” for more information.

40

5.5 SMS 5 USERS

Note: The mobile settings page is disabled by default. If the BlackBerry add-in for BIS should be used, the mobile settings page should be enabled.

5.5 SMS

Phone number (S) The phone number of the recipient to which SMS Textmessages will be sent. Passwords for the encrypted PDF or passwords forencrypted certificates can be sent via SMS Text messages. The phone numbershould be in international format (i.e., including the country code).

Send SMS (S) If checked, the sender of the message is allowed to send SMSText messages.

Receive SMS (R) If checked, the recipient of the message is allowed to re-ceive SMS Text messages.

Phone number allowed (S) If checked, senders are allowed to specify a tele-phone phone number on the subject of an outgoing message. This telephonenumber is used by the PDF encryption functionality to send passwords via SMSText messages. The telephone number is only used when the subject triggeris specified (see “Subject trigger” on page 28) and when the telephone numberis at the end of the subject line. The telephone number can start with a + andmay contain spaces, and the following characters (excluding the quotes) “-()”.

Examples: Suppose that the subject trigger is [encrypt].

The following subjects contain valid telephone numbers:

(a) This is a subject with a phone number [encrypt] +31123456

(b) Encrypt this [encrypt] +31-(123)456

The following subjects do not contain valid telephone numbers:

(a) This is a subject with an invalid phone number [encrypt] 31=456

(b) Another example with an invalid phone number +31123456 [encrypt]

It should be noted that only one recipient (“To”, “Cc” or “Bcc”) at the same timeis supported when the telephone number is in the subject. With multiple recip-ients it would be impossible to match the recipient with the correct telephonenumber. If the message has more than one recipient, the message will not besent and the sender will be notified.

Default country code (S) The telephone number in the subject should be ininternational format (i.e., including the country code). If the telephone numberstarts with a zero (0), which is not a country code, the server will add the de-fault country code to the telephone number to make it a complete internationaltelephone number. The “default country code” is only used when the telephone

41

5.6 Portal 5 USERS

Figure 22: Portal settings

number is specified on the subject. The “Default country code” is not used bythe telephone number that has been explicitly set using the administration page(see “Phone number” on page 41) since that number should always be set ininternational format.

5.6 Portal

The portal can be used to provide the following functionality for external users:

• PDF reply

• Manage a DLP quarantined message

• Generate the one time password

The portal settings page can be used to setup certain aspects of the portal(see figure 22).

Password The password is used by the external user to login to the portal. Ifan external user receives a PDF encrypted email which was encrypted with aone time password (OTP), the external user can login to the portal to retrievethe password for the PDF. If no password is set for the user, the user cannotlogin.

Min. password strength If the user sets or changes the portal password, thepassword should have a minimal strength. The password strength is estimatedusing the algorithm from “NIST Special Publication 800-63”. Before the newpassword is accepted, additional checks on the password strength are done. Anew portal password is only accepted if the password:

1. is not based on your email address

2. does not contain a QWERTY keyboard sequence of more than 5 charac-ters

3. does not contain more than 5 duplicate characters in a row

4. is of sufficient strength in bits

42

5.7 PDF settings 5 USERS

Note: The administrator is free to set any portal password for a user, i.e.,there is not check on the strength of the password if set from the WEB GUI.

Enabled If set, the user can login to the portal using the email address of theuser as the login name and the portal password for the user. If not set, the usercannot login.

Note: the enabled setting is only used to specify whether the user can login.If not set, users can still reply to a PDF since replying to a PDF does not requirethe user to login.

Auto invite If the “Auto invite” setting is set and a one time password en-crypted PDF gets sent to the user, the user is “invited” to select a new pass-word. See the PDF encryption guide for more information.

Base URL To access the portal functionality, external users need to connectto the portal. The URLs to which external users need to connect to are writtento the emails and encrypted PDFs (for example the reply link in the PDF). Tomake sure the URLs are externally accessible URLs, the gateway has to knowwhat the correct external URL of the portal is7. The “Base URL” is not directlyused, but is used as the base for the following URLs: PDF reply URL, OTPURL and DLP Quarantine URL. The “Base URL” can only be set for the globalsettings.

Example: In most setups, the base URL should look similar to*:

https://www.example.com/web/portal

* replace www.example.com with the domain name or IP address of the realserver.

Note

since all other URLs used by the gateway are based on the “Base URL”,it’s advised to only set the “Base URL” and not set the other URLs. Theother URLs only need to be explicitly set if some specific functionalityuses a different URL than the portal base URL.

5.7 PDF settings


By clicking the PDF settings link on the settings page for a user, domain orglobal settings, the PDF settings page will be opened (see figure 23).

7In most typical setups, the gateways internal IP address is different from the external IP ad-dress (NAT).

43

5.7 PDF settings 5 USERS

Figure 23: PDF settings

5.7.1 Cover page

The cover page 8 will be added to the beginning of the encrypted PDF. Thiscan for example be used to add company logo and address information.

Add cover page If set and a cover page is set, the cover page will be addedas the first page of the encrypted PDF.

Cover page The actual cover page. The cover page should be a valid PDFfile with a maximum size of 1MB.

5.7.2 Attachments

Message attachments are added to the encrypted PDF as well. Some attach-ment types however are blocked by some PDF readers (for example AdobeAcrobat blocks access to zip files). The PDF encryption module can automati-cally rename attachment extensions so the PDF reader will not block access tothe attachment 9.

Example: If a message is PDF encrypted and a zip file with name a-file.zipwas attached to the message, the zip file will be renamed to a-file.zip.RENAMED.

8Although the cover page will be a single page in most setups, the PDF cover page can extendmultiple pages

9The extracted attachment should be renamed by the recipient to the correct extension

44

5.8 Webmail 5 USERS

Auto rename attachments If set, files that match a rule from from the “At-tachments to rename” list will be renamed by appending the keyword from thesetting “Keyword to add to renamed attachments”.

Attachments to rename The list of filenames to rename. Multiple entriesshould be separated with space. Wilcard filename are supported.

Example: *.zip some-file.txt *.exe

5.7.3 Portal

Additional settings for the PDF reply portal page

Max. attachment size The maximum size (in bytes) of an attachment addedto the PDF reply.

Max. number of attachments The maximum number of attachments allowto add to the PDF reply.

5.7.4 Other settings

Attach original message as RFC822 (.eml) If selected, the original mes-sage will be attached to the PDF. The eml file can be opened in the local emailclient. All message content, like HTML email will be intact. An additional benefitis that the recipient can store the message in unencrypted form.

Background color This allows the admin to change the background color ofthe PDF to match the color of the cover page.

5.8 Webmail


Ciphermail Secure Webmail is a secure pull delivery webmail add-on to theCiphermail encryption gateway. If the rules of the Ciphermail encryption gate-way determine that a message must be encrypted, and S/MIME, PGP or PDFcannot be used, for example because there is no certificate for a recipient, theemail will be sent to the Ciphermail Webmail box via an S/MIME secured tun-nel. The recipient gets a notification that a new message is available. The firsttime the user receives a message, the user needs to select a secure password.The user can read and reply to the message using any web browser. This partonly briefly explains the webmail settings for the gateway and how the gatewayinteracts with the webmail appliance. For more details on how to install andconfigure the webmail appliance, see the “Ciphermail Webmail AdministrationGuide” and “Ciphermail Webmail Quick Start Guide”.

The following steps are taken when sending an email to a recipient via securewebmail (see figure 24):

45

5.8 Webmail 5 USERS

Figure 24: Webmail mail flow

1. User sends email via Exchange (or some other mail server)

2. Exchange forwards the message to the CipherMail gateway.

3. A rule on the CipherMail gateway flags that the email must be sent towebmail.

4. The message gets S/MIME signed with the webmail sender key and en-crypted with the webmail recipient certificate and forwarded via email tothe webmail appliance. The webmail appliance decrypts the mail, checksthe signature and places the email in the mailbox of the recipient(s).

5. A notification message is sent to the recipient that a message is availablefor pick-up.

6. The user logs-in with a browser via HTTPS and reads the message.

5.8.1 Webmail settings

The webmail settings page (see figure 25) can be opened by clicking the “web-mail” link on the settings page.

Enabled (S & R) If set, webmail will be enabled for the recipient.

Read receipt (S) If set, a read receipt header will be added to the messageand a read receipt message will be sent when the recipient has opened themessage. Alternatively, the sender can add a read receipt from the email clientwhen sending the message. An example of a read receipt message:

This is a Return Receipt for your message

To: test <[email protected]>Subject: demo webmailDate: 2015-06-26 16:34

Note: This receipt only acknowledges that the message was displayed on therecipient's computer. There is no guarantee that the recipient has read orunderstood the message contents.

46

5.8 Webmail 5 USERS

Figure 25: Webmail settings

Webmail recipient Email for the webmail appliance is routed to the webmailappliance via email. The “webmail recipient” is a specialized email address ofthe webmail appliance. The webmail appliance scans this email address foremail from the gateway. The “webmail recipient” is a required setting otherwisethe gateway is unable to route email to the webmail appliance.

Webmail sender Email for the webmail appliance needs to be S/MIME signedand is routed to the webmail appliance via email. The sender of the tunnel mes-sage, i.e., the message sent to the webmail appliance, is set to the “Webmailsender” address. The message is S/MIME signed with the key associated withthe “Webmail sender” address.

5.8.2 Webmail tunnel certificate

Because email for the webmail appliance needs to be S/MIME signed, a validsigning certificate must be available. A valid S/MIME signing certificate and pri-vate key for the webmail S/MIME tunnel can be created by clicking the “createwebmail certificate” link (see figure 25). On the “Create webmail tunnel certifi-cate” page, the email address of the certificate is set to the “Webmail sender”address. Additional subject information can be specified before the certificateis created (see figure 26). The generated certificate will be a self signed certifi-cate and automatically added to the certificate trust list.

Note: The “create webmail certificate” link is only available if the “Webmailsender” address is specified and applied.

47

7 TEMPLATES

Figure 26: Create webmail tunnel certificate

6 Domains

The domains page gives an overview of all the domains that have been ex-plicitly added by the administrator (see figure 27). A domain can be used tosetup preferences for all users of that domain. For example, a domain canbe added to create a secure S/MIME tunnel between two organizations. Be-cause all users from a specific domain inherit the preferences and certificatesfrom that domain, every email sent to a user in that domain will be encryptedwith the domain certificate. Normally a “virtual private network” (for example aTLS connection) is used for a secure tunnel between email servers. However,the problem with a VPN is that each intermediate email server must supportencrypted connections and each intermediate server needs to be fully trusted(the email is stored unencrypted on the email server until forwarded to the nexthop). When email is sent to domains which cannot be guaranteed to be secure(like for example Hotmail or Yahoo) use of an encrypted channel cannot beenforced. With S/MIME tunnelling, the message itself is encrypted and not justthe connection. Because the message itself is protected, it can be sent overan unsecured connection.

Wild-card domains are also supported. For example user “[email protected]”inherits the preferences and certificates from the wild-card domain “*.exam-ple.com” and from “example.com”. If a domain is in use (i.e., there is a userin the users list from that domain) the domain can no longer be removed (indi-cated by the missing red “cross”) until all users from that domain are removed.

7 Templates

Some actions require the gateway to send email or SMS Text messages. Thesemessages are created from message templates which can be modified by theadministrator10. The templates are MIME encoded messages. When modi-fying the templates, care should be taken that the templates are valid MIMEmessages. The following templates can be edited (see figure 28):

• encrypted PDF10The templates are processed using the Freemarker template engine (see http://

freemarker.sourceforge.net)

48

http://freemarker.sourceforge.net

http://freemarker.sourceforge.net

7 TEMPLATES

Figure 27: Domains

• Encrypted PDF via SMS

• Encrypted PDF OTP

• Encrypted PDF OTP invite

• Encryption failed notification

• Encryption notification

• Passwords notification

• SMS with password

• BlackBerry S/MIME

• SMS PFX password

• PFX email

• DLP warning

• DLP quarantine

• DLP block

• DLP error

• DLP release notification

• DLP delete notification

• DLP expire notification

Note: The “SMS PFX password” and “PFX email” templates can only beedited for the global settings.

49

7 TEMPLATES

Figure 28: Message templates

encrypted PDF The template for the final message of an encrypted PDFmessage. When a message is PDF encrypted the actual message content,including the attachments, is converted to an encrypted PDF. This encryptedPDF is then attached to a message and the message, with the encrypted PDF,is sent to the final recipient. The PDF attachment in the template is just a“dummy” PDF which will be replaced by the real encrypted PDF. This templateis used when the PDF password was not newly generated (i.e., the PDF pass-word was a static password or was still valid).

Encrypted PDF via SMS This template is similar to the “encrypted PDF” tem-plate. The only difference is that this template is used when the PDF passwordis newly generated and the password was sent via an SMS Text message tothe recipient.

Encrypted PDF OTP This template is similar to the “encrypted PDF” tem-plate. The only difference is that this template is used when the PDF passwordis generated using the one time password (OTP) functionality.

Encrypted PDF OTP invite This template is similar to the “Encrypted PDFOTP” template. The only difference is that this template is used when therecipient does not yet have a password set.

50

8 CERTIFICATES

Encryption failed notification Template used for the notification messagethat the message could not be encrypted but encryption was mandatory.

Encryption notification Template used for the notification message that themessage was successfully encrypted. This template is only used when thesender of the message has “Encryption notification” enabled (see page 25).

Passwords notification Template used for the notification message contain-ing newly generated passwords (see “Send to originator” on page 27 for moreinfo).

SMS with password Template for the SMS Text message containing the gen-erated password. The complete SMS Text message should fit in one SMS Textmessage (maximum 160 characters). The template should therefore not be toolarge.

BlackBerry S/MIME Template used for the S/MIME email message when therecipient preference “Recipient uses add-on” is enabled. Any S/MIME messagesent to a recipient having “Recipient uses add-on” enabled, is converted to amessage that can be read on a BlackBerry using the “Ciphermail for Black-Berry” add-on. See “Ciphermail for BlackBerry administration guide” for moreinformation.

SMS PFX password Template for the SMS Text message containing thepassword for the encrypted private key file. The complete SMS Text messageshould fit in one SMS Text message (maximum 160 characters). The templateshould therefore not be too large. For more information see the CA section 13.Note that this template can only be edited for the global settings.

PFX email Template for the email containing the password protected privatekey file (.pfx). For more information see the CA section 13. Note that thistemplate can only be edited for the global settings.

DLP templates For more information about the DLP specific templates, seethe separate “DLP setup guide”.

8 Certificates

Ciphermail gateway supports S/MIME for encryption and digital signing of emailmessages. S/MIME is based on PKI and X.509 certificates11. The system hasa built in X.509 certificate store. Certificates can be manually added and re-moved by the administrator. Certificates attached to incoming digitally signedmessages are automatically extracted from the signature and are added to the

11For more information on S/MIME and X.509 see http://en.wikipedia.org/wiki/SMIMEand http://en.wikipedia.org/wiki/X.509

51

http://en.wikipedia.org/wiki/SMIME

http://en.wikipedia.org/wiki/X.509

8 CERTIFICATES

Figure 29: Certificate store

“Certificates” store. The certificate store supports unlimited number of certifi-cates12. Intermediate and end-entity certificates are stored in the “Certificates”store and root certificates are stored in the “Roots” certificate store. The Cer-tificates page shows all the certificates in the “Certificates” store (see figure29).

Specific certificates can be searched with the certificate filter. Certificateswhich are not valid (not signed by a trusted root, revoked, expired etc.) areshown in gray. Certificates with an associated private key contain the “key”icon. Certificates which are revoked are shown in red.

Ciphermail gateway follows RFC 3280 (“Internet X.509 Public Key Infras-tructure Certificate and Certificate Revocation List Profile”). Selected certifi-cates can be downloaded or deleted. When a certificate is in use (by a user,domain or global settings) the certificate cannot be deleted (indicated by amissing “red cross”).

Certificate details can be opened by clicking on the certificate subject (seefigure 30). By clicking the “usage” sub-menu it is shown which users or domainsare using the certificate. The certificate details page can be used to get moreinfo as to why a certificate is not valid. For example, figure 30 shows thatthe certificate is not trusted because the certificate is not trusted by a rootcertificate (the certificate chain is incomplete).

The “Certificates” store can also contain private keys associated with theX.509 certificate. Private keys can be used for decrypting S/MIME encryptedmessages or for digital signing of messages. An entry with an associated pri-vate key has a non-empty “Key alias” (see for example figure 30). By uncheck-ing the “allow missing key alias” checkbox only certificates for which there is aprivate key available will be shown.

12Limited by the size of the database. If a HSM is used, the HSM can impose a limit on thenumber of certificates.

52

8.1 Importing Certificates 8 CERTIFICATES

Figure 30: Certificate details

The “Roots” store contains certificates which are fully trusted by the ad-ministrator (i.e., trust is explicit and not inferred from other certificates). The“Roots” store normally only contains certificates (i.e., the “Key alias” is alwaysempty).

Certificates can be manually imported by the administrator. Certificatescan also be added to the certificate store when an incoming S/MIME protectedemail has attached certificates. Any attached certificates are extracted fromthe message and are stored in the certificates store. Most S/MIME signedmessages contain at least the signing certificate.

The certificate can be added to the “Certificate Trust List” by clicking “addto CTL”. “Certificate Trust List” will be explained in section 12.

8.1 Importing Certificates

Certificates can be imported into a store with the “Import certificates” page(see figure 31). A certificate file, a store to import to and additional importparameters should be selected. Files with just one certificate (DER or PEMencoded) and files with multiple certificates (.p7b) are supported. Importing alarge number of certificates can take some time. After the import the “Importcertificates” page will show how many certificates were imported.

8.2 Importing keys

Certificates with associated private keys can be imported into the “Certificates”store using the “Import keys” page (see figure 32). A password protected“PKCS#12” private key file (.p12 or .pfx) must be selected and uploaded.

53

8.2 Importing keys 8 CERTIFICATES

Figure 31: Certificate import

Figure 32: Key import

54

8.3 Download certificates and keys 9 S/MIME

8.3 Download certificates and keys

Certificates and associated private keys can be downloaded from the gateway.Select the certificates that need to be downloaded and click “download certifi-cates” or “download keys” from the sub-menu. When downloading private keys,a password used for encrypting the private key file (.p12 file) must be entered.

9 S/MIME

In this section a brief introduction of S/MIME will be given. S/MIME is based on“Public Key Infrastructure” (PKI) and uses X.509 certificates.

9.1 PKI

Public Key Infrastructure is a technology which can be used to securely ex-change information over insecure networks using public key cryptography. PKIuses X.509 certificates to bind a public key to an identity. The main advantageof PKI is that there is no need to directly trust everyone involved because trustcan be inferred. Roughly speaking there are two trust models in use today:hierarchical (via trusted CAs) or “Web Of Trust”.

With the hierarchical trust model, trust is inferred bottom-up. The root (thebottom) is blindly trusted (that makes it by definition a root) and all leaf nodesand branches (the end-user and intermediate certificates) are trusted becausethey are child’s of the trusted root (to be precise the intermediate certificatesare issued by the root certificate). S/MIME uses a hierarchical trust model.

In a “Web of Trust” model, trust is inferred from trusted neighbours in a meshlike structure (a web). For example: “Alice” trusts “Bob” and “Ted” trusts “Alice”and therefore “Ted” now also trusts “Bob” (through “Allice”). The hierarchicalmodel can be viewed as a “Web of Trust” model with additional constraints.

Because trust is inferred from other entities, it is possible to securely checkwhether one entity trusts another entity and that it is not possible to “spoof” anytrust. Trust checking is done using “Public Key Cryptography”. An intermediatecertificate is digitally signed by the issuer of the certificate using the issuersprivate key. With the public key of the issuer, it can be checked whether thecertificate was really issued by the issuer. The public key together with someextra information forms an X.509 certificate.

9.2 X.509 certificate

A typical X.509 certificate contains the following elements (this is a non-exhaustivelist):

• Public Key

• Subject

• Email address

• Issuer

55

9.2 X.509 certificate 9 S/MIME

• Serial Number

• Not Before

• Not After

• Key Usage

• Extended Key Usage

An X.509 certificate is digitally signed by the issuer of the certificate. By digitallysigning the certificate, any changes done after signing will break the signature.Any changes to the certificate will therefore be noticed. A brief introduction ofsome of the main elements of an X.509 now follows.

Public Key The public key, like the name already implies, is the key thateveryone is allowed to know. If a message must be encrypted, the public keyof the recipient is used for encryption. The public key is used to verify a digitalsignature (the digital signature is created with the associated private key).

Subject The subject of a certificate contains the name of the “owner” andoptionally an email address (or sometimes multiple email addresses).

Email address A certificate can contain multiple email addresses. X.509certificates for S/MIME should normally contain the email address for whichthe certificate was issued.

Issuer The issuer contains the name of the issuer of this certificate (i.e., theissuer element should be equal to the subject of the issuer). If the subject ofa certificate is equal to the issuer of a certificate the certificate is most likely aself-signed certificate. Root certificates are almost always self-signed.

Serial Number Every certificate should have a serial number. The serialnumber should be unique for the issuer (i.e., an issuer should use the serialnumber only once).

Not Before This is the date at which the certificate becomes valid. If thecurrent date is before the “Not Before” date, the certificate is not yet valid.

Not After This is the date at which the certificate is no longer valid. If thecurrent date is after the “Not After” date, the certificate is no longer valid.

Key Usage The public key of the certificate can be used for multiple pur-poses. Sometimes however the issuer of the certificate wants to restrict thekey usage to only certain types. The following key usage types can be identi-fied:

• digitalSignature

56

9.2 X.509 certificate 9 S/MIME

• nonRepudiation

• keyEncipherment

• dataEncipherment

• keyAgreement

• keyCertSign

• CRLSign

• encipherOnly

• decipherOnly

If the key usage is not specified it implies that the key may be used for allpurposes. For S/MIME encryption, if a key usage is specified it should at leastcontain “keyEncipherment”. For S/MIME signing, if a key usage is specified itshould at least contain “digitalSignature” or “nonRepudiation”.

Extended Key Usage The extended key usage, if specified, further specifiesfor what purposes the certificate has been issued. The following extended keyusages can be identified:

• anyKeyUsage

• serverAuth

• clientAuth

• codeSigning

• emailProtection

• timeStamping

• OCSPSigning

• IPSecEndSystem

• IPSecUser

• IPSecTunnel

• smartcardLogin

If the extended key usage is not specified it implies that the key may be usedfor all purposes. For S/MIME, if an extended key usage is specified, it shouldat least contain “anyKeyUsage” or “emailProtection”.

Thumbprint The thumbprint is strictly speaking not part of an X.509 certifi-cate. The thumbprint is the “cryptographic hash”13 calculated over the bytes ofthe encoded certificate. The thumbprint uniquely identifies a certificate. Thedefault algorithm used by the Ciphermail gateway for calculating the thumbprintis “SHA-512”.

13See http://en.wikipedia.org/wiki/Cryptographic_hash_function for more info oncryptographic hash functions.

57

http://en.wikipedia.org/wiki/Cryptographic_hash_function

9.3 Revocation checking 10 CERTIFICATE SELECTION

9.3 Revocation checking

Sometimes it can happen that a certificate should no longer be used. Forexample because the “private key” has been compromised or an employeehas left the company. Certificates can be revoked by putting the certificates ona “Certificate Revocation List” (CRL). A CRL is issued by a certificate authority(CA) and is periodically updated. A revoked certificate should no longer beused. When a CRL is not available or when the administrator would like to“black list” a specific certificate, the certificate can be added to the “CertificateTrust List” (CTL). For more info on CTL see section 12.

10 Certificate selection

When required the Ciphermail gateway will automatically select the correct cer-tificates for signing and encryption. Only certificates that are valid (i.e., trusted,not expired, not revoked) are automatically used. This implies that certificatesshould be trusted by a root certificate. The root certificate store by default doesnot contain any certificates14. The administrator should therefore add all theroot certificates trusted by the organization to the root store. If a root certificateis not available a certificate can be “white listed” by adding the certificate to the“Certificate Trust List”.

10.1 Encryption certificate selection

Encryption certificates can be selected for a user, a domain or for the globalsettings. The “select encryption certificates” page can be opened by clickingthe “select encryption certificates” sub-menu on the preference page (see fig-ure 18). The “select encryption certificates” page shows all the certificatesthat have been selected for the user (or domain or global settings). When thecertificate selection page has been opened, by default, only certificates withmatching email addresses will be shown (see figure 33).

Each user can have an unlimited number of associated certificates. Thesystem tries to automatically select the certificates for a user based on strictPKI rules. The certificate will only be automatically selected when the emailaddresses match. If a certificate is not automatically selected (for example theemail address in the certificate does not match the email address of the user)the administrator can force the usage of a certificate by manually selecting thecertificate for this particular user. Figure 33 Shows that multiple certificates areselected for user “[email protected]”.

When a message is S/MIME encrypted all of the selected certificates for therecipient are used. This allows the recipient to open the message with one theprivate keys associated with one the public keys used for encryption. The mainadvantage of using all of the selected certificates is that it allows the recipient touse different keys for decryption. For example, the key stored on the recipientshome computer can be used when the message is read at home and the keyon the office computer can be used when the message is read at the office.

14A collection of some well known CA certificates can be downloaded from the Ciphermailwebsite.

58

10.1 Encryption certificate selection 10 CERTIFICATE SELECTION

Figure 33: Select encryption certificates

Figure 34: Color coding

The sender does not known at which location the recipient will open the emailso it’s better to encrypt the message with both certificates.

Color coding The selected certificates are color coded based on validity andinheritance of the certificates (see figure 34):

Certificates can be manually selected and deselected by selecting the cer-tificate checkbox and applying the settings. Automatically selected certificatescannot be deselected (the certificate can be completely removed if the certifi-cate is no longer required). Uncheck “Auto select certificates” for the user ifautomatic selection of certificates for the user is not required.

Even when a certificate is manually selected it does not automatically meanthat the certificate will be used for encryption. If a certificate is not valid it’s notused for encryption. For example figure 33 shows that two certificates aremanually selected. One certificate is however not valid (“gray color”) because ithas expired. This certificate is therefore not used when a message is encryptedfor this user. If a manually selected but invalid certificate must be used, thecertificate must be made valid (add for example the certificate to the CTL tomake it valid).

Besides selecting certificates, the “Select encryption certificates” page sup-ports the creation of new end-user certificates for external users with the built-inCA server. A certificate can also be securely transported via email to an exter-nal end-user. For more information on the built-in CA functionality see section

59

10.2 Signing certificate selection 10 CERTIFICATE SELECTION

Figure 35: Select signing certificate

13.

10.2 Signing certificate selection

A signing certificate can be selected for a user, a domain or for the global set-tings. The “select signing certificate” page can be opened by clicking the “se-lect signing certificate” sub-menu on the preference page (see figure 18). The“select signing certificate” page shows the signing certificate that has been se-lected for the user (or domain or global settings). When the certificate selectionpage has been opened, only certificates with matching email addresses will beshown by default (see figure 35). Only certificates with an associated privatekey can be selected and only one signing certificate per user can be selectedat the same time. The system tries to automatically select a signing certificateby searching for a valid certificate with a matching email address. If there aremultiple certificates suitable for signing, the first certificate found will be se-lected. The administrator can override the automatically selected certificate bymanually selecting another certificate. If a certificate was manually selectedthe selected certificate can be reverted back to an automatically selected cer-tificate by pressing “auto select certificate”.

10.3 Additional certificates

If a message is S/MIME encrypted, the message can also be encrypted withadditional certificates. For example, a company policy might dictate that allencrypted data should be readable even when the sender and or recipient nolonger have access to the private key (key escrow). Another reason to encryptthe data with an additional encryption certificate is that it allows a centralizedvirus scanner to scan the email. Additional certificates can be selected using

60

11 CERTIFICATE REVOCATION LIST (CRL)

Figure 36: CRL store

the “additional certificates” sub-menu (see figure 33). Additional certificatesare inherited just like regular encryption certificates and can be selected for theglobal settings, the domain settings or for a user.

Note: Anyone with access to the private key of the additional certificate(s)can in principle decrypt all encrypted email. The private keys of the additionalcertificates should therefore be stored in a safe place and only be used whenrequired.

11 Certificate Revocation List (CRL)

A certificate revocation list (CRL) is a list of certificates15 which have beenrevoked and which should therefore no longer be used. Certificates can contain“CRL distribution points”. A “CRL distribution point” contains URLs from whichthe latest CRL can be downloaded. Periodically all the URLs from all the “CRLdistribution points” for all the trusted certificates16 are collected and the latestCRLs are then downloaded from these URLs17. The downloaded CRLs arestored in the CRL store (see figure 36).

CRL details can be viewed by clicking the CRL “Issuer” link (see figure 37).CRLs which are not valid (incorrectly signed, no path to a trusted root etc.)are shown in gray. The details page provides more information on why a CRLis not valid. By default the CRL store is periodically updated every 12 hours.A CRL update can be forced by clicking “update CRL store” in the sub-menu.The CRL entries (the serial numbers of the revoked certificates and optionallya revocation reason) can be downloaded as a text file by clicking “downloadCRL entries” (see figure 37).

15to be precise it’s actually a list of serial numbers issued by the CA16by default, CRLs will only be downloaded from valid certificates17CRL distribution over HTTP(s) and LDAP is supported.

61

12 CERTIFICATE TRUST LIST (CTL)

Figure 37: CRL details

Note: Some CRLs contain an extremely large number of revoked certificates.Downloading the entries of these large CRLs is therefore not advised.

12 Certificate Trust List (CTL)

A Certificate Trust List (CTL) is a list of certificates (to be precise, a list ofcertificate thumbprints) which are explicitly trusted (“white listed”) or explicitlydistrusted (“black listed”). The administrator can manually add or remove cer-tificates to the Certificate Trust List.

In most cases PKI is sufficient for deciding whether or not a certificate is valid.Sometimes however, the administrator needs more control over this automaticprocess. Some examples when a CTL can be helpful:

(a) A certificate should no longer be used because it was compromised but thecertificate issuer does not have a CRL. In this case the administrator can“black list” the certificate.

(b) A certificate is not valid because the root is missing. The administratorhowever knows that the certificate is valid (for example the thumbprinthas been checked over the phone). After “white listing” the certificate theadministrator can manually select the certificate for a user.

(c) A certificate is not valid because the certificate has expired. However, theadministrator is 100% certain that the certificate is still ‘valid’. By “whitelisting” the certificate and checking the “Allow expired” checkbox the cer-tificate can now be manually selected.

By clicking “Certificate Trust List” on the left hand side menu of the certificatespage (see figure 38) the “Certificate Trust List” can be opened. The “CertificateTrust List” contains the thumbprints of all the certificates that have been addedto the CTL (see figure 39). A new entry can be added to the CTL by clicking

62

12 CERTIFICATE TRUST LIST (CTL)

Figure 38: Open Certificate Trust List

Figure 39: Certificate Trust List

“Add CTL entry” on the left hand side menu. A CTL entry does not directlycontain a certificate, it contains the thumbprint of a certificate. The reason forthis is that it should be possible to “white list” or “black list” a certificate even ifthe certificate is not available in the certificate store. An expired certificate canbe made valid by by checking “Allow expired”. “Allow expired” is only applicablewhen “white listing” a certificate.

Trust inheritance “Black listing” a certificate is inherited by certificates is-sued by that certificate. This means that if an intermediate certificate is “blacklisted” all certificates, directly or indirectly, issued by that intermediate certifi-cate are also “black listed”. “White listing” is not inherited. If an intermediatecertificate is “white listed”, certificates issued by that intermediate certificateare not automatically “white listed”. For a certificate to be “white listed” it hasto be explicitly added to the “Certificate Trust List”.

Example: Suppose a trusted root has issued multiple intermediate certifi-cates. Normally all the intermediate certificates issued by that root are trusted.The administrator however does not trust one of the intermediate certificates.Removing the root from the root store won’t help because the result would bethat none of intermediate certificates are trusted. By “black listing” one of theintermediate certificates all certificates issued by that intermediate certificate

63

13 CERTIFICATE AUTHORITY (CA)

Figure 40: Certificate Trust List Icons

Figure 41: “white listed” and “black listed” certificates

will also be (implicitly) “black listed”.

CTL icons When a certificate is “white listed” or “black listed” an icon is addednext to the email address of the certificate (see figure 41). The green icon isshown when the certificate is “white listed” and the yellow icon is shown whenthe certificate is “black listed” (see figure 40). Clicking one of the icons willopen the CTL entry page for the certificate.

Note

The “Certificate Trust List” should normally only be used as a “workaround” when the standard PKI rules are not sufficient.

13 Certificate Authority (CA)

The gateway contains a built-in CA server which can be used to create end-user certificates for internal and external users. This helps to quickly setup anS/MIME infrastructure without having to resort to external CAs for certificatesand keys. Certificates and private keys can be securely transported to externalrecipients using a password encrypted certificate store (.pfx). The externalrecipients can use the certificate with any S/MIME capable email client like“Outlook”, “Outlook express”, “Lotus Notes” and start receiving and sendingS/MIME encrypted email without having to install additional software.

The Ciphermail gateway contains a pluggable framework which allows newcertificate request handlers to be registered. A certificate request handler is

64

13.1 Create new CA 13 CERTIFICATE AUTHORITY (CA)

responsible for creating and/or retrieving a certificate and private key from in-ternal or external CAs. By default, there are currently three certificate requesthandlers available: “built-in”, “delayed built-in” and “EJBCA”.

A brief explanation of the CA functionality will now follow. For a more thor-ough overview on how to setup the S/MIME infrastructure see the separate“S/MIME setup guide”.

Note

The built-in CA has limited functionality. For support of multiple CA pro-files, OCSP etc., use a dedicated external CA (for example EJBCA).

13.1 Create new CA

Before starting to create end-user certificates, a root and intermediate certifi-cate should be created18. The “Create new CA” page (see figure 42) can beused to create a new CA (i.e., create a new intermediate and root certificate).

Some details about the root and intermediate certificates should be speci-fied before the certificates can be created (see figure 42).

Validity The number of days the root or intermediate certificate is valid (start-ing from the day it was created). This is a mandatory property.

Key length The length of the public key in bits (1024, 2048 and 4096). A2048 bits key is sufficient is most cases. This is a mandatory property.

Email The email address that will be added to the certificate. Leave it empty(unless your policy requires an email address for your CA).

Common name The “common name” of the certificate is the main identifier ofthe certificate. The common name of the root certificate must be different fromthe common name of the intermediate certificate. Choose a unique commonname and do not reuse a common name.

More Selecting “more” enables the following advanced settings for the sub-ject: “organization”, “first name” and “last name”. These settings are only usedto make it easier for end users to identify the CA certificates.

Make default CA If checked, the newly created CA will be the default CA.

Signature algorithm The algorithm used for signing the root and intermedi-ate certificate.

18If a root and intermediate certificate is already available import them into the certificate androot store.

65

13.1 Create new CA 13 CERTIFICATE AUTHORITY (CA)

Figure 42: Create new CA

66

13.2 CA settings 13 CERTIFICATE AUTHORITY (CA)

Figure 43: CA settings

13.2 CA settings

When the “Create new end-user certificate” page is opened the default dialogvalues are taken from the “CA settings”. The “CA settings” can be openedfrom the CA settings sub-menu (see figure 43). The settings “Common name”,“Validity”, “Key length” and “Signature algorithm” were already explained (seepage 65)

CA email The sender email address used when sending certificates to end-users by email. Make sure that the CA email address is a valid email address.Because the email containing the encrypted certificate is sent by the gateway,the settings for the CA email user should be such that the email is not encryptedby the gateway (i.e., set encrypt mode of the CA user to “No Encryption”). If acertificate and key must be sent to an external recipient the CA email address

67

13.3 Certificate Request Handlers 13 CERTIFICATE AUTHORITY (CA)

must be set.

Note

Set “encrypt mode” of the CA user to “No Encryption”.

Password length The certificate creation page can automatically generate apassword for the encrypted private key container (.pfx). The number of randombytes used to generate the password is set with the password length.

Store password This will be the default value for “Store password” for the“Create new end-user certificate” page. If checked the password for the lastgenerated pfx file for a user will be stored in the “Last used pfx password”preferences of the user (see 5.2.12).

Add CRL dist. Point This is the default value for “Add CRL dist. Point” forthe “Create new end-user certificate” page. If checked, and the CRL distribu-tion point is set, the CRL distribution point value will be added to the newlygenerated end-user certificate.

CRL dist. Point The CRL distribution point added to the end-user certificate.The CRL distribution point is only added if “Add CRL dist. Point” is set. Thisis the default value for the “CRL distribution point” setting for the “Create newend-user certificate” page.

Certificate Authority The default CA used when a certificate is requested.The default “Certificate Authority” is for example used when a certificate is au-tomatic requested for a sender when the sender does not yet have a validsigning certificate and “Auto request certificate” is enabled for the sender. Seesection 13.3 for more information on “Certificate Request Handlers” and Cer-tificate Authorities.

13.3 Certificate Request Handlers

A certificate request handler is responsible for creating and/or retrieving a cer-tificate and private key from internal or external CAs. The Ciphermail gatewaycontains a pluggable framework which allows new certificate request handlersto be registered. By default, there are currently three certificate request han-dlers available: “built-in”, “delayed built-in” and “EJBCA”.

Some certificate request handlers should be setup before they can be used.Certificate request handlers can register a configuration page which can beused to setup the certificate request handler. The available certificate requesthandler configuration pages can be accessed using the “Request handlers”left-hand side menu on the “CA” page. The “Registered Certificate RequestHandler configuration pages” page shows all registered certificate request han-dler configuration pages (see figure 44).

68

13.4 Create new end-user certificate 13 CERTIFICATE AUTHORITY (CA)

Figure 44: Registered Certificate Request Handler configuration pages

13.3.1 built-in certificate request handler

The built-in certificate request handler uses the built-in CA for creating newcertificates. Certificates created with the built-in certificate request handler willbe issued by the default selected CA (see section 13.5 for more informationon selecting the default CA). The built-in certificate request handler createsa private key and certificate instantly without any delay (i.e., a request for acertificate is synchronously handled).

13.3.2 delayed built-in certificate request handler

The delayed built-in certificate request handler is similar to the built-in certificaterequest handler. The only difference is that with the delayed certificate requesthandler, the request will be handled asynchronously by the background requesthandler thread.

If “Auto request certificate” (see page 31) is enabled and message through-put should not be impacted when a new certificate is requested, it’s better touse the delayed built-in certificate request handler because all certificate re-quests will then be handled asynchronously. If however a certificate shouldbe used immediately when requested, the built-in certificate request handlershould be used.

13.4 Create new end-user certificate

With the CA page a new end-user certificate can be created (see figure 45).Before an end-user certificate can be created a CA should be available. Awarning will be shown if no CA is available or if a default CA is not selected.The general and Certificate subject settings have already been discussed.

Email delivery The email delivery settings are required when the newly cre-ated certificate and private key should be securely sent to an external recipient.If the “Send by email” checkbox is checked a password used for the protectionof the certificate and private key should be set.

A password can be randomly generated by pressing the “gear” icon on theright hand side of the password edit field. If a password is manually set makesure that the password is strong enough. The password should be handed outto the recipient in a secure way i.e., it should not be emailed. For example send

69

13.4 Create new end-user certificate 13 CERTIFICATE AUTHORITY (CA)

Figure 45: Create end-user certificate

70

13.5 Select default CA 13 CERTIFICATE AUTHORITY (CA)

Figure 46: Select default CA

it by regular post or give the password in person. Alternatively the gateway cansend the password via an SMS Text message.

SMS password If the “SMS password” checkbox is checked the passwordfor the protected certificate and private key file will be sent to the recipient viaan SMS Text message. This requires that the SMS gateway is correctly setup(see section 18) and that the recipients telephone number is added to the usersettings of the recipient.

Store password If checked the password for the last generated pfx file fora user will be stored in the “Last used pfx password” preferences of the user(see 5.2.12).

Advanced settings With the advanced settings page the CRL distributionpoint for the certificate can be specified. A CRL distribution point should be afully qualified URL pointing to the location where the latest CRL for the CA canbe downloaded. If a CRL for the CA should be created and published makesure that the correct URL is specified. The URL cannot be changed after thecertificate has been issued. The default value for the CRL distribution point istaken from the CA settings.

When the create button is clicked, and only if all the settings are valid, a newend-user certificate is created. If “Send by email” was checked the certificateand key will be password protected with the password and sent to the recipientby email. If “SMS password” was checked the password will be sent via anSMS Text message to the recipients telephone number. For a more thoroughexplanation of this procedure see the “S/MIME administration guide”.

13.5 Select default CA

There can be multiple CAs but only one can be active at the same time. Selectthe default CA with the “Select default CA” page (see figure 46).

71

13.6 Pending requests 13 CERTIFICATE AUTHORITY (CA)

Figure 47: Pending certificate requests

13.6 Pending requests

Some certificate request handlers do not immediately issue a certificate (i.e.,the certificate is asynchronously issued). For example the Comodo certificaterequest process requires several steps (see appendix F for more information).Certificate requests which are not immediately handled are stored in the “pend-ing requests” store and handled asynchronously by a background thread (seefigure 47).

13.7 Bulk request

With the bulk request option, multiple certificate requests can be issued at thesame time. A comma separated text file containing the request details can beuploaded (see figure 48). The certificates will be requested using the selectedcertificate request handler. To make sure that the request details are correctlyimported, a preview of the imported certificate requests will be shown afterpressing “Request preview” (see figure 49). See appendix G for details of thecomma separated file format.

Note: Certificate requests for email addresses for which there already is avalid signing certificate, will be skipped.

13.8 Create CRL

Sometimes a certificate should no longer be used even when it is not yet ex-pired. A certificate revocation list (CRL) is used to revoke a specific certificateissued by a CA. With the “Create CRL” page a CRL for the internal CAs can becreated or updated. Before the CRL can be created the CA, which will issuethe CRL, must be selected (see figure 50).

After selecting the CA the “Create CRL” page is opened on which the cer-tificates that should be revoked can be added to the list of revoked certificates.A brief explanation of the dialog fields:

Serial numbers A certificate issued by a CA is uniquely identified by theserial number. The serial numbers list contains all the serial numbers that areabout to be revoked.

72

13.8 Create CRL 13 CERTIFICATE AUTHORITY (CA)

Figure 48: Bulk request

Figure 49: Certificate request preview

73

13.8 Create CRL 13 CERTIFICATE AUTHORITY (CA)

Figure 50: Create CRL

74

13.9 Send certificates 13 CERTIFICATE AUTHORITY (CA)

Revoked certificate Add a new certificate to the list of certificates to be re-voked by entering the serial number of the certificate (in hex form) in the “Re-voked certificate” edit box and clicking the “Add” button.

Next update The “next update” is the date at which the CA claims it will issuea new CRL19. If the CA contains a CRL distribution point (see section 13.1)make sure that a new CRL is available and download-able from the CRL distri-bution point before the CRL expires. The next update is specified in days fromthe date of the CRL creation.

Update existing CRL If “update existing CRL” is selected an existing CRLis updated with the new serial numbers. The new CRL will contain the serialnumbers of the old CRL and the new serial numbers. If “update existing CRL”is not selected a completely new CRL will be created with only the new serialnumbers. It’s best to always update an existing CRL because certificates thatare previously revoked should remain revoked.

Signature algorithm The CRL will be signed by the issuing CA. A CRLshould be signed to make it possible for external parties to check whether theCRL is a valid CRL and is issued the CA. Windows versions prior to “XP-sp3”do not support “SHA256 With RSA” or better. If older Windows versions shouldbe supported you are advised to use “SHA1 With RSA”. If support for older Win-dows versions is not required you are advised to select “SHA256 With RSA”.

Clicking the “Create CRL” button will create the new CRL. The new CRL will beautomatically added to the CRL store (see section 11). If the CA specifies aCRL distribution point the CRL should be published. Download the CRL fromthe CRL store and upload it to the CRL distribution point URL.

13.9 Send certificates

Sometimes end-users require a copy of their certificates (and private keys). Forexample they experienced a system crash and had to completely reinstall thesystem (and forgot to make a backup).

The “Send certificates” page can be used to send a new copy of the certifi-cate and private key to an external user. This is also known as “key escrow”.Clicking “Send certificates” opens the “Send selected certificates to recipient”page (see figure 51). Sending CA certificates by email is not allowed. This isdone to prevent accidental leakage of CA certificates.

Password This has already been explained. See section 13.4.

SMS password This has already been explained. See section 13.4.19The next update is the date at which a new CRL must be available. A CA is allowed to issue

a new CRL before this date.

75

13.9 Send certificates 13 CERTIFICATE AUTHORITY (CA)

Figure 51: Send selected certificates to recipient

76

14 OPENPGP

Figure 52: PGP keyring

Email This is the email address of the recipient to which the certificate(s) andkey(s) will be sent.

Allow mismatch By default, email addresses in the certificate must matchthe email address of the recipient. However, there are situations where thecertificate and private key should be sent to to a different email address. Bychecking “Allow mismatch” the certificates and keys can be sent to non match-ing email addresses. The “Allow mismatch” check is added to prevent anyleakage of certificate(s) and key(s) because of an accidental mistype of therecipients email address.

14 OpenPGP

OpenPGP is an email encryption and digital signing standard which is similarto S/MIME. OpenPGP works with public and secret keys. Public keys canbe signed by other public keys (although in practise most keys are only self-signed). PGP public keys can be published to public accessible key servers.Public keys can be downloaded from public key servers if a public key is not yetlocally available for a recipient.

OpenPGP supports two forms of encoding: PGP/MIME and PGP/INLINE.With PGP/MIME the MIME message (HTML parts and attachments) is signedand/or encrypted as a whole. With PGP/INLINE, every part of the messageis individually signed and/or encrypted. Since PGP/MIME keeps the structureof the original message intact and supports HTML, PGP/MIME is strongly ad-vised. The PGP keyring stores all the public and secret keys (see figure 52).Keys with an associated private key are shown with a yellow key symbol nextto the Key ID.

14.1 Importing keys

Secret and public key rings can be imported from a file by clicking “Importkeyring” on the left hand side menu (see figure 52). On the import key ring

77

14.2 Creating keys 14 OPENPGP

Figure 53: Import PGP key ring

page the key ring file and a password (if importing a secret key ring) should bespecified (see figure 53).

14.2 Creating keys

A new secret key ring can be created by clicking “Create keyring” on the left-hand side menu. On the PGP key ring page, the email address which will beused for the User ID, the name and the key size of the generated keys can bespecified (see figure 54). If “Publish key” is selected, the generated key ringwill be automatically published to the registered key servers. The generatedsecret key ring will be added to the key ring and automatically trusted.

14.3 Search keys

With the “Search keys” page, a search can be done for a key on the registeredkey servers. The search keys page can be opened by clicking “Search keys”on the left-hand side menu. The keys returned from the search can be down-loaded and imported into the key ring by selecting the keys and then selecting“import selected” (see figure 55). Imported keys are not automatically trustedunless the checkbox “Automatically trust imported key” is selected.

Note

Searching for key ID or fingerprint requires that the search query is pre-fixed with 0x. For example, to search for a key with key ID 271AD23B,the search query should be 0x271AD23B.

78

14.3 Search keys 14 OPENPGP

Figure 54: Create PGP secret key ring

Figure 55: Search PGP keys

79

14.4 Key servers 14 OPENPGP

Figure 56: PGP key servers

14.4 Key servers

The list of registered key servers can be managed by clicking “Key servers”.Key servers can be added or removed (see figure 56).

Note

Currently only key servers that support the OpenPGP HTTP KeyserverProtocol (HKP) are supported.

14.5 Key details

The details page of a key can be opened by clicking the Key ID of the key. Thekey details page shows the most relevant key parameters. If the key is a masterkey and the key contains sub keys, all the sub keys will be shown below thekey details (see figure 57). The details of a sub key can be shown by clickingthe Key ID of the sub key.

14.6 Key trust

A key by default is not trusted. The trust level of a key can be managed byclicking “key trust”.

14.7 Publish public key

The public key (including the sub keys) can be published to the registered keyservers by clicking “publish public key”.

Note: the public public key option is only available for a master key.

80

14.8 Email addresses 14 OPENPGP

Figure 57: PGP key details

14.8 Email addresses

Before a key can be used, it has to be associated with an email address. Whena key gets imported, it is automatically associated with the email address ex-tracted from the User IDs. Quite often however the email address from theUser ID is outdated. Either because the email address is no longer used or theowner of the PGP key is using a new email address. By clicking the “Email ad-dress” sub menu on the key details page (see figure 57), the email addressesassociated with the key can be managed. Associated email addresses can beadded or removed (see figure 58).

14.8.1 domains

In addition to email addresses, a domain can also be associated with a key.This makes it possible to use the key as a domain key (i.e., encrypt all email tothe domain with the domain PGP key).

Note: email addresses can only be associated with a master key.

14.9 Revoke key

A key for which there is a private key can be revoked. A revoked key can nolonger be used. After revoking a key it’s advised to (re) publish the key to the

81

14.10 Key selection 14 OPENPGP

Figure 58: Associated email addresses

key servers.

14.10 Key selection

When sending email the gateway will automatically select the keys for encryp-tion and signing. Whether or not a key is used for encryption and/or signingdepends on a number of factors. The requirements for encryption keys aredifferent then the requirements for signing keys.

14.10.1 Email encryption key

A key will be used for encryption if the following key requirements are met:

1. The key must be trusted

2. The key must not be expired

3. The key must not be revoked

4. The email recipient must match an associated email address or domainof the key

5. The key must be valid for encryption

The encryption key will be automatically selected for every recipient. Tocheck which keys are selected for a recipient a search for the email address(or domain) can be executed on the PGP keyring page. Another way to checkwhich key is selected for a recipient or domain is by adding a user or domainand selecting “encryption keys” of the PGP pulldown menu on the user or do-mains settings page (see figure 59). The selected encryption keys for the re-cipient (or recipients domain if a domain was selected) will be shown on PGPencryption key page (see figure 60). If there are multiple valid keys availablefor a recipient, the email will be encrypted with multiple keys.

82


Figure 59: PGP encryption keys menu

Figure 60: PGP encryption keys

14.10.2 Email signing key

A key will be used for digital signing if the following key requirements are met:

1. A private key is available

2. The key must be trusted

3. The key must not be expired

4. The key must not be revoked

5. The from sender address must match an associated email address ordomain of the key

6. The key must be valid for signing

The signing key will be automatically selected for a sender. To check whichsigning key is selected, add a user or domain and select “Signing key” of thePGP pulldown menu on the user or domains settings page (see figure 61).The selected signing key for the sender (or senders domain if a domain wasselected) will be shown on PGP signing key page (see figure 62). Only theselected signing key will be used for signing. If there are multiple keys whichcan be used for signing are available, a new signing key can be set by selectingthe signing key and applying the settings.

83


Figure 61: PGP signing key menu

Figure 62: PGP signing keys

84

15 PDF ENCRYPTION

15 PDF encryption

The problem with S/MIME is that it requires the recipient to use an S/MIME ca-pable email client20 and the recipient must have a certificate and a private key.Although installing a certificate and a private key is not hard, even less so whenusing the gateways built-in CA functionality, it may still be too cumbersome forsome recipients. Especially when only a few secure email messages need tobe exchanged over a longer period.

As an alternative to S/MIME encryption, PDF encryption can be used. ThePDF standard allows a PDF to be encrypted with a password21. Files canbe added to the PDF and are encrypted as well. Because most recipientsalready have a PDF reader installed they do not need to install or configureany software.

When the gateway PDF encrypts a message it converts the complete emailmessage, including all attachments, to a PDF. The PDF is then password en-crypted and attached to a new message (which is based on a template). Thismessage does not contain any information other than a general note that themessage contains an encrypted PDF (see section 7 for the templates). Thereare different options on how to password encrypt the PDF:

(a) The PDF can be encrypted using a pre-defined static password.

(b) The PDF can be encrypted using randomly generated password. Thepassword will then be sent by SMS Text to the recipient.

(c) The PDF can be encrypted using randomly generated password. The pass-word will be sent back to the sender of the message.

(d) The PDF can be encrypted using a one time password (OTP) algorithm.

The four password options will be briefly explained. For more details see thePDF encryption guide.

Static password To use a pre-defined and static password for PDF encryp-tion, the password for the recipient should be set. To make sure that the pass-word will always be valid (i.e., that it will never expire), either set the “Validityinterval” to -1 or make sure that the “Date set” password setting is not set.

Send password by SMS Text If setup correctly, the system can automaticallysend the generated password to the recipient via an SMS Text message. Thisrequires that the SMS “Phone number” is set for the recipient. Alternatively, ifthe user is allowed to add a telephone number to the subject (see page 41), themobile number can be specified on the subject of the email. Figure 63 showsthe complete PDF encryption process when using the SMS option.

Send to originator If the “Send to originator” option is enabled, the gener-ated password(s) will be sent back to the sender of the message. The senderis then responsible for securely delivering the passwords to the recipients.

20Most email clients however support S/MIME out of the box21The PDF is encrypted with AES128 with a key based on the password.

85

15.1 Encrypted PDF message 15 PDF ENCRYPTION

Figure 63: PDF encryption

One time password (OTP) If the one time password option is enabled, thePDF password will be generated using a one time password algorithm. Therecipient can login to the portal to retrieve the PDF password.

15.1 Encrypted PDF message

The recipients receives a message with a standard message (based on a tem-plate) with the encrypted PDF attached (see figure 64 for an example openedin Gmail). When the PDF is opened, the PDF reader asks for the password(see figure 65). Only after entering the correct password will the PDF contentbe shown. The PDF is formatted to make it look like a normal email message.The attachments can be accessed from the attachment pane at the bottom(see figure 66).

15.2 Replying

A recipient can reply to the encrypted PDF message by clicking the “Reply”link (see figure 64). An on-line portal, via a secure “HTTPS” connection, will beopened (see figure 67). The reply URL in the PDF is equal to the “Reply URL”parameter at the time the encrypted PDF was created (see paragraph 5.2.4).The user can now enter a message body and add attachments (by defaultmaximum 3). The reply will be sent via the Ciphermail gateway. Because thereply is sent via the Ciphermail gateway it can be encrypted as well (see “ReplySender” at page 35).

86

15.2 Replying 15 PDF ENCRYPTION

Figure 64: PDF encrypted message

Figure 65: PDF encrypted message

87

15.2 Replying 15 PDF ENCRYPTION

Figure 66: PDF decrypted

Figure 67: PDF reply

88

16 DOMAINKEYS IDENTIFIED MAIL (DKIM)

16 DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail (DKIM) can be used to digitally sign email at thegateway level. The gateway signs the complete email (including some userdefined headers) with a private key. The associated public key is stored inDNS under a DKIM specific name. The main difference between S/MIME sign-ing and DKIM signing is that with S/MIME the signature is in most cases vali-dated by the end user whereas with DKIM the signature is validated by the mailserver. Another difference between S/MIME and DKIM is that S/MIME usesa hierarchical trust model (using X.509 certificates) and DKIM uses DNS forthe trust model. DKIM is an additional signing option to S/MIME and shouldbe used whenever possible because it can be used to prevent spoofing. Thisguide will not explain all details of DKIM. For more details and backgroundinformation about DKIM see https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail and http://www.dkim.org/.

The CipherMail gateway allows all outgoing email to be DKIM signed. DKIMkeys can be selected at global, domain or individual level. DKIM keys can bemanaged on the DKIM settings page (see figure 68).

Note

It is advised to only set DKIM keys for the sending domains. DMARCfor example requires that the d= parameter matches the domain of thesender

generate key A new DKIM signing key can be generated by clicking generatekey. A 1024 bits or 2048 bits key can be selected.

Note

If possible select a 2048 bits key. Note however that not all DNS serverssupport DNS TXT entries large enough to store a public 2048 key.

upload key With the upload key option, an existing DKIM private key can beuploaded into the gateway.

download private key This download the private key in PEM form.

Note

If HSM support is enabled, importing and downloading a DKIM privatemight not be allowed by the HSM.

89

https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

http://www.dkim.org/

16 DOMAINKEYS IDENTIFIED MAIL (DKIM)

Figure 68: DKIM

DKIM signing enabled Only if DKIM signing enabled is enabled for the senderand recipient (and a DKIM key is available) will the message be DKIM signed.If DKIM signing enabled is enabled for the sender and for some recipients butnot for all recipients, the email will be split. Email for the recipients for whichDKIM signing enabled is set will be DKIM signed.

Signature template The signature template is the template for the DKIMheader value that will be added. The default template is set to:

v=1; c=relaxed/relaxed; s=ciphermail; d=${domain}; h=From:Subject:To:Date;a=rsa-sha256; t=; bh=; b=;

The template supports the following template parameters: ${email} and ${do-main}. When the email is DKIM signed, ${email} will be replaced by thesenders email address and ${domain} will be replaced by the domain partof the senders email address.

Note

${email} can for example be used to set the identity of the user or agentusing the i= parameter

90

18 SMS GATEWAY

17 Data Leak Prevention (DLP)

Data Leak Prevention (DLP) is a feature that prevents certain information toleave the organization via email. What information this is, is defined in the con-figuration of the DLP system. Typically, it includes credit card numbers, bankaccount numbers, excessive amounts of email addresses or other personalinformation in one email message, etc. DLP is implemented as a filter on out-going email.

DLP can monitor email at various levels:

• email body content

• email headers

• email attachments of various types

• nested attachments of various types

The Ciphermail DLP engine currently only filters email bodies, attachmentsand nested attachments of type text, html, xml and other text-based formats.Filtering attachments of type pdf, doc, xls etc. will be part of a future offeringof the Ciphermail DLP engine. For more information about setting up the DLPfunctionality, see the separate “DLP setup guide”.

18 SMS gateway

The Ciphermail gateway contains an SMS gateway which can be used for send-ing generated passwords via SMS Text messages. The SMS gateway can usedifferent SMS transports for the delivery of SMS Text messages22. The defaultSMS transport is set to Clickatell (see http://www.clickatell.com for moreinformation). SMS Text messages are sent via a secure HTTPS connection toClickatell. When an SMS Text message is sent, it is queued for delivery untilthe message has been delivered with the active SMS transport (see figure 69).To test the SMS gateway an SMS Text message can be manually added with“Add SMS”.

Note

The enterprise edition supports different SMS gateways like for exampleTwilio and eCall

18.1 Clickatell transport

The default SMS transport is the “Clickatell transport”. This transport for-wards all the SMS Text messages to an external SMS gateway (using a secure

22Currently only Clickatell and Gnokii (direct connection to Nokia phones) are supported.

91

http://www.clickatell.com

19 MAIL QUEUES

Figure 69: SMS gateway

HTTPS connection). A Clickatell account must be created and configured be-fore any SMS Text messages can be sent. See see http://www.clickatell.com for more information about the sign-up process.

During the sign up process a HTTP connection must be added 23 (leavethe “Callback” parameters empty). The connection has an associated “APIID” which is required for the Clickatell transport. Open the Clickatell transportconfiguration page by opening the “SMS” page and clicking the “Clickatell set-tings” left-hand side sub-menu (see figure 70). The first three settings: “API id”,“User” and “Password” are mandatory. The “From” parameter can be set to thesender of the SMS Text message (i.e., the telephone number of the sender)but only after the telephone number has been approved by Clickatell.

Clickatell uses pre-paid message credits. To check how many credits areleft (and for testing the login credentials), click “update balance”.

Note: newly entered transport settings are only used after the changes havebeen applied. Before clicking “Update balance”, make sure all changes areapplied.

19 Mail Queues

Postfix is used as the MTA for sending and receiving of email to internal andexternal recipients. Internally a Java based SMTP server is used for messageprocessing (the “Mail Processing Agent”). The MTA and MPA store all mail intodifferent mail queues.

The mail queues of the MTA and MPA can be viewed and managed usingthe “Queues” page (see figure 71). There are five different mail queues: “MTA”,“MPA outgoing”, “MPA error”, “MPA spool” and “MPA respool”.

MTA queue With the MTA queue page messages on the MTA queue can beremoved, put on hold, viewed etc.

MPA queues The MPA contains four queues: “MPA outgoing”, “MPA error”,“MPA spool” and “MPA respool”. Normally the error and respool queue shouldbe empty. The other two queues should only contain email for a short period

23See the Clickatell “HTTP API Specification v.2.x.x” document for more information

92



19 MAIL QUEUES

Figure 70: Clickatell settings

Figure 71: Mail Queues

93

21 ADMINISTRATORS

Figure 72: Logging

while the email is processed. Processed email is sent to the MTA for furtherdelivery.

20 Logging

The “Logs” page is used to view the MTA and MPA logs. A keyword filter canbe set to view only a subset of all the log entries (see figure 72). The searchkeyword is highlighted in yellow. Every email is tagged with a unique “Mail ID”(shown in a green color). This makes it easier to track an email while the emailis being processed. Color coding of certain log elements is used to make iteasier to spot certain details (for example an email address is shown in a bluecolor, an error in red).

21 Administrators

Multiple administrators, each with a different set of roles, can be registered.The “Admin” page shows a list of all the registered administrators (see figure73). A new administrator can be added by clicking “Add admin” on the left-handside menu. This will open the “Adding new administrator” page (see figure 74).

21.1 Roles

An administrator can have any of the following roles:

• ROLE_LOGIN

• ROLE_ADMIN

• ROLE_USER_MANAGER

94

21.1 Roles 21 ADMINISTRATORS

Figure 73: Administrators

Figure 74: Add new administrator

95

21.1 Roles 21 ADMINISTRATORS

• ROLE_DOMAIN_MANAGER

• ROLE_GLOBAL_MANAGER

• ROLE_LOG_MANAGER

• ROLE_PKI_MANAGER

• ROLE_QUEUE_MANAGER

• ROLE_SMS_MANAGER

• ROLE_TEMPLATE_MANAGER

• ROLE_DLP_MANAGER

• ROLE_QUARANTINE_MANAGER

• ROLE_MOBILE_MANAGER

• ROLE_PORTAL_MANAGER

ROLE_LOGIN This is a required role. An administrator with just ROLE_LOGINis only allowed to view a few basic settings.

ROLE_ADMIN This role is similar to having all roles (i.e., an administratorwith ROLE_ADMIN is allowed to do anything).

ROLE_USER_MANAGER An administrator with this role is allowed to “addusers”, “delete users”, “edit users”, “select user certificates” and “select usersigning certificate”.

ROLE_DOMAIN_MANAGER An administrator with this role is allowed to “adddomains”, “delete domains”, “edit domains”, “select domain certificates” and“select domain signing certificate”.

ROLE_GLOBAL_MANAGER An administrator with this role is allowed to editthe global settings.

ROLE_LOG_MANAGER An administrator with this role is allowed to view thelog files.

ROLE_PKI_MANAGER An administrator with this role is allowed to “importcertificates”, “delete certificates”, “import keys”, “download keys”, “import CRLs”,“delete CRLs”, “update CRL store” and “manage the CA”.

ROLE_QUEUE_MANAGER An administrator with this role is allowed to man-age the queues (with the exception of the quarantine queue).

96

22 BACKUP AND RESTORE

ROLE_SMS_MANAGER An administrator with this role is allowed to managethe SMS gateway.

ROLE_TEMPLATE_MANAGER An administrator with this role is allowed toedit templates.

ROLE_DLP_MANAGER An administrator with this role is allowed to manageall DLP settings like adding new DLP rules, removing DLP rules, managing thequarantine queue. In order to view the quarantine queue, the administrator alsorequires the ROLE_QUEUE_MANAGER role.

ROLE_QUARANTINE_MANAGER An administrator with this role is allowedto manage the quarantine queue. In order to view the quarantine queue, theadministrator also requires the ROLE_QUEUE_MANAGER role.

22 Backup and restore

22.1 System backup

The backup manager can be used to backup and restore all the relevant sys-tem settings (including the certificates, keys and MTA settings). A backup canbe created and downloaded to the administrators computer or a backup canbe stored on a remote SAMBA share (see figure 75). A backup can be auto-matically initiated at set intervals and stored (encrypted or non encrypted) on aremote SAMBA share. A backup can be password encrypted. If no passwordis specified the backup will not be encrypted.

Warning

Restoring a backup will overwrite all local settings and cannot be un-done. The system need to be restarted after the restore.

22.2 Backup configuration

The backup configuration page is used to configure the remote SAMBA shareand configure the automatic backup (see figure 76).

22.2.1 SMB share settings

The SMB share settings specify which remote SAMBA share should be usedfor remote backups (automatic backups can only be stored on a remote share).The remote share can be any server that supports the SMB protocol (for ex-ample Microsoft Windows Network or SAMBA). “Test connection” can be usedto test whether the specified share can be accessed with the provided settingsand credentials.

97

23 LOG EXPORT

Figure 75: System Backup

22.2.2 Automatic backup

Enabled Remote backups can be automatically initiated at set intervals. Toenable automatic backups the “enabled” checkbox should be checked.

Cron expression The cron expression24 determines at which intervals a backupwill be started. The default cron expression 0 0 2 * * ? automatically starts abackup every night at 2 o’clock (see Appendix D for more cron expression ex-amples).

Password The password with which the backup will be encrypted.

22.2.3 Other

Strategy The filename of the backup is determined by the “strategy”. Choosebetween “day of week”, “day of month”, “day of year” and “timestamp”. “Day ofweek” uses the day of the week as a filename postfix (1-7). “Day of month” usesthe day number as a filename postfix (1-31). “Day of year” uses the day (1-365)as a filename postfix. “Timestamp” uses a filename based on the number ofmilliseconds since January 1, 1970 UTC.

23 Log export

only available with the enterprise edition24For more info on the cron trigger format see http://www.quartz-scheduler.org/docs/

tutorials/crontrigger.html

98

http://www.quartz-scheduler.org/docs/tutorials/crontrigger.html


23 LOG EXPORT

Figure 76: Backup configuration

99

23.1 Log export config 23 LOG EXPORT

Figure 77: Log export

With the log export, all system log files can be exported to a remote SAMBAshare or downloaded to the local computer (see figure 77).

Password If a password is set, the exported logs will be PGP password en-crypted.

Last modified If set, only log files which were modified within the last numberof minutes will be exported. If not set, all logs files will be exported.

Export location The logs can be exported to the local computer (i.e., down-loaded with the browser) or to a remote SAMBA share.

23.1 Log export config

The log export configuration page is used to configure the remote SAMBAshare and configure automatic log export (see figure 78).

23.1.1 SMB share settings

The SMB share settings specify which remote SAMBA share should be usedfor remote log export (automatic log exports can only be stored on a remoteshare). The remote share can be any server that supports the SMB protocol(for example Microsoft Windows Network or SAMBA). “Test connection” can beused to test whether the specified share can be accessed with the providedsettings and credentials.

23.1.2 Automatic log export

Enabled Remote exports can be automatically initiated at set intervals. Toenable automatic exports the “enabled” checkbox should be checked.

100

23.1 Log export config 23 LOG EXPORT

Figure 78: Log export settings

101

25 SSL/TLS

Cron expression The cron expression25 determines at which intervals a logexport will be started. The default cron expression 0 0 3 * * ? automaticallystarts an export every night at 3 o’clock (see Appendix D for more cron expres-sion examples).

Password The password with which the exported logs will be encrypted.

23.1.3 Other

Strategy The filename of the export is determined by the “strategy”. Choosebetween “day of week”, “day of month”, “day of year” and “timestamp”. “Day ofweek” uses the day of the week as a filename postfix (1-7). “Day of month” usesthe day number as a filename postfix (1-31). “Day of year” uses the day (1-365)as a filename postfix. “Timestamp” uses a filename based on the number ofmilliseconds since January 1, 1970 UTC.

24 Reporting


The gateway keeps statistics on all incoming and outgoing email like for exam-ple whether a message was encrypted. These statistics can be exported to aPDF report from the reporting page (Admin→ reporting). The grouping (year,month, week, day), start date and end date can be specified (see figure 79).

Note: statistics are only persisted to the database if the number of cachedentries exceeds a fixed limit. This is done to minimize the number of databasewrites required when handling an email. It will therefore take a number ofemails before the reporting functionality returns updated statistics.

24.1 Report

A PDF report shows the statistics grouped by date (see figure 80). The statisticfor email sent to internal recipients (recipients with locality set to “Internal”)starts with “incoming” and the statistic for email sent to external recipients startswith “outgoing”.

25 SSL/TLS

25.1 Web GUI

Access to the Web GUI and portal is protected with SSL/TLS. During installa-tion, a default SSL certificate has been installed26. It is therefore advised to

25For more info on the cron trigger format see http://www.quartz-scheduler.org/docs/tutorials/crontrigger.html

26With the virtual appliance, a new SSL/TLS certificate is generated when the appliance isstarted for the first time

102



25.1 Web GUI 25 SSL/TLS

Figure 79: Reporting

Figure 80: Report

103

25.2 SMTP 25 SSL/TLS

Figure 81: SSL/TLS configuration for the web GUI

install a new SSL certificate after installation. On the “SSL/TLS configurationfor the web GUI” page, a new SSL certificate can be imported (see figure 81).A password protected “PKCS#12” file (.pfx or .p12) with the SSL certificate andprivate key suitable for SSL should be uploaded. After installation of the SSLcertificate, the system must be restarted. The system can be restarted by click-ing “Restart” on the “SSL certificate manager” page or by opening the “Admin”menu and selecting “Restart” on the left hand side menu27.

Note: if the PDF portal functionality (like for example the PDF reply) is usedyou are advised to install an SSL certificate which is trusted by all browsers (forexample Comodo, Verisign or StartSSL certificates).

25.2 SMTP


The SMTP server supports TLS for incoming and outgoing SMTP. During in-stallation a new SSL/TLS certificate is generated when the appliance is startedfor the first time. On the “TLS configuration for the SMTP server” page, anew SSL certificate can be imported (see figure 82). A password protected“PKCS#12” file (.pfx or .p12) with the SSL certificate and private key suitablefor SSL should be uploaded. The SMTP server will be automatically restartedafter the installation of the new SSL certificate.

25.3 CSRs


For the portal functionality, it’s advised to use a certificate which is trusted byall browsers. This requires that the certificate is issued by a trusted CA (for

27Alternatively with the Virtual Appliance, the system can be restarted by selecting “Restartservices” from the Virtual Appliance Console.

104

25.3 CSRs 25 SSL/TLS

Figure 82: TLS configuration for the SMTP server

example Comodo, Verisign or StartSSL). The certificate with private key can beimported using a password protected “PKCS#12” file. This however requiresthat a “PKCS#12” file is already available. The “Certificate Signing Requests”page can be used to request a certificate from an external trusted CA (seefigure 83).

25.3.1 CSR manager

Most CAs require a Certificate Signing Request (CSR) before they can issuea certificate. When a CSR is generated, a private/public key pair is generatedtogether with some identifying information (for example the name of the com-pany). After generating the CSR, the CSR should be sent to the CA. The CAwill then create a new certificate using the data from the CSR. This certificateshould then be imported into the CSR store. The certificate will then be com-bined with the associated private key and the certificate and private key canbe exported to a password protected PKCS#12 file. The CSR store stores thegenerated CSRs together with the associated private keys. CSRs for which thecertificate is not yet imported are shown in yellow (see figure 83). CSRs forwhich the certificate was imported, can be exported to a password protectedPKCS#12 file by selecting the CSRs and clicking “download certificates”.

25.3.2 Certificate request procedure

The following steps will outline the procedure with which a trusted SSL certifi-cate can can be requested for the Web GUI:

1. Create a CSR

2. Download CSR

3. Send CSR to CA

4. Import certificate generated by CA

5. Download certificate as password protected “PKCS#12” file

105

25.3 CSRs 25 SSL/TLS

Figure 83: Certificate Signing Requests

6. Import “PKCS#12” file into Web GUI

1. Create A CSR Click “Create new CSR” on the “Certificate Signing Re-quest” page (see figure 83). On the “Create certificate signing request” page(see figure 84), fill in the request details required by the CA and select thelength of the private key. A public/private key pair will be generated and theCSR will be created when the “Create” key is pressed. The CSR together withthe public/private key pair will be stored in the CSR store.

2. Download CSR Select the CSR, and click “Download CSRs”. Save thedownloaded CSR.

3. Send CSR to CA Send the downloaded CSR to the CA. It depends on theCA how the CSR should be delivered to the CA.

4. Import certificate generated by CA The CA will generated a certificateusing the details from the CSR 28. After the CA has issued the certificate, importthe certificate into the CSR store. After import the certificate, the certificate andprivate key belonging to the certificate will be combined.

5. Download certificate as password protected “PKCS#12” file Select theCSR for which the certificate and private should be exported to a “PKCS#12”file and click “download certificate”. On the “Export CSR certificates and keys”page, a password for the “PKCS#12” file should be provided.

28Generating a certificate may take a few seconds or a couple of days. This depends on thepolicies of the CA.

106

26 REMOTE MONITORING

Figure 84: Create certificate signing request

6. Import “PKCS#12” file into Web GUI The exported password protected“PKCS#12” file can now be imported into the Web GUI. See section 25 fordetails on how to import the “PKCS#12” file.

26 Remote monitoring


The gateway can be remotely monitored using the monitoring web service. Themonitoring web service is accessible on https://HOST/unprotected/monitor/*?password=PASSWORD where * should be replaced with the name of the ser-vice to monitor. For example the following URL returns the number of mails inthe MTA queue:

https://HOST/unprotected/monitor/mta-queue-size?password=PASSWORD

Note: HOST and PASSWORD should be replaced with the real hostnameand configured password for the monitoring service.

For more details on the supported commands and their return values, see theseparate monitoring guide.

26.1 Monitoring configuration

The monitoring configuration (Admin → other → monitoring) can be config-ured on the “Monitoring configuration” page (see figure 85). The monitor-ing service should be enabled, the IP address from which the connection ismade should be allowed and the password for the monitoring service should

107

https://HOST/unprotected/monitor/*?password=PASSWORD

https://HOST/unprotected/monitor/*?password=PASSWORD

27 CERTIFICATE REQUEST BY MAIL

Figure 85: Monitoring configuration

be set. If the monitoring service is not enabled or if the IP address is not au-thorized or the password is not set or not correct, an “access denied” page isshown. The authorized IP addresses (IP filter) can be set to multiple commaseparated IP addresses or to some IP range in CIDR format. For example:192.168.88.0/24, 10.0.0.16

27 Certificate request by mail


A problem with S/MIME is that on order to encrypt email, the certificate ofthe recipient must be available. One option to get someone’s certificate is byasking the recipient to send a digitally signed email. The gateway will extractthe certificate from the digitally signed message and import it into the gateway.With the “Certificate request by mail” option, the gateway can be configuredto automatically reply with a digitally signed email to an incoming email. Thiscan be used by external senders to “automatically” retrieve a certificate fromthe gateway which can then be used for sending S/MIME encrypted email.Because the reply is digitally signed, the email client (for example Outlook) canextract the certificate from the digitally signed email.

The automatic reply service will only be active if it is enabled and if thesender used a subject for the mail which matches a pre-defined regular ex-pression and if the message was digitally signed with a trusted certificate (thiscan be disabled). The “Certificate request by mail” service can be configuredon the Certificate request by mail page (see figure 86). The configuration can

108

27.1 Certificate request by mail reply templates 28 PROXY

Figure 86: Certificate request by mail

be changed for the global settings, domain or for an individual recipient.

Enabled The “Certificate request by mail” service is only enabled if “Enbaled”is checked.

Subject trigger The “Subject trigger” is a regular expression which will bematched against the subject of an incoming email. If matched, the messagewill be handled by the “Certificate request by mail” service.

Must be signed If checked (the default), the message will only be acceptedif the incoming message was signed with a trusted digital S/MIME signature.

27.1 Certificate request by mail reply templates

The digitally signed reply messages are based on the “Cert request signed”and “Cert request not signed” templates. The templates can be modified bythe administrator (see section 7). The reply template “Cert request signed” isused if the email is accepted and there is a valid signing certificate. The replytemplate “Cert request not signed” is used if the email is accepted but there isnot a valid signing certificate.

Note: if the email contains the subject trigger and is signed, or not signed if“Must be signed” is not enabled, the email will “not” be delivered to the recipient.The email will be handled by the gateway and the reply (based on the template“Cert request signed” or “Cert request not signed”) will be sent. It’s thereforeimportant that the subject pattern used is not something that is triggered bynormal emails.

28 Proxy

For downloading of CRLs and sending of SMS Text messages, the gatewayneeds access to external resources. If external resources should be accessedvia a proxy, the proxy client should be configured. The proxy client only sup-ports HTTP(s) and “NTLMv1” (“NTLMv2” is not supported). The proxy clientcan be configured by opening the “Admin” page and selecting “Proxy config”(see figure 87).

109

29 FETCHMAIL

Figure 87: Proxy configuration

29 Fetchmail

Fetchmail can be used to retrieve email from remote “POP3”, “IMAP” servers.The retrieved email can then be forwarded to some other email addresses bythe Ciphermail gateway. The servers from which email should be fetched andthe email addresses to which email should be forwarded to can be configuredwith the fetchmail configuration page.

Note

Fetchmail support is only available on the Virtual Appliance.

29.1 Fetchmail manager

When Fetchmail support is enabled a “Fetchmail manager” option is added tothe admins menu (see figure 88). With the “Fetchmail manager” page newservers can be added which will be periodically polled for new messages (seefigure 89).

Figure 88: Admins fetchmail options

110

29.1 Fetchmail manager 29 FETCHMAIL

Figure 89: Fetchmail manager

29.1.1 Global settings

Fetchmail manager contains three global settings relevant for all polled servers:“Postmaster”, “Poll interval” and “Check certificate”.

Postmaster If email cannot be forwarded an error message will be sent tothe postmaster email address.

Poll interval The number of seconds between consecutive checks for newemail. For “IMAP” accounts with “IDLE” support a new message is instantlydetected and forwarded (also known as push mail). The “Poll interval” shouldnot be too low to prevent flooding of the remote server.

Check certificate If checked, Fetchmail checks whether the server certificateis trusted and is issued by a locally trusted CA.

29.1.2 Applying changes

When the “Apply” button is pressed the Fetchmail configuration will be updatedand Fetchmail will be restarted.

29.1.3 Adding a new account

New accounts to be polled and forwarded can be added by clicking “add ac-count” (see figure 89). The page “Fetchmail Add Account to Poll” will be opened(see figure 90). The account settings will be briefly explained.

111

30 SYSTEM RUNTIME CONTROL

Server The server that is being polled. This can be a fully qualified domainname or an IP address.

Port The port the server being polled listens on. If left empty the default portfor the protocol will be used.

Protocol The protocol of the server being polled (“POP3”, “IMAP” etc.).

Authentication The authentication protocol the server being polled uses.With “Any”, Fetchmail tries each available method consecutively until a suc-cessful login.

Principal The Kerberos principal (only relevant for IMAP and kerberos).

Username The username of the remote account.

Password The password of to the user account.

Folder The remote folder to query.

UIDL Force client-side tracking of new messages. Should be used in con-junction with “keep”. This setting is only relevant for “POP3”.

SSL Connect to the remote server via SSL.

Keep If “Keep” is selected, seen messages are not deleted from the remoteserver (if “Keep” is used with “POP3”, “UIDL” should also be selected). If pos-sible, seen message should be deleted to make sure a message is never de-livered twice. It is therefore advised to leave “Keep” unchecked.

Idle If selected, Fetchmail waits for new messages after each poll (IMAPonly). With “Idle” new messages are instantly forwarded.

Forward To The email address to forward newly polled messages to.

30 System runtime control

The “System runtime control” page can be used to manage the runtime ofthe gateway (rebooting, and start/stopping the MTA etc. see figure 91). The“System runtime control” page can be opened by clicking Admin→ system.

112


Figure 90: Fetchmail new account

113


Figure 91: System runtime control

114

32 EXTRACT TEXT FROM A MIME MESSAGE

Figure 92: Compose test email

31 Compose test email

The “Compose test email” page can be used to create a test email to testthe gateway settings (see figure 92). The “Compose test email” page can beopened by clicking Admin→ other→ send email.

32 Extract text from a MIME message

With the “Extract text from a MIME message” page, the text from an uploadedemail will be extracted and returned (see figure 93). This allows the adminis-trator to see which text the DLP scanner uses for pattern matching. This helpsthe administrator to create DLP rules. The “Extract text from a MIME message”page can be opened by clicking Admin→ other→ extract text.

115

A SMTP HELO/EHLO NAME

Figure 93: Extract text

A SMTP HELO/EHLO name

The SMTP helo/ehlo name is the hostname the SMTP server sends with theSMTP EHLO or HELO command (the Ciphermail gateway uses the HELO orEHLO command when sending email to another email server). Some emailservers check whether the helo/ehlo name is equal to the reverse IP lookup(with a reverse IP lookup the name is retrieved that belongs to the IP address)and if the names do not match they will flag the email as spam.

If the Ciphermail gateway is used to directly send email to external recip-ients (i.e., outgoing email is not relayed through an external relay host) thegateway should be setup with the correct helo/ehlo. The SMTP helo nameshould be equal to the reverse lookup of the external IP address.

If the external IP address is not known and the Ciphermail gateway usesthe same IP address as the web browser, the external IP address and host-name (reverse IP) can be retrieved using on-line services like http://www.whatismyipaddress.com. The IP address shown is the external IP address.The shown hostname (the reverse IP lookup) should be used for the SMTPhelo name. If the hostname of the Ciphermail gateway is set to the externalhostname, the SMTP helo name can be left empty because the SMTP heloname will then be equal to the gateway hostname.

Checking the HELO/EHLO name whether the HELO/EHLO name is cor-rectly setup can be checked using the helo check services from http://cbl.abuseat.org/helocheck.html by sending an email to “[email protected]”.The email will be immediately bounced. The bounce message contains theHELO name used by the gateway.

<[email protected]>: host mail-in.cbl.abuseat.org said:550 HELO for IP 82.94.189.170 was "secure.djigzo.com"(in reply to RCPT TO command)

Where 82.94.189.170 is the external IP address of the gateway (IP addresswill be different for every server) and “secure.djigzo.com” was the HELO nameused by the gateway.

116

http://www.whatismyipaddress.com

http://www.whatismyipaddress.com

http://cbl.abuseat.org/helocheck.html

http://cbl.abuseat.org/helocheck.html

B SASL AUTHENTICATION

Figure 94: SASL add password

B SASL authentication

SMTP client authentication is not enabled by default. SMTP client authenti-cation can be enabled by adding the following lines to the postfix main configusing the “MTA raw config” page (see 4.4):29

smtp_sasl_auth_enable = yessmtp_sasl_password_maps = hash:/etc/postfix/smtp_client_passwdsmtp_sasl_type = cyrus

New SASL credentials for an SMTP host can be added by clicking “addpassword”. This opens the “Add SASL password” page (see figure 94). If “mx”is selected the MX-records of the server are used instead of the IP address ofthe server (A-record). In most cases the IP address of the server should beused and “mx” should therefore not be selected.

Gmail example: as an example the following part will explain how to usethe Gmail SMTP servers as an external relay host (i.e., email sent to externalrecipients will be relayed via Gmail). For SMTP authentication Gmail requiresa TLS protected connection. TLS and sasl authentication should therefore beenabled by adding the following lines to the postfix main config file using the“MTA raw config” page (see 4.4):

smtp_tls_security_level = maysmtp_sasl_auth_enable = yessmtp_sasl_password_maps = hash:/etc/postfix/smtp_client_passwdsmtp_sasl_type = cyrussmtp_tls_CApath = /etc/postfix/certs/smtp_sasl_security_options =

29The main config that comes with Ciphermail gateway already contain these lines. They arehowever commented out.

117

C CONTENT AND VIRUS SCANNING

Figure 95: Gmail external relay host

Figure 96: Gmail SASL password

The “External relay host” should be set to “smtp.gmail.com” and the port to“587” (see figure 95).

The SASL password for server “smtp.gmail.com” and port “587” should beset. The username should be set to the Gmail username (the username shouldinclude @gmail.com) and password (see figure 96).

C Content and virus scanning

A content scanner can be used in combination with Ciphermail gateway toselectively force encryption when a message contains certain keywords (forexample a “Social Security Number”). A typical setup of a content scanner andan encryption gateway can be see in figure 97.

Ciphermail gateway with content scanner:

Figure 97: Content scanning

118


Figure 98: Virus scanning

Figure 99: Virus scanning with desktop encryption

1. User sends unencrypted message.

2. Exchange forwards message to content scanner.

3. Content scanner detects that the message must be encrypted (for exam-ple the message contains a SSN).

4. Ciphermail gateway encrypts the message with S/MIME or PDF.

5. Content scanner sends the encrypted message to the recipient.

Most organizations need to scan all incoming and outgoing email for viruses.A typical setup of an encryption gateway and a virus scanner can be see in fig-ure 98.

Ciphermail gateway with virus scanning:

1. S/MIME encrypted message is received from the Internet.

2. Ciphermail gateway decrypts the message.

3. The decrypted message is scanned for viruses.

4. After virus scanning the message is forwarded to Exchange.

5. User reads the message.

A more advanced setup is required when email must be encrypted on thedesktop yet all outgoing email must be virus scanned because of corporatepolicies. Figure 98 shows how encrypted outgoing email can be virus scanned.

119


Ciphermail gateway with desktop encryption and virus scanning:

1. User encrypts message with personal and receivers certificate.

2. S/MIME encrypted message is sent to Exchange.

3. Exchange sends S/MIME encrypted message to the Ciphermail gateway.

4. Ciphermail gateway decrypts the message with the senders private key(the gateway stores a copy of the key) and sends the decrypted messageto the virus scanner.

5. Virus scanner scans the message and if clean it will be sent back to theCiphermail gateway.

6. The Ciphermail gateway re-encrypts the message and sends the mes-sage to the external recipient.

120

D CRON EXPRESSIONS

D Cron Expressions

The following cron examples are taken from http://www.quartz-scheduler.org/docs/tutorials/crontrigger.html.

Expression Meaning

0 0 12 * * ? Fire at 12pm (noon) every day0 15 10 ? * * Fire at 10:15am every day0 10,44 14 ? 3 WED Fire at 2:10pm and at 2:44pm every Wednesday in March.0 15 10 15 * ? Fire at 10:15am on the 15th day of every month0 15 10 L * ? Fire at 10:15am on the last day of every month

For more cron examples see the “Quartz Scheduler” website.

121



E MPA MAIL FLOW

E MPA mail flow

The following flow-charts will show exactly how email is processed by the Ci-phermail gateway.

Note

The MPA mail flow can be used to find out why the gateway handled anemail in a certain way.

122

E MPA MAIL FLOW

Figure 100: Start

123

E MPA MAIL FLOW

Figure 101: DLP

124

E MPA MAIL FLOW

Figure 102: DLP Warn

Figure 103: DLP Must Encrypt

125

E MPA MAIL FLOW

Figure 104: DLP Quarantine

126

E MPA MAIL FLOW

Figure 105: DLP Block

127

E MPA MAIL FLOW

Figure 106: DLP Error

128

E MPA MAIL FLOW

Figure 107: External recipient

129

E MPA MAIL FLOW

Figure 108: Must encrypt

130

E MPA MAIL FLOW

Figure 109: S/MIME

131

E MPA MAIL FLOW

Figure 110: S/MIME encrypt132

E MPA MAIL FLOW

Figure 111: PGP133

E MPA MAIL FLOW

Figure 112: PDF encryption

134

E MPA MAIL FLOW

Figure 113: Generate PDF password

135

E MPA MAIL FLOW

Figure 114: Check PDF OTP136

E MPA MAIL FLOW

Figure 115: Check PDF SMS

137

E MPA MAIL FLOW

Figure 116: PDF sign email

Figure 117: Check encrypt

138

E MPA MAIL FLOW

Figure 118: Check Sign139

E MPA MAIL FLOW

Figure 119: Encryption notification

Figure 120: S/MIME sign

140

E MPA MAIL FLOW

Figure 121: BlackBerry S/MIME adapter

141

G BULK IMPORT

F Comodo certificate request handler

The Comodo certificate request handler requests certificates30 from Comodo’sEnterprise Public Key Infrastructure (EPKI). Comodo’s EPKI is an outsourcedCertificate Authority managed by Comodo. The main advantage of using cer-tificates issued by Comodo is that these certificates are by default trusted bymost systems (like Windows, Mac OS, Ubuntu).

The Comodo EPKI certificate request procedure is a three step procedure:

1. Apply for certificate.

2. Authorize request.

3. Collect certificate.

After every step, the EPKI manager sends an email to the registered EPKImanager. Because requesting a certificate using the Comodo certificate re-quest handler takes several steps, a certificate is not immediately issued.

The Comodo certificate request handler requires a valid EPKI account. AComodo EPKI account can be provided by Ciphermail or alternatively directlyfrom Comodo. The following Comdoo EPKI account settings can be specified:“Login name”, “Login password”, “AP”, “CA Certificate ID” and “Auto authorize”(see figure 122).

The only required settings are: “Login name”, “Login password” and “AP”.Step two, “Authorize request”, will be done automatically by the Ciphermailgateway when “Auto authorize” is enabled. If “Auto authorize” is not enabled,the authorization step should be done online using the EPKI portal. “CA Certifi-cate ID” should only be specified when the issued certificate should be signedby a non-default CA certificate.

F.1 Tier details

By clicking “view Tier details”, Comodo EPKI status information can be re-trieved (see figure 123).

G Bulk import

The file format of the file containing all the certificate requests used for the “bulkrequest” option is as follows:

• The file should be a comma separated file (CSV).

• Values containing commas should be double quoted.

• The first row should contain the column order.30The private key will be generated on the gateway and not leave the gateway. The public key

and some identifying information (like email address) will be sent to Comodo. Comodo will thengenerate, sign and return the certificate.

142

G BULK IMPORT

Figure 122: Comodo EPKI settings

Figure 123: Comodo Tier details

143

G.1 Examples CSV G BULK IMPORT

• The CSV is considered to be US-ASCII encoded unless a Byte OrderingMark (BOM) is used.

• The following columns are supported: “EMAIL”, “ORGANISATION”, “COM-MONNAME”, “FIRSTNAME”, “LASTNAME”

• “EMAIL” and “COMMONNAME” are mandatory.

• By default, the maximum number of requests in a single CSV file is10000.

• The maximum length of an individual entry is 256 characters.

Multiple aliases for the columns are available. Column names are case insen-sitive:

Column AliasesEMAIL email, eORGANISATION organisation, org, oCOMMONNAME commonname, cnFIRSTNAME firstname, fn, givenname, gnLASTNAME lastname, ln, surname, sn

G.1 Examples CSV

The following example shows how to import two requests. It uses a combina-tion of column name aliases:

"e","org","COMMONNAME","fn","surname""[email protected]","organisation 0","user 0","first name 0","last name 0""[email protected]","organisation 1","user 1","first name 1","last name 1"

A similar example but this time the values are not quoted and only the requiredvalues email and organisation are specified:

e,[email protected], [email protected], cn2

144

ciphermail email encryption gateway administration guide · openpgp and pdf encryption. s/mime and...

Documents