7 Security and Access Control in Messaging Server

Oracle Communications Messaging Server supports security features that enable you to keep messages from being intercepted, prevent intruders from impersonating your users or administrators, and permit only specific users access to specific parts of your messaging system.

The Messaging Server security architecture is part of the security architecture of Oracle servers as a whole. It is built on industry standards and public protocols for maximum interoperability and consistency.

About Server Security

Server security encompasses a broad set of topics. In most enterprises, ensuring that only authorized people have access to the servers, that passwords or identities are not compromised, that people do not misrepresent themselves as others when communicating, and that communications can be held confidential when necessary are all important requirements for a messaging system.

Perhaps because the security of server communication can be compromised in many ways, there are many approaches to enhancing it. This information focuses on setting up encryption, authentication, and access control. It discusses the following security-related Messaging Server topics:

• User ID and password login: Requiring users to enter their user IDs and passwords to log in to IMAP, POP, HTTP, or SMTP, and the use of SMTP password login to transmit sender authentication to message recipients.

• Encryption and authentication: Using the TLS and SSL protocols to encrypt communication and authenticate clients.

• Administrator access control: Using the access-control facilities to delegate access to a Messaging Server and some of its individual tasks.

• TCP client access control: Using filtering techniques to control which clients can connect to your server's POP, IMAP, HTTP, and authenticated SMTP services.

Not all security and access issues related to Messaging Server are treated in this chapter. Security topics that are discussed elsewhere include the following:

• Physical security: Without provisions for keeping server machines physically secure, software security can be meaningless.

• Message-store access: You can define a set of message-store administrators for the Messaging Server. These administrators can view and monitor mailboxes and can control access to them. For details, see the discussion on Message Store management in the Messaging Server System Administrator's Guide.

• End-user account configuration: End-user account information can be primarily maintained by using the Delegated Administrator product.

• Filtering unsolicited bulk email (UBE): See the discussion on mail filtering and access control in the Messaging Server System Administrator's Guide.

• Secure Multipurpose Internet Mail Extensions (S/MIME) is described in the discussion on administering SMIME in Convergence in the Convergence System Administrator's Guide.

About HTTP Security

Messaging Server includes an http-based service that provides a custom protocol called WMAP. This service is only used by the Convergence web client, runs on ports 8990/8991 and should be disabled if Convergence is not used. For more information about http access to email and security thereof, see the documentation for Convergence.

Configuring Authentication Mechanisms in Messaging Server

An authentication mechanism is a particular method for a client to prove its identity to a server. Messaging Server supports authentication methods defined by the Simple Authentication and Security Layer (SASL) protocol and it supports certificate-based authentication. The SASL mechanisms are described in this information. For more information about certificate-based authentication, see "Configuring Encryption and Certificate-Based Authentication."

Topics:

• Overview

• To Configure Access to Plaintext Passwords

• Transitioning Users

Overview

Messaging Server supports the following SASL authentication methods for password-based authentication.

• PLAIN. This mechanism passes the user's plaintext password over the network, where it is susceptible to eavesdropping. Secure Sockets Layer (SSL) can be used to alleviate the eavesdropping problem. For more information, see "Configuring Encryption and Certificate-Based Authentication."

• APOP. A challenge/response authentication mechanism that can be used only with the POP3 protocol. Defined in RFC 1939. Should be used only by sites that have legacy usage of this mechanism.

• CRAM-MD5. A challenge/response authentication mechanism similar to APOP, but suitable for use with other protocols as well. Defined in RFC 2195. Should be used only by sites that have legacy usage of this mechanism.

• LOGIN. This is equivalent to PLAIN and exists only for compatibility with pre-standard implementations of SMTP authentication. This mechanism is only enabled for use by SMTP.

With a challenge/response authentication mechanism, the server sends a challenge string to the client. The client responds with a hash of that challenge and the user's password. If the client's response matches the server's own hash, the user is authenticated.

Note:

The POP, IMAP, and SMTP services support all SASL mechanisms. The HTTP service supports only the plaintext password mechanism.

Table 7-1 shows some SASL and SASL-related configuration options. For the complete listing of options, see Messaging Server Reference.

Table 7-1 Some SASL and SASL-related Options

Option	Description
auth.has_plain_passwords	Boolean to indicate that directory stores plaintext passwords which enables APOP and CRAM-MD5. Default: 0 (False)
auth.auto_transition	Boolean. When set and a user provides a plain text password, the password storage format is transitioned to the default password storage method for the directory server. This can be used to migrate from plaintext passwords to APOP and CRAM-MD5. Default: 0 (False)
imap.allowanonymouslogin	This enables the SASL ANONYMOUS mechanism for use by IMAP. Default: 0 (False)
imap|pop|smtp|http.plaintextmincipher	If this is greater than 0, then disable use of plaintext passwords unless a security layer (SSL or TLS) is activated. This forces users to enable SSL or TLS on their client to log in, which prevents exposure of their passwords on the network. The MMP has an equivalent option restrictplainpasswords. Default: 0
auth.searchfilter	This is the default search filter used to look up users when one is not specified in the inetDomainSearchFilter for the domain. The syntax is the same as inetDomainSearchFilter. (See the Schema Reference). Default: (&(uid=%U)(objectclass=inetmailuser))

To Configure Access to Plaintext Passwords

To work, the CRAM-MD5 or APOP authentication methods require access to the users' plaintext passwords. You need to perform the following steps:

1. Configure Directory Server to store passwords in cleartext.

2. Configure Messaging Server so that it knows Directory Server is using cleartext passwords.

To Configure Directory Server to Store Cleartext Passwords

To enable the CRAM-MD5 or APOP mechanisms, you must configure the Directory Server to store passwords in cleartext. If you are using a Directory Server prior to version 6, the following instructions apply. (For version 6 or later, refer to the latest Directory Server documentation.)

1. In the Directory Server Console, open the Directory Server you want to configure.

2. Click the Configuration tab.

3. Open Data in the left pane.

4. Click Passwords in the right pane.

5. From the Password encryption drop-down list, choose cleartext.

   Note:

   This change only impacts users created in the future. You need to transition or reset existing users' passwords after this change.

To Configure Messaging Server for Cleartext Passwords

You can configure Messaging Server so that it knows the Directory Server is able to retrieve cleartext passwords. This makes it safe for Messaging Server to advertise APOP and CRAM-MD5:

1. Enable the auth.has_plain_passwords option.

   msconfig set auth.has_plain_passwords 1
   

2. To disable these challenge/response SASL mechanisms, disable the auth.has_plain_passwords option (set the value to 0).

Note:

Existing users cannot use APOP and CRAM-MD5 until their password is reset or migrated (see "Transitioning Users").

Transitioning Users

You can specify information about transitioning users. An example would be if a user password changes or if a client attempts to authenticate with a mechanism for which they do not have a proper entry.

• Set the auth.auto_transition option.

  msconfig set auth.auto_transition value
  

  For the value, you can specify one of the following:

  • 0 - Do not transition passwords. This is the default.

  • 1 - Do transition passwords.

To successfully transition users, you must set up ACIs in the Directory Server that enable Messaging Server write access to the user password attribute. To do this, perform the steps in the following task.

To Transition Users

If you are using a Directory Server prior to version 6, the following instructions apply. (For version 6 or later, refer to the latest Directory Server documentation.)

1. In Console, open the Directory Server you want to configure.

2. Click the Directory tab.

3. Select the base suffix for the user/group tree.

4. From the Object menu, select Access Permissions.

5. Select the ACI for Messaging Server End User Administrator Write Access Rights.

6. Click ACI Attributes.

7. Add the userpassword attribute to the list of existing attributes.

8. Click OK.

Configuring Client Access to POP, IMAP, and HTTP Services

Messaging Server provides two ways to control client access, one for non-dispatcher services and one for dispatcher services. This information describes the TCP client access control mechanism used by non-dispatcher services, like the IMAP and POP servers. The proxy servers, MMP and mshttpd, also use this mechanism (by using options such as popproxy.domainallowed, imapproxy.domainallowed, and so on). The internal ENS server uses the mechanism as well, but does not perform authentication and thus does not use LDAP attributes. See the discussion of how to filter mail based on its source or header strings in Messaging Server System Administrator's Guide.

Note:

The MMP behaves differently with respect to access control than the other services. For example, the MMP IMAP service controls both IMAP and IMAP+SSL services (that is, controls both ports 143 and 993). The other Messaging Server services treat IMAP and IMAP+SSL as separate services, that is, IMAP+SSL on port 993 has its own access control that is separate from IMAP on port 143.

If you are managing messaging services for a large enterprise or an Internet service provider, be sure to also implement protection from spammers and DNS spoofers to improve the general security of your network. See "Protecting Against Email Spammers" for more information.

If controlling access by IP address is not an important issue for your enterprise, you do not have to create any filters. If minimal access control is all you need, see "Mostly Allowing" for instructions.

Topics:

• How Client Access Filters Work

• Filter Syntax

• Filter Examples

• To Create Access Filters for Services

• To Create Filters by Using the Command Line

How Client Access Filters Work

The Messaging Server access-control facility for TCP clients is an implementation of the TCP wrapper concept. A TCP wrapper is a program that listens at the same port as the TCP daemon it serves. It uses access filters to verify client identity, and it gives the client access to the daemon if the client passes the filtering process. The design of the Messaging Server TCP wrapper is based on the Unix Tcpd access-control facility (created by Wietse Venema).

As part of its processing, the Messaging Server TCP client access-control system performs (when necessary) the following analyses of the socket end-point addresses:

• Reverse DNS lookups of both end points (to perform name-based access control)

• Forward DNS lookups of both end points (to detect DNS spoofing)

The system compares this information against access-control statements called filters to decide whether to grant or deny access. For each service, separate sets of Allow filters and Deny filters control access. Allow filters explicitly grant access. Deny filters explicitly forbid access.

When a client requests access to a service, the access-control system compares the client's address or name information to each of that service's filters, in order, by using these criteria:

• The search stops at the first match. Because Allow filters are processed before Deny filters, Allow filters take precedence.

• Access is granted if the client information matches an Allow filter for that service.

• Access is denied if the client information matches a Deny filter for that service.

• If no match with any Allow or Deny filter occurs, access is granted, except in the case where there are Allow filters but no Deny filters, in which case lack of a match means that access is denied.

The filter syntax described here is flexible enough that you should be able to implement many different kinds of access-control policies in a simple and straightforward manner. You can use both Allow filters and Deny filters in any combination, even though you can probably implement most policies by using almost exclusively Allows or almost exclusively Denies.

The following sections describe filter syntax in detail and give usage examples. "To Create Access Filters for Services" gives the procedure for creating access filters.

Filter Syntax

Filter statements contain both service information and client information. The service information can include the name of the service, names of hosts, and addresses of hosts. The client information can include host names and host addresses. Both the server and client information can include wildcard names or patterns.

The very simplest form of a filter is:

service:hostSpec

where service is the name of the service (such as SMTP, POP, IMAP, or HTTP) and hostSpec is the host name, IPv4 address, or wildcard name or pattern that represents the client requesting access. When a filter is processed, if the client seeking access matches client, access is either allowed or denied (depending on which type of filter this is) to the service specified by service. Here are some examples:

imap: roberts.newyork.example.com
pop: ALL
http: ALL

If these are Allow filters, the first one grants the host roberts.newyork.example.com access to the IMAP service, and the second and third grant all clients access to the POP and HTTP services, respectively. If they are Deny filters, they deny those clients access to those services. For descriptions of wildcard names such as ALL, see "Wildcard Names."

Either the server or the client information in a filter can be somewhat more complex than this, in which case the filter has the more general form of:

serviceSpec:clientSpec

Where serviceSpec can be either service or service@hostSpec, and clientSpec can be either hostSpec or user@hostSpec. Where user is the user name (or a wildcard name) associated with the client host seeking access. Here are two examples:

[e-mail]: ALL
imap: [e-mail]

If these are Deny filters, the first filter denies all clients access to the SMTP service on the host mailServer1.example.com. The second filter denies the user srashad at the host xyz.europe.example.com access to the IMAP service.

Finally, at its most general, a filter has the form:

serviceList:clientList

where serviceList consists of one or more serviceSpec entries, and clientList consists of one or more clientSpec entries. Individual entries within serviceList and clientList are separated by blanks and/or commas.

In this case, when a filter is processed, if the client seeking access matches any of the clientSpec entries in clientList, then access is either allowed or denied (depending on which type of filter this is) to all the services specified in serviceList. Here is an example:

pop, imap, http: .europe.example.com .newyork.example.com

If this is an Allow filter, it grants access to POP, IMAP, and HTTP services to all clients in either of the domains europe.example.com and newyork.example.com. For information on using a leading dot or other pattern to specify domains or subnet, see "Wildcard Patterns."

You can also use the following syntax:

"+" or "-" serviceList:*$next_rule

+ (allow filter) means the daemon list services are being granted to the client list.

- (deny filter) means the services are being denied to the client list.

* (wildcard filter) allow all clients to use these services.

$ separates rules.

The following example enables multiple services on all clients.

+imap,pop,http:*

The following example shows multiple rules, but each rule is simplified to have only one service name and uses wildcards for the client list. (This is the most commonly used method of specifying access control in LDIF files.)

+imap:ALL$+pop:ALL$+http:ALL

An example of how to disallow all services for a user is:

-imap:*$-pop:*$-http:*

Wildcard Names

Table 7-2 shows the wildcard names that represent service names, host names or addresses, or user names:

Table 7-2 Wildcard Names for Service Filters

Wildcard Name	Explanation
ALL, *	The universal wildcard. Matches all names.
LOCAL	Matches any local host (one whose name does not contain a dot character). However, if your installation uses only canonical names, even local host names will contain dots and thus will not match this wildcard.
UNKNOWN	Matches any host whose name or address is unknown. Use this wildcard name carefully. Host names may be unavailable due to temporary DNS server problems - in which case all filters that use UNKNOWN will match all client hosts. A network address is unavailable when the software cannot identify the type of network it is communicating with - in which case all filters that use UNKNOWN will match all client hosts on that network.
KNOWN	Matches any host whose name and address are known. Use this wildcard name carefully: Host names may be unavailable due to temporary DNS server problems - in which case all filters that use KNOWN will fail for all client hosts. A network address is unavailable when the software cannot identify the type of network it is communicating with - in which case all filters that use KNOWN will fail for all client hosts on that network.
DNSSPOOFER	Matches any host whose DNS name does not match its own IP address.

Wildcard Patterns

You can use the following patterns in service or client addresses:

• A string that begins with a dot character (.). A host name is matched if the last components of its name match the specified pattern. For example, the wildcard pattern .example.com matches all hosts in the domain example.com.

• A string of the form n.n.n.n/m.m.m.m. This wildcard pattern is interpreted as a net/mask pair. A host address is matched if net is equal to the bitwise AND of the address and mask. For example, the pattern 123.45.67.0/255.255.255.128 matches every address in the range 123.45.67.0 through 123.45.67.127.

• A string of the form n.n.n.n/p. This wildcard pattern is interpreted as a CIDR where p is the routing prefix. The corresponding subnet mask, mask, is p one bits followed by 32-p zero bits for a total of 32 bits. A host address is matched if the bitwise AND of n.n.n.n and mask is equal to the bitwise AND of the address and mask. For example, the pattern 123.45.67.0/25 matches every address in the range 123.45.67.0 through 123.45.67.127.

EXCEPT Operator

The access-control system supports a single operator. You can use the EXCEPT operator to create exceptions to matching names or patterns when you have multiple entries in either serviceList or clientList. For example, the expression:

list1EXCEPTlist2

means that anything that matches list1 is matched, unless it also matches list2.

Here is an example:

ALL: ALL EXCEPT isserver.example.com

If this were a Deny filter, it would deny access to all services to all clients except those on the host machine isserver.example.com.

EXCEPT clauses can be nested. The expression:

list1 EXCEPT list2 EXCEPT list3

is evaluated as if it were:

list1 EXCEPT (list2 EXCEPT list3)

Server-Host Specification

You can further identify the specific service being requested in a filter by including server host name or address information in the serviceSpec entry. In that case the entry has the form service@hostSpec.

You might want to use this feature when your Messaging Server host machine is set up for multiple Internet addresses with different Internet host names. If you are a service provider, you can use this facility to host multiple domains, with different access-control rules, on a single server instance.

Filter Examples

The examples in this section show a variety of approaches to controlling access. In studying the examples, keep in mind that Allow filters are processed before Deny filters, the search terminates when a match is found, and access is granted when no match is found at all.

The examples listed here use host and domain names rather than IP addresses. Remember that you can include address and netmask information in filters, which can improve reliability in the case of name-service failure.

Mostly Denying

In this case, access is denied by default. Only explicitly authorized hosts are permitted access.

The default policy (no access) is implemented with a single, trivial deny file:

ALL: ALL

This filter denies all service to all clients that have not been explicitly granted access by an Allow filter. The Allow filters, then, might be something like these:

ALL: LOCAL @netgroup1
ALL: .example.com EXCEPT externalserver.example.com

The first rule permits access from all hosts in the local domain (that is, all hosts with no dot in their host name) and from members of the group netgroup1. The second rule uses a leading-dot wildcard pattern to permit access from all hosts in the example.com domain, with the exception of the host externalserver.example.com.

Mostly Allowing

In this case, access is granted by default. Only explicitly specified hosts are denied access.

The default policy (access granted) makes Allow filters unnecessary. The unwanted clients are listed explicitly in Deny filters such as these:

ALL: externalserver.example1.com, .example.asia.com
ALL EXCEPT pop: contractor.example1.com, .example.com

The first filter denies all services to a particular host and to a specific domain. The second filter permits nothing but POP access from a particular host and from a specific domain.

Denying Access to Spoofed Domains

You can use the DNSSPOOFER wildcard name in a filter to detect host-name spoofing. When you specify DNSSPOOFER, the access-control system performs forward or reverse DNS lookups to verify that the client's presented host name matches its actual IP address. Here is an example for a Deny filter:

ALL: DNSSPOOFER

This filter denies all services to all remote hosts whose IP addresses do not match their DNS host names.

Controlling Access to Virtual Domains

If your messaging installation uses virtual domains, in which a single server instance is associated with multiple IP addresses and domain names, you can control access to each virtual domain through a combination of Allow and Deny filters. For example, you can use Allow filters like:

[e-mail]: @.example1.com
[e-mail]: @.example2.com
...

coupled with a Deny filter like:

ALL: ALL

Each Allow filter permits only hosts within domainN to connect to the service whose IP address corresponds to msgServer.exampleN.com. All other connections are denied.

Controlling IMAP Access While Permitting Access to Webmail

If you wish to allow users to access Webmail, but not access IMAP, create a filter like this:

+imap:access_server_host,access_server_host

This permits IMAP only from the access server hosts. You can set the filter at the IMAP server level by using imap.domainallowed, or at the domain/user level with LDAP attributes.

To Create Access Filters for Services

You can create Allow and Deny filters for the IMAP, POP, or HTTP services. You can also create them for SMTP services, but they have little value because they only apply to authenticated SMTP sessions. See the discussion of how to filter mail based on its source or header strings in the Messaging Server System Administrator's Guide.

To Create Filters by Using the Command Line

You can also specify access and deny filters at the command line as follows:

• To create or edit access filters for services:

  msconfig set service.domainallowed filter
  

  where service is POP, IMAP, or HTTP and filter follows the syntax rules described in "Filter Syntax."

• To create or edit deny filters for services:

  msconfig set service.domainnotallowed filter
  

  where service is POP, IMAP, or HTTP and filter follows the syntax rules described in "Filter Syntax." For a variety of examples, see "Filter Examples."

• Restart the relevant services when you make changes to their access filters.

Configuring Encryption and Certificate-Based Authentication

This information describes encryption and certificate-based authentication for Messaging Server in a Unified Configuration.

Topics:

• Encryption and Certificate-Based Authentication Overview

• Obtaining Certificates

• To Enable SSL and Selecting Ciphers

• Configuring Individual Messaging Processes for SSL

• Setting Up Certificate-Based Login

Encryption and Certificate-Based Authentication Overview

Messaging Server uses the Transport Layer Security (TLS) protocol, otherwise known as the Secure Sockets Layer (SSL) protocol, for encrypted communications and for certificate-based authentication of clients and servers. Messaging Server supports SSL versions 3.0 and 3.1. TLS is fully compatible with SSL and includes all necessary SSL functionality.

If transmission of messages between a Messaging Server and its clients and between the server and other servers is encrypted, there is a reduced chance for eavesdropping on the communications. If connecting clients are authenticated, there is also a reduced chance for intruders to impersonate (spoof) them.

SSL functions as a protocol layer beneath the application layers of IMAP4, HTTP, POP3, and SMTP. If SSL is needed with SMTP, it is normally handled on the standard SMTP relay port (25) or the standard SMTP submission port (587) with the STARTTLS command. Alternatively, SMTP submission with SSL can be handled by the port that is often used for SSL submission (465).

HTTP and HTTP/SSL require different ports. IMAP and IMAP/SSL, and POP and POP/SSL can use the same port or different ports. SSL acts at a specific stage of message communication for both outgoing and incoming messages.

Figure 7-1 shows the route of an encrypted outgoing message with Messaging Server.

Figure 7-1 Outgoing Encrypted Communications with Messaging Server

Description of ''Figure 7-1 Outgoing Encrypted Communications with Messaging Server''

Note:

To enable encryption for outgoing SMTP connections, you must modify the channel definition to include the tls channel keywords, such as maytls, musttls, and so on.

Figure 7-2 shows the route of an encrypted incoming message with Messaging Server.

Figure 7-2 Incoming Encrypted Communications with Messaging Server

Description of ''Figure 7-2 Incoming Encrypted Communications with Messaging Server''

SSL provides hop-to-hop encryption, but the message is not encrypted on each intermediate server.

There is a small performance cost to consider in setting up an SSL connection when planning server capacity. To help reduce this cost, cryptographic accelerators can be used.

Obtaining Certificates

Whether you use SSL for encryption or for authentication, you need to obtain a server certificate for your Messaging Server. The certificate identifies your server to clients and to other servers. For more information on certutil, see: http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html.

This section consists of the following subsections:

• To Manage Internal and External Modules

• Creating a Password File

• Obtaining and Managing Certificates

To Manage Internal and External Modules

A server certificate establishes the ownership and validity of a key pair, the numbers used to encrypt and decrypt data. Your server's certificate and key pair represent your server's identity. They are stored in a certificate database that can be either internal to the server or on an external, removable hardware card (smartcard).

Oracle servers access a key and certificate database using a module conforming to the Public-Key Cryptography System (PKCS) #11 API. The PKCS #11 module for a given hardware device is usually obtained from its supplier and must be installed into the Messaging Server before the Messaging Server can use that device. The pre-installed Internal PKCS # 11 Module supports a single internal software token that uses the certificate database that is internal to the server.

Setting up the server for a certificate involves creating a database for the certificate and its keys and installing a PKCS #11 module. If you do not use an external hardware token, you create an internal database on your server, and you use the internal, default module that is part of Messaging Server. If you do use an external token, you connect a hardware smartcard reader and install its PKCS #11 module.

You can manage PKCS #11 modules, whether internal or external, through modutil:

1. Connect a hardware card reader to the Messaging Server host machine and install drivers.

2. To install the PKCS #11 module for the installed driver, use the modutil command found in MessagingServer_home /lib.

Installing Hardware Encryption Accelerators. If you use SSL for encryption, you might be able to improve server performance in encrypting and decrypting messages by installing a hardware encryption (cryptographic) accelerator. An encryption accelerator typically consists of a hardware board, installed permanently in your server machine or integrated into the server CPU, plus a software driver. Messaging Server supports accelerator modules that follow the PKCS #11 API. (They are essentially hardware tokens that do not store their own keys; using the internal database instead.) You install an accelerator by first installing the hardware and drivers as specified by the manufacturer, and then completing the installation - as with hardware certificate tokens - by installing the PKCS #11 module.

Creating a Password File

For most Oracle servers for which SSL is enabled, the administrator is prompted at startup to supply the password required to decrypt the key pair. On Messaging Server however, to alleviate the inconvenience of having to enter the password multiple times (it is needed by at least three server processes), and to facilitate unattended server restarts, the password is read from a password file. Passwords themselves are generated when their certificate database is created, for example, when using the certutil command.

In Unified Configuration, SSL passwords for key files are stored in the xpass.xml file. Use the msconfig set -prompt "sectoken:Internal (Software) Token.tokenpass" command to change. This command causes the msconfig command to prompt for the password without an echo.

Caution:

Because the administrator is not prompted for the module password at server startup, it is especially important that you ensure proper administrator access control to the server and proper physical security of the server host machine and its backups.

Obtaining and Managing Certificates

Whether you use SSL for encryption or for authentication, you need to obtain a server certificate for your Messaging Server. The certificate identifies your server to clients and to other servers. Use the certutil command to manage certificates and key databases. Use certutil with appropriate options (-d followed by a directory location with a sql: prefix and -Z SHA256 -g 2048), or other third-party certificate generation tools, to create certificates and certificate requests with up-to-date security strength.

To run SSL on Messaging Server, you must either use a self-signed certificate or a Public Key Infrastructure (PKI) solution which involves an external Certificate Authority (CA). For a PKI solution, you need a CA-signed server certificate that contains both a public and a private key. This certificate is specific to one Messaging Server. You also need a trusted CA certificate, which contains a public key. The trusted CA certificate ensures that all server certificates from your CA are trusted. This certificate is sometimes also called a CA root key or root certificate. For instructions on how to create and install a self-signed CA certificate and key, see "SSL/TLS Tasks."

To Enable SSL and Selecting Ciphers

Topics in this section:

• About Ciphers

• Specify SSL Certificate

SSL certificates can be installed and configured by using the certutil utility and by running the appropriate msconfig commands to enable SSL for the required services.

About Ciphers

A cipher is the algorithm used to encrypt and decrypt data in the encryption process. SSL cipher suites control the level of protection required between SSL client and server. Different cipher suites have different properties and use different cryptographic algorithms. At any time a specific cryptographic algorithm might be weakened or compromised by new research in cryptography. The ability to change the default cipher suites allows the software to adapt as security technology changes. As CPUs get faster, the key size necessary to provide several years of comfortable protection increases, even if the algorithm is considered state-of-the-art.

The default set of SSL cipher suites used may change over time as more secure ones are introduced and weaker ones are deprecated. It is expected most deployments will be happy with the default set of cipher suites and it is generally not a good idea to adjust the available cipher suites without reason.

However, here are some scenarios where it may be helpful to adjust the cipher suites:

1. A site with specific security policies may wish to provide a fixed list of cipher suites to use that is set by site policy rather than simply using state-of-the-art suites provided by the NSS library. Such a site would typically configure this setting to '-ALL,...' where '...' contains the cipher suite names.

2. A site which is experimenting with higher performance or more secure cipher suites that require installation of special server certificate types, for example, the elliptic curve cipher suites. Such a site would enable these additional suites once installation was complete using a setting such as '+TLS_ECDH_RSA_WITH_AES_128_CBC_SHA' to enable an ECDH_RSA cipher suite from RFC 4492.

3. If a site is forced to continue supporting a particularly old client that only supports weak cipher suites, they can be explicitly enabled (for example 'WEAK+DES' enables the single-DES cipher suites.

4. In the event the cryptographic research community discovers a vulnerability in one or more of the ciphers enabled by default, this provides a mechanism to immediately disable those ciphers.

SSL Ciphers for Messaging Server

See the ssladjustciphersuites option in the Messaging Server Reference for a list of available cipher suites.

This list excludes the SSL2 cipher suites as Messaging Server has not supported SSL2 since the Messaging Server 6.0 release. While the standard names for cipher suites (as published in TLS RFCs) are preferred, there is limited support for legacy names used in previous releases and for some OpenSSL names.

The following configuration options can be used to turn on all cipher suites excluding the weak ones:

• For all services: base.ssladjustciphersuites ”all”

• For individual services: service.ssladjustciphersuites ”all” where service is imapproxy, popproxy, or MMP

However, be advised to instead only turn on the specific cipher suite needed for interoperability. The 56-bit ciphers are not as weak as the 40-bit ciphers so if it's possible to only enable those, the following cipher suite works: +TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA.

Adjusting the SSL Ciphers for Messaging Server

In Unified Configuration, the .cfg files are no longer used, and the configuration is stored in the Unified Configuration itself. In Unified Configuration, you enable and modify the configuration by running the msconfig command to set the appropriate options in the imapproxy, popproxy, and smtpproxy configuration groups. For example, in Unified Configuration, the following command sets the SSL Cipher suite for the IMAP proxy:

msconfig set imapproxy.ssladjustciphersuites cipher suite

Specify SSL Certificate

• To specify the SSL certificate to be presented by Messaging Server, run the following command:

  msconfig set base.sslnicknames certname
  

  For example:

  msconfig set base.sslnicknames "Server-Cert"
  

There is also a per-service configuration setting for the SSL server certificate nickname. The settings are as follows:

mta.sslnicknames for the SMTP and Submit servers, imap.sslnicknames for the IMAP server, pop.sslnicknames for the POP server, and http.sslnicknames for Webmail server.

The *.sslnicknames options have the same meaning as (and override) the base.sslnicknames option. Specifically, this is a comma-separated list of NSS certificate nicknames. Although more than one nickname is permitted in the list, each nickname must refer to a different type of certificate (for example, an RSA certificate and a DSS certificate) so the setting will almost always be only one nickname. A nickname can be unqualified in which case the NSS software token or default token will be searched, or it can have the form security-module:nickname in which case the specified security module will be searched for that nickname. This is needed for certificates stored in hardware tokens or places other than the default NSS database.

This does not permit the use of more than one NSS software token in the product. In particular, there is only one cert8.db and key3.db for IMAP, POP, SMTP, and HTTP. NSS does not permit that.

Note:

To enable SSL encryption for outgoing messages, you must modify the channel definition to include the tls channel options, such as maytls, musttls, and so on.

Configuring Individual Messaging Processes for SSL

This section describes the procedures you use to configure the various Messaging Server processes for SSL.

Topics in this section:

• To Configure MMP for SSL

• To Configure IMAP for SSL

• To Configure POP for SSL

• To Configure HTTP for SSL

• To Configure SMTP for SSL

• To Verify the SSL Configuration

To Configure MMP for SSL

• Use the msconfig command to set the following configuration options to enable SSL:

  msconfig set mmp.enable 1
  msconfig set imapproxy.tcp_listen:imapproxy1.ssl_ports 993
  msconfig set popproxy.tcp_listen:popproxy1.ssl_ports 995
  

To Configure IMAP for SSL

• Use the msconfig command to set the following configuration options to enable SSL:

  msconfig imap.enablesslport 1
  msconfig imap.enable 1
  msconfig imap.sslport 993
  msconfig imap.sslusessl 1
  

To Configure POP for SSL

• Use the msconfig command to set the following configuration options to enable SSL:

  msconfig pop.enablesslport 1
  msconfig pop.enable 1
  msconfig pop.sslport 995
  msconfig pop.sslusessl 1
  

To Configure HTTP for SSL

• Use the msconfig command to set the following configuration options to enable SSL:

  msconfig http.enablesslport 1
  msconfig http.enable 1
  msconfig http.sslport 443
  msconfig http.sslusessl 1
  

To Configure SMTP for SSL

1. To enable SSL encryption for outgoing messages, modify the channel definitions to include the TLS channel options such as maytls, musttls, and so on.

2. (Optional) Use the msconfig command to support SMTP submission with SSL on port 465 instead of the default port 587, which is enabled when a server certificate is installed and often used for SMTP submission with STARTTLS:

   msconfig set dispatcher.service:SMTP_SUBMIT.ssl_ports 465
   

To Verify the SSL Configuration

1. Use the netstat command to verify that the service is running.

   netstat -an | grep service.sslport
   

   where:service is a keyword MMP, IMAP, POP, HTTP, or SMTP. For example:

   msconfig show imap.sslport 
   993
   netstat -an | grep 993 
         *.993                *.*                0      0 49152      0 LISTEN
   

2. Check for errors in the Messaging Server log files. Log files are located in the MessagingServer_home/log directory. For example, check the IMAP log for SSL initialization errors (ASockSSL_Init errors).

Setting Up Certificate-Based Login

In addition to password-based authentication, Oracle servers support authentication of users through examination of their digital certificates. In certificate-based authentication, the client establishes an SSL session with the server and submits the user's certificate to the server. The server then evaluates whether the submitted certificate is genuine. If the certificate is validated, the user is considered authenticated.

To Set Up Certificate-Based Login

1. Obtain a server certificate for your server. (For details, see "Obtaining Certificates.")

2. Install the certificates of any trusted certificate authorities (CAs) that will issue certificates to the users that your server will authenticate. Note that as long as there is at least one trusted CA in the server's database, the server requests a client certificate from each connecting client.

3. Turn on SSL. (For details, see "To Enable SSL and Selecting Ciphers.")

4. Set up a certificate mapping for your server. For example, to make the default certificate map match by the email address in the certificate subject, make the following configuration changes at the msconfig prompt:

   msconfig> set base.certmap:default.dncomps ""
   msconfig# set base.certmap:default.filtercomps "e=mail"
   msconfig# write
   

   For more information about certificate mapping and the dncomp and filtercomps options, see the discussion on certificate-based client authentication in the Messaging Server System Administrator's Guide.

Once you have taken these steps, when a client establishes an SSL session so that the user can log in to IMAP or HTTP, the Messaging Server requests the user's certificate from the client. If the certificate submitted by the client has been issued by a CA that the server has established as trusted, and if the certificate identity matches an entry in the user directory, the user is authenticated and access is granted (depending on access-control rules governing that user). There is no need to disallow password-based login to enable certificate-based login.

If password-based login is allowed (which is the default state), and if you have performed the tasks described in this section, both password-based and certificate-based login are supported. In that case, if the client establishes an SSL session and supplies a certificate, certificate-based login is used. If the client does not use SSL or does not supply a certificate, the server requests a password.

User/Group Directory Lookups Over SSL

It is possible to do user/group directory lookups over SSL for MTA, MMP, and IMAP/POP/HTTP services. The prerequisite is that Messaging Server must be configured in SSL mode.

Set the base.ugldapport to option 636 to enable this feature. For example:

msconfig set base.ugldapport 636

You can also use LDAP + STARTTLS by setting base.ldaprequiretls to 1. For example:

msconfig set base.ldaprequiretls 1