Internet mail protocols such as POP3, IMAP4, HTTP, and SMTP are not inherently secure. Consequently, organizations concerned with securing message transport must use TLS or SSL over these protocols.TLS and SSL secure Internet communications through public and private key encryption.
This section reviews how to set up SSL or TLS on a Novell® NetMail® 3.5 system.
As transport encryption protocols, TLS and SSL both perform the same basic function. There are, however, some notable distinctions.
First, TLS (RFC 2246) incorporates the SSL protocol and is the official Internet standard for transport encryption.
Second, SSL requires its own port assignment for every supported protocol. The following table lists the default SSL port assignments by agent:
| Agent | Port |
|---|---|
ModWeb |
443 |
WebAdmin |
444 |
POP |
995 |
IMAP |
993 |
TLS, on the other hand, can run on any supported protocol's native or SSL port. For example, TLS can run on HTTP port 80 or HTTPS port 443. NetMail allows POP, IMAP, and HTTP mail clients that support TLS to automatically switch to encrypted mode without changing ports.
Because TLS advertises itself in the initial SMTP exchange, mail servers that support TLS also have the ability to automatically switch to encrypted mode. If TLS is configured, NetMail messaging servers automatically switch to encrypted mode when communicating with other mail servers that support TLS.
NOTE: SSL and TLS only encrypt the communication channel; they do not encrypt actual messages. Messages are encrypted according to the S/MIME standard using X.509 client certificates. These certificates are not installed or managed at the server level; they must be installed through the e-mail client. For more information on installing X.509 client certificates, contact your e-mail client vendor.
To support SSL or TLS connections in NetMail, you must have a server certificate and a private key on each messaging server that provides POP, IMAP, HTTP, or SMTP connections.
By default, NetMail 3.5 reads certificates from the following directories:
| Operating System | NetMail 3.5 Certificate Directory |
|---|---|
NetWare® |
sys:\system |
Windows |
drive:\program files\novell\netmail\dbf |
Linux |
/var/opt/novell/netmail/dbf |
If you do not have an existing server certificate and private key, NetMail 3.5 can generate its own self-signed certificates. When you configure the messaging server object during the NetMail portion of the Novell NterpriseTM Linux Services installation, NetMail 3.5 generates its own self-signed certificate. The certificate files, osslcert.pem and osslpriv.pem, are generated in the server's certificate directory.
NOTE: NetMail will not overwrite existing certificates.
If you are upgrading NetMail from a previous version, you can generate a self-signed certificate in the certificate directory by running the NIMSExt utility with the -cert command. For more information, see NIMSExt.
Alternatively, you can use WebAdmin to generate certificates from your workstation. For more information, see Generating Certificates in WebAdmin.
Although self-signed certificates allow the messaging server to immediately support secure HTTP, SMTP, POP, and IMAP connections, there is no trust associated with these certificates and, therefore, they are not secure. Therefore, we do not recommend that you use self-signed certificates in a live NetMail environment. For information on obtaining a secure certificate, see Requesting a New Certificate.
Using a DS editing tool such as NDS® Snoop, you can redefine where NetMail 3.5 looks for SSL certificates and private key files.
To define where a specific messaging server looks for SSL certificates and private key files, add the following information to the Messaging Server object's configuration in eDirectory:
Attribute: NIMS:PKeyFile
Value: directory
Attribute: NIMS:CAFile
Value: directory
To define a default certificate and private key directory for all distributed messaging servers, configure these same attributes in the Internet Services configuration in eDirectory.
NOTE: The certificate and private key directories defined in the Messaging Server object take precedence over the directories defined in the Internet Services configuration.
WebAdmin is currently designed to always run over HTTPS. If you have your own certificate, you must put the server certificate and private key files in the following directories on the messaging server running the WebAdmin Agent:
| Operating System | WebAdmin Certificate Directory |
|---|---|
NetWare |
sys:\system\webadmin |
Windows |
drive:\program files\novell\webadmin |
Linux |
/opt/novell/WebAdmin |
NOTE: You can redefine where WebAdmin looks for SSL certificates and private key files in the Web Administration Server object. For more information, see Configuring WebAdmin.
If WebAdmin does not detect a valid SSL certificate in its certificate directory during startup, it generates its own self-signed certificate (cert.int). This file contains both public and private keys, allowing WebAdmin to secure its connection.
Although self-signed certificates allow the messaging server to immediately support HTTPS connections for WebAdmin, there is no trust associated with these certificates and, therefore, they are not secure. Therefore, we do not recommend that you use self-signed certificates in a live NetMail environment.
For information on making a secure connection to WebAdmin, see Securing Your WebAdmin Connection.
The Create Certificate task in WebAdmin provides three options:
Request a New Certificate allows you to create a Certificate Signing Request.
Generate a Self Signed Certificate creates a valid SSL certificate that allows you to secure POP, IMAP, HTTP, and SMTP connections. However, because they are self-signed, there is no trust associated with these certificates. Consequently, when users make a secure connection to the messaging server, their mail client or Web browser displays a warning indicating that the certificate is not trusted.
Add/Renew a trusted Certificate Authority (CA) appends a CA's public key certificate to your server certificate.
The following sections review the WebAdmin certificate tasks, installing your server certificate, and installing the CA's root certificate:
To obtain an externally signed certificate, you must submit a Certificate Signing Request (CSR) to a Certificate Authority.
A Certificate Authority (CA) is a trusted service that issues digital certificates to other entities (organizations or individuals) to allow them to prove their identity on the Internet. In most cases, the CA is an third party that offers digital certificate services. In some instances, the CA can also have intermediate CAs that provide different levels of certificate services. It is also possible for organizations to manage their own CA using CA services from external or third party CA vendors or CA toolkit products.
NOTE: To select a CA, you should check your e-mail client or browser to determine which CAs it already supports. If you use one of these providers, you probably won't need to install your CA's root certificate on all your e-mail clients or browsers. If, however, you do need to install the root certificate, see Adding or Renewing a Trusted Authority.
A CSR is a Certificate Request File that contains your organization's name, your server's requested distinguished name, and the server's public key. The CA fulfills the certificate request by validating the requesting entity and, if the request is valid, it constructs an X.509 certificate from the distinguished name and public key. The validation process varies per CA, but at a minimum, the CA verifies your organization's identity and collects payment for the certificate.
NOTE: Most certificates expire and must be renewed at regular intervals. To maintain SSL functionality, you must keep your certificate current.
Before you generate your CSR, you will need the following information:
To generate a CSR:
In the WebAdmin task view, click Create Certificate.
Select Request a New Certificate, then click Next.
Complete the information in the requested fields, then click Next.
If you are using a public CA, this information is used to notify you when your certificate needs to be renewed.
Click Private Key to download and save your private key (osslpriv.pem) to a local directory.
IMPORTANT: The private key is required to use the signed certificate you receive from the CA. If you lose the private key, the certificate is useless.
Click Certificate Signing Request to download and save your CSR (osslcsr.pem) to a local directory.
Send the CSR to your CA to be signed.
When you receive your server certificate from the CA, install the certificate and the private key on the NetMail server that responds to the DNS name you specified in the common name field. For more information, see Installing Your Certificate and Private Key.
IMPORTANT: The certificate you receive from your CA references a specific server DNS name. This certificate should be installed only on the server that responds to that DNS name. If you install this certificate on a server with a different DNS name, you will create a naming mismatch between X.509 and DNS. Although it is possible to run NetMail in this configuration, it is not recommended.
Wildcard certificates are the exception to this rule. Wildcard certificates can be installed and used on any server that is within the DNS sub-domain specified in the wildcard certificate. Contact your CA to determine if they support wildcard certificates.
Some CAs might not accept CSRs generated in WebAdmin. In these cases, you can generate a CSR using Apache Mod_SSL and OpenSSL.
NOTE: In order to use SSL with your Apache server, you must have Mod_SSL and OpenSSL installed on your Apache server.
To generate a key pair consisting of Private Key and Certificate Signing Request (CSR) for an Apache server:
Enter the following command:
openssl req -new -nodes -keyout osslpriv.pem -out osslcsr.pem
When prompted, provide the following data for your CSR:
When finished, you have two files: the Private Key file (osslpriv.pem) and the CSR (osslcsr.pem).
IMPORTANT: The private key is required to use the signed certificate you receive from the CA. If you lose the private key, the certificate is useless.
Send the CSR to your CA to be signed.
When you receive your server certificate from the CA, install the certificate and the private key on the NetMail server that responds to the DNS name you specified in the common name field.
For NetMail to recognize the server certificate, it must be named osslcert.pem. For information on installing the certificate and private key, see Installing Your Certificate and Private Key.
IMPORTANT: The certificate you receive from your CA references a specific server DNS name. This certificate should be installed only on the server that responds to that DNS name. If you install this certificate on a server with a different DNS name, you will create a naming mismatch between X.509 and DNS. Although it is possible to run NetMail in this configuration, it is not recommended.
Wildcard certificates are the exception to this rule. Wildcard certificates can be installed and used on any server that is within the DNS sub-domain specified in the wildcard certificate. Contact your CA to determine if they support wildcard certificates.
Self-signed certificates conform to the X.509 certificate standards as defined in RFC 2459. However, because they are self-signed, there is no trust associated with these certificates. Consequently, when users make a secure connection to the messaging server, their mail client or Web browser displays a warning indicating that the certificate is not trusted.
WARNING: We do not recommend that you use self-signed certificates in a live NetMail environment because there is no trust associated with these certificates and, therefore, they are not secure.
Before you generate your self-signed certificate, you will need the following information:
To generate a self-signed certificate:
In the WebAdmin task view, click Create Certificate.
Select Generate a Self Signed Certificate, then click Next.
Complete the information in the requested fields, then click Next.
Click Private Key to download and save your private key (osslpriv.pem) to a local directory.
IMPORTANT: The private key is required to use the self-signed certificate. If you lose the private key, the certificate is useless.
Click Certificate to download and save your self-signed certificate (osslcert.pem) to a local directory.
Install the certificate and private key on the server that responds to the DNS name you specified in the common name field. For more information, see Installing Your Certificate and Private Key.
IMPORTANT: This certificate should be installed only on the server that responds to the DNS name you specified in the certificate's Common Name field. If you install this certificate on a server with a different DNS name, you will create a naming mismatch between X.509 and DNS. Although it is possible to run NetMail in this configuration, it is not recommended.
A Certificate Authority (CA) is a trusted third party that issues digital certificates to other entities (organizations or individuals) to allow them to prove their identity on the Internet. In most cases, the CA is an third party that offers digital certificate services. In some instances, the CA can also have intermediate CAs that provide different levels of certificate services. It is also possible for organizations to manage their own CA using CA services from external or third party CA vendors or CA toolkit products.
In general, for SSL to function properly, your server certificate must include the public key certificate of the CA that directly signed your certificate. This will either be the CA root certificate or the CA intermediate root certificate. Contact your CA vendor for more detailed information on whether they use intermediate root certificates, and if so, how to obtain the intermediate root certificate.
If you obtain a certificate from a service that utilizes an intermediate CA, you can use WebAdmin to append the CA's intermediate certificate to your own server certificate. This allows mail clients and browsers to follow a path of certificate validation until they arrive at a certificate they trust (that is, for which they have a root certificate).
To append a root or intermediate certificate to your server certificate:
Open the CA's root or intermediate certificate and your own server certificate (osslcert.pem) in a text editor so you can copy and paste the certificate data into WebAdmin.
In the WebAdmin task view, click Create Certificate.
Select Add/Renew a Trusted Certificate Authority, then click Next.
Copy and paste the data from your server certificate (osslcert.pem) into the Encoded Certificate field.
IMPORTANT: Be sure to include the BEGIN and END lines.
Copy and paste the data from the CA's root or intermediate certificate into the Root Certificate field.
IMPORTANT: Be sure to include the BEGIN and END lines.
Click Next.
WebAdmin appends the CA's certificate to your server certificate.
Click Certificate to download and save your server certificate (osslcert.pem) to a local directory.
After you have appended the CA root certificate or CA intermediate root certificate to your server certificate, install the consolidated certificate file on the NetMail server. For more information, see Installing Your Certificate and Private Key.
IMPORTANT: The certificate you received from your CA references a specific server DNS name. This certificate should be installed only on the server that responds to that DNS name. If you install this certificate on a server with a different DNS name, you will create a naming mismatch between X.509 and DNS. Although it is possible to run NetMail in this configuration, it is not recommended.
Wildcard certificates are the exception to this rule. Wildcard certificates can be installed and used on any server that is within the DNS sub-domain specified in the wildcard certificate. Contact your CA to determine if they support wildcard certificates.
To install a certificate and private key, copy the certificate (osslcert.pem) and the private key (osslpriv.pem) to the certificate directory on the NetMail server that responds to the DNS name specified in the certificate's common name field.
IMPORTANT: Each server certificate references a specific server DNS name. A server certificate should be installed only on the server that responds to that DNS name. If you install a certificate on a server with a different DNS name, you will create a naming mismatch between X.509 and DNS. Although it is possible to run NetMail in this configuration, it is not recommended.
Wildcard certificates are the exception to this rule. Wildcard certificates can be installed and used on any server that is within the DNS sub-domain specified in the wildcard certificate. Contact your CA to determine if they support wildcard certificates.
For NetMail 3.5, the certificate and private key must be located in the following directories:
| Operating System | NetMail 3.5 Certificate Directory |
|---|---|
NetWare |
sys:\system |
Windows |
drive:\program files\novell\netmail\dbf |
Linux |
/var/opt/novell/netmail/dbf |
For WebAdmin, the certificate and private key must be located in the following directories:
| Operating System | WebAdmin Certificate Directory |
|---|---|
NetWare |
sys:\system\webadmin |
Windows |
drive:\program files\novell\webadmin |
Linux |
/opt/novell/WebAdmin |
The CA's public key certificate identifies the Certificate Authority (CA) that signed your server certificate. In general, for SSL to function properly:
During the initial communication between the server and the client, the server passes its server certificate and the CA's public key certificate to the client. The client must also have its own copy of the CA's public key certificate before it will trust the server's certificate.In some cases, the client does not need the public key certificate of the CA that directly signed your server certificate. If you obtain a server certificate from a service that utilizes an intermediate CA, you can use WebAdmin to append the CA's intermediate certificate to your own server certificate. This allows e-mail clients and browsers to follow a path of certificate validation until they arrive at a certificate they trust (that is, for which they have a public key certificate). For information on adding the CA's public key certificate to your server certificate, Adding or Renewing a Trusted Authority.
Most browser and e-mail clients already include the root and intermediate certificates of popular CAs. The only time you need to install a CA's public key certificate on the client is if your browser or e-mail client does not recognize the CA root certificate or the CA intermediate root certificate included in your server certificate.
To determine which CAs are recognized by your client, locate the list of supported CAs in your e-mail client or browser:
If your CA is not supported, ask your CA for instructions on adding its root certificate to your e-mail client or browser.