|
| |
| Sun Java System Messaging Server 6 2005Q1 Administration Guide | |
Chapter 20
Administering S/MIME for Communications Express MailSecure/Multipurpose Internet Mail Extension (S/MIME) is available on Sun Java System Communications Express Mail. Communications Express Mail users who are set up to use S/MIME can exchange signed or encrypted messages with other users of Communications Express Mail, Microsoft Outlook Express, and Mozilla mail systems.
Information about using S/MIME in Communications Express Mail is part of the online help. Information to administer S/MIME is explained in this chapter. This chapter consists of the following sections:
What is S/MIME?S/MIME provides a Communications Express Mail user with these features:
- Create a digital signature for an outgoing mail message to assure the message’s recipient that the message was not tampered with and is from the person who sent it
- Encrypt an outgoing mail message to prevent anyone from viewing, changing or otherwise using the message’s content before the message arrives in the recipient’s mailbox
- Verify the digital signature of an incoming signed message with a process involving a certificate revocation list (CRL)
- Automatically decrypt an incoming encrypted message so the recipient can read the message’s contents
- Exchange signed or encrypted messages with other users of an S/MIME compliant client such as Communications Express Mail and Mozilla mail systems
Concepts You Need to Know
To properly administer S/MIME, you need to be familiar with the following concepts:
- Basic administrative procedures for your platform
- Structure and use of a lightweight directory access protocol (LDAP) directory
- Addition or modification of entries in an LDAP directory
- Configuration process for the Sun Java System Directory Server
- Concepts and purpose of the following:
- Secure Socket Layer (SSL) for a secured communications line
- Digitally signed email messages
- Encrypted email messages
- Local key store of a browser
- Smart cards and the software and hardware to use them
- Private-public key pairs and their certificates
- Certificate authorities (CA)
- Verifying keys and their certificates
- Certificate revocation list (CRL). (See When is a Certificate Checked Against a CRL? for an introduction.)
Required Software and Hardware ComponentsThe required hardware and software for using Communications Express Mail with S/MIME is described in this section. Ensure that you install all the correct versions of the software on the server and client machines before attempting to configure for S/MIME.
Table 20-1 lists the required software and hardware for the client machine where Communications Express Mail is accessed.
Table 20-1 Required Hardware and Software for Client Machine
Component
Description
Operating system
Browser
Sun software
Sun Java 2 Runtime Environment, Standard Edition, Version 1.4.2_03 or later, but not 1.5
Private-public keys with certificates
One or more private-public key pair with certificates. Certificates are required and they must be in standard X.509 v3 format. Obtain keys and certificates from a CA for each Communications Express Mail user who will use the S/MIME features. The keys and their certificates are stored on the client machine or on a smart card. The public keys and certificates are also stored in an LDAP directory that can be accessed by Directory Server.
A certificate revocation list (CRL), maintained by the CA, must be part of your system if you want key certificates checked against it to further ensure that the keys are valid. See When is a Certificate Checked Against a CRL?.
Smart card software (only required when keys and certificates are stored on smart cards)
Smart card reader
Any model of smart card reading device supported by the client machine and smart card software.
Table 20-2 lists the required Sun Microsystems software for the server machine.
Requirements for Using S/MIMEThe signature and encryption features are not immediately available to Communications Express Mail users after you install Messaging Server. Before a user can take advantage of S/MIME, the requirements described in this section must be met.
Private and Public Keys
At least one private and public key pair, including a certificate in standard X.509 v3 format, must be issued to each Communications Express Mail user who will use S/MIME. The certificate, used in a verification process, assures other mail users that the keys really belong to the person who uses them. A user can have more than one key pair and associated certificate.
Keys and their certificates are issued from within your organization or purchased from a third-party vendor. Regardless of how the keys and certificates are issued, the issuing organization is referred to as a certificate authority (CA).
Key pairs and their certificates are stored in two ways:
These cards are similar to commercial credit cards and should be used and safeguarded by the mail user as they do their own credit cards. Smart cards require special card readers attached to the mail user’s computer (client machine) to read the private key information. See Keys Stored on Smart Cards for more information.
A mail user’s browser provides the key store. The browser also provides commands to download a key pair and certificate to the key store. See Keys Stored on the Client Machine for more information
Keys Stored on Smart Cards
If the private-public key pair, with its certificate, is stored on a smart card, a card reader must be properly attached to the mail user’s computer. The card reading device also requires software; the device and its software are supplied by the vendor from whom you purchase this equipment.
When properly installed, a mail user inserts their smart card into the reading device when they want to create a digital signature for an outgoing message. After verification of their smart card password, the private key is accessible by Communications Express Mail to sign the message. See Required Software and Hardware Components for information on the supported smart cards and reading devices.
Libraries from the vendor of the smart card are required on the user’s computer. See Key Access Libraries for the Client Machines for more information.
Keys Stored on the Client Machine
If key pairs and certificates are not stored on smart cards, they must be kept in a local key store on the mail user’s computer (client machine). Their browser provides the key store and also has commands to download a key pair and certificate to the key store. The key store may be password-protected; this depends on the browser.
Libraries from the vendor of the browser are required on the user’s computer to support a local key store. See Key Access Libraries for the Client Machines for more information.
Publish Public Keys in LDAP Directory
All public keys and certificates must also be stored to an LDAP directory, accessible by the Sun Java System Directory Server. This is referred to as publishing the public keys so they are available to other mail users who are creating S/MIME messages.
Public keys of the sender and receiver are used in the encrypting-decrypting process of an encrypted message. Public key certificates are used to validate private keys that were used for digital signatures.
See Managing Certificates for more information to use ldapmodify to publish the public keys and certificates.
Give Mail Users Permission to Use S/MIME
To create a signed or encrypted message, a valid Communications Express Mail user must have permission to do so. This involves using the mailAllowedServiceAccess or mailDomainAllowedServiceAccess LDAP attributes for a user’s LDAP entry. These attributes can be used to include or exclude mail users from S/MIME on an individual or domain basis.
See Granting Permission to Use S/MIME Features for more information.
Multi-language Support
A Communications Express Mail user who only uses English for their mail messages might not be able to read an S/MIME message which contains non-Latin language characters, such as Chinese. One reason for this situation is that the Java 2 Runtime Environment (JRE) installed on the user’s machine does not have the charsets.jar file in the /lib directory.
The charsets.jar file is not installed if the English version of JRE was downloaded using the default JRE installation process. However, charsets.jar is installed for all other language choices of a default installation.
To ensure that the charsets.jar file is installed in the /lib directory, alert your users to use the custom installation to install the English version of JRE. During the installation process, the user must select the “Support for Additional Languages” option.
Getting Started After Installing Messaging ServerThis section explains what the S/MIME applet is and provides a basic configuration procedure to set up S/MIME for Communications Express Mail. The configuration process involves setting parameters for the S/MIME applet and options for Messaging Server.
The S/MIME Applet
The process of signing a message, encrypting a message, or decrypting a message, along with the various procedures to verify private and public keys, are handled by a special applet, referred to as the S/MIME applet. The configuration of the S/MIME features is done with parameters in the smime.conf file and options of Messaging Server. Figure 20-1 shows the S/MIME Applet in relation to other system components.
Figure 20-1 S/MIME Applet
Logging In for the First Time
When a Communications Express Mail user who has permission to use S/MIME logs in to the Messaging Server for the first time, a series of special prompts displays about the S/MIME applet. After answering the prompts with Yes or Always, the S/MIME applet is downloaded to their computer. The applet remains on their machine until they log out of Communications Express Mail.
Refer to Managing Certificates for more information.
Downloading the S/MIME Applet
The S/MIME applet is downloaded each time a user logs in to Communications Express Mail unless caching is enabled for the Java 2 Runtime Environment (JRE) on the user’s machine. When caching is enabled, a copy of the S/MIME applet is saved on the user’s machine after the initial download which prevents downloading the applet every time the user logs in.
Caching can improve performance so you might direct your users to do the following steps to enable caching for Java 2 Runtime Environment, Version 1.4.x:
After downloading, a user is not aware of the S/MIME applet. It appears that signing, encrypting, or decrypting a message is done by Communications Express Mail. Unless an error message pops up, the user also is unaware of the processes to verify a private or public key. Refer to Verifying Private and Public Keys for more information.
A Basic S/MIME Configuration
The configuration file for S/MIME, smime.conf, contains descriptive comments and an example of each S/MIME parameter. The smime.conf file is included with Messaging Server, located in the directory msg-svr-base/config/, where msg-svr-base is the directory where Messaging Server is installed.
The following procedure contains the minimum required steps to configure the S/MIME features:
- Verify that the basic features of Communications Express Mail are working after you install Messaging Server.
- If you haven’t already, create or obtain private-public key pairs, with certificates in standard X.509 v3 format, for all your mail users who have permission to use the S/MIME features.
- If smart cards are used for keys and certificates:
- If local key stores of the browsers are used to store keys and certificates, instruct your mail users how to download their key pairs and certificate to the local key store.
- Ensure that the correct libraries are on the client machines to support smart cards or local key stores. See Key Access Libraries for the Client Machines for more information.
- Set up your LDAP directory to support S/MIME:
- Store all certificates for the CAs in the LDAP directory, accessible by Directory Server, under the distinguished name for certificate authorities. The LDAP attribute for these certificates is cacertificate;binary.Write down the directory information where you store them. You’ll need this information for a later step.
See trustedurl for an example of specifying LDAP directory information and Managing Certificates for information to search an LDAP directory.
- Store the public keys and certificates in the LDAP directory accessible by Directory Server. The LDAP attribute for public keys and certificates is usercertificate;binary. Write down the directory information where you store them. You’ll need this information for a later step.
See certurl for an example of specifying LDAP directory information and Managing Certificates for information to search an LDAP directory.
- Ensure that all users who send or receive S/MIME messages are given permission to use S/MIME with an LDAP filter in their user entries. A filter is defined with the mailAllowedServiceAccess or mailDomainAllowedServiceAccess LDAP attributes.
Note: By default, if you do not use mailAllowedServiceAccess or mailDomainAllowedServiceAccess, all services including smime, are allowed. If you explicitly specify services with these attributes, then the services http and smtp, as well as smime, must be specified to give mail users permission to use the S/MIME features.
See Granting Permission to Use S/MIME Features for more information.
- Edit the smime.conf file with any available text editor. See comments at the beginning of the file for parameter syntax.
All text and example parameters in smime.conf are preceded with a comment character (#). You can add the parameters you need to smime.conf or copy a parameter example to another part of the file and change its value. If you copy and edit an example, be sure to remove the # character at the beginning of its line.
Add these parameters to the file, each on its own line:
- trustedurl -- set to the LDAP directory information to locate the certificates of the CAs. Use the information you saved from Step 6Step a.
- certurl -- set to the LDAP directory information to locate the public keys and certificates. Use the information you saved from Step 6Step b.
- usercertfilter -- set to the value of the example in the smime.conf file. The example value is almost always the filter you want. Copy the example and delete the # character at the beginning of the line.
This parameter specifies a filter definition for the primary, alternate, and equivalent email addresses of a Communications Express Mail user to ensure that all of a user’s private-public key pairs are found when the key pairs are assigned to different mail addresses.
- sslrootcacertsurl -- if you are using SSL for the communications link between the S/MIME applet and Messaging Server, set sslrootcacertsurl with the LDAP directory information to locate the certificates of CAs that are used to verify the Messaging Server’s SSL certificates. See Securing Internet Links With SSL for more information.
checkoverssl -- set to 0 if you are not using SSL for the communications link between the S/MIME applet and Messaging Server.
- crlenable -- set to 0 to disable CRL checking for now because doing CRL checking might require adding other parameters to the smime.conf file.
- logindn and loginpw -- if the LDAP directory that contains the public keys and CA certificates requires authentication to access it, set these parameters to the distinguished name and password of the LDAP entry that has read permission.
Note: The values of logindn and loginpw are used whenever the LDAP directory is accessed with the LDAP information specified by the certurl, crlmappingurl, sslrootcacertsurl, or trustedurl parameters. See Accessing LDAP for Public Keys, CA certificates and CRLs Using Credentials for more information.
Do not set logindn and loginpw if authentication is not required to access the LDAP directory.
- Set the Messaging Server options with configutil:
- local.webmail.smime.enable -- set to 1.
- local.webmail.cert.enable -- set to 1 if you want to verify certificates against a CRL.
See Messaging Server Options for more information.
- Communications Express Mail is now configured for the S/MIME features. Verify that the S/MIME features are working with the following steps:
- Restart the Messaging Server.
- Check the Messaging Server log file, msg-svr-base/log/http, for diagnostic messages relating to S/MIME.
- If any problems were detected for S/MIME, the diagnostic messages help you determine how to correct the problem with the configuration parameters.
- Correct the necessary configuration parameters.
- Repeat Steps a. through d. until there are no more diagnostic messages for S/MIME in the Messaging Server’s log file.
- Check that the S/MIME features are working with the following steps:
- Log in to Messaging Server from a client machine. Answer the special prompts for the S/MIME applet with Yes or Always. See Managing Certificates for more information.
- Compose a short message, addressed to yourself.
- Encrypt your message by checking the Encrypt checkbox at the bottom of the Compose window if it is not already checked.
- Click Send to send the encrypted message to yourself. This should exercise most of the mechanisms for keys and certificates.
- If you find problems with the encrypted message, the most likely causes are the values you used for LDAP directory information in the smime.conf file and/or the way keys and certificates are stored in the LDAP directory. Check the Messaging Server log for more diagnostic messages.
The remaining S/MIME parameters, summarized in Table 20-3, provide many options you might want to use to further configure your S/MIME environment. See Parameters of the smime.conf File for more information about the parameters.
* You must specify a value for these parameters because they have no default value.
Accessing LDAP for Public Keys, CA certificates and CRLs Using Credentials
Public keys, CA certificates, and CRLs required for S/MIME may be stored in an LDAP directory (see previous section). The keys, certificates, and CRLs may be accessible from a single URL or multiple URLs in LDAP. For example, CRLs may be stored in one URL and public keys and certificates may be stored in another. Messaging Server allows you to specify which URL contains the desired CRL or certificate information, as well as the DN and password of the entry that has access to these URLs. These DN/password credentials are optional; if none are specified, LDAP access first tries the HTTP server credentials, and if that fails, it tries accessing it as anonymous.
Two pairs of smime.conf credential parameters may be set to access the desired URLs: logindn and loginpw, and crlurllogindn and crlurlloginpw.
logindn and loginpw are the credentials used for all URLs in smime.conf. They specify the DN and password of the LDAP entry that has read permission for the public keys, their certificates, and the CA certificates as specified by the certurl and trustedurl parameters.
crlurllogindn and crlurlloginpw specifies the DN and password of the LDAP entry that has read permission for the resulting URL from the mapping table (see Accessing a CRL for more information). If these credentials are NOT accepted, LDAP access is denied and no retry with other credentials is attempted. Either both parameters must be specified, or both must be empty. These parameters do not apply to the URLs that come directly from the certificate.
Setting Passwords for Specific URLs
Messaging Server allows you to specifically define the DN/password pairs for accessing the following smime.conf URLs: certUrl, trustedUrl, crlmappingUrl, sslrootcacertsUrl.
The syntax is as follows:
url_type URL[|URL_DN | URL_password]
Example:
trustedurl==ldap://mail.siroe.com:389/cn=Directory Manager, ou=people, o=siroe.com,o=ugroot?cacertificate?sub?(objectclass=certificationauthority) | cn=Directory manager | boomshakalaka
Summary of Using LDAP credentials
This section summarizes the use of LDAP credentials.
1) Local LDAP credential pair - if specified, only one tried
2) Default LDAP Credential Pair - if specified, and no Local LDAP credential pair, only one tried
3) Server - if neither Local LDAP credential pair nor default LDAP credential pair specified, first tried
4) anonymous - last tried only if server fails or none specified
Parameters of the smime.conf FileThe smime.conf file is included with the Messaging Server, located in the directory msg-svr-base/config/, where msg-svr-base is the directory where Messaging Server is installed. All text and parameter examples in the file are preceded with a comment character (#).
You can add parameters with your values to the smime.conf file or you can edit the parameter examples. If using an example, copy the example to another part of the file, edit the parameter’s value, and remove the # character at the beginning of the line.
Edit smime.conf with any available text editor after you install Messaging Server. The parameters, described in Table 20-4, are not case sensitive and unless otherwise stated, are not required to be set.
Table 20-4 S/MIME Configuration Parameters in smime.conf File
Parameter
Purpose
alwaysencrypt
Controls the initial setting for whether all outgoing messages are automatically encrypted for all Communications Express Mail users with permission to use S/MIME. Each Communications Express Mail user can override this parameter’s value for their messages by using the checkboxes described in Table 20-6.
Choose one of these values:
0 - do not encrypt messages. The encryption checkboxes within Communications Express Mail are displayed as unchecked. This is the default.
1 - always encrypt messages.The encryption checkboxes within Communications Express Mail are displayed as checked.
Example:
alwaysencrypt==1
alwayssign
Controls the initial setting for whether all outgoing messages are automatically signed for all Communications Express Mail users with permission to use S/MIME. Each Communications Express Mail user can override this parameter’s value for their messages by using the checkboxes described in Table 20-6.
Choose one of these values:
0 - do not sign messages. The signature checkboxes within Communications Express Mail are displayed as unchecked. This is the default.
1 - always sign messages.The signature checkboxes within Communications Express Mail are displayed as checked.
Example:
alwaysensign==1
certurl
Specifies the LDAP directory information to locate the public keys and certificates of Communications Express Mail users (the LDAP attribute for public keys is usercertificate;binary). See Managing Certificates for more information about certificates.
This parameter must point to the highest node in the user/group of the LDAP directory information tree (DIT) that includes all users that are being served by the Messaging Server. This is particularly important for sites with more than one domain; the distinguished name must be the root distinguished name of the user/group tree instead of the subtree that contains users for a single domain.
This is a required parameter that you must set.
Example:
certurl==ldap://mail.siroe.com:389/ou=people, o=siroe.com, o=ugroot
checkoverssl
Controls whether an SSL communications link is used when checking a key’s certificate against a CRL. See Securing Internet Links With SSL for more information.
Choose one of these values:
0 - do not use an SSL communications link.
1 - use an SSL communications link. This is the default.
A problem can occur when a proxy server is used with CRL checking in effect. See Proxy Server and CRL Checking for more information.
crlaccessfail
Specifies how long to wait before the Messaging Server attempts to access a CRL after it has failed to do so after multiple attempts. This parameter has no default values.
Syntax:
crlaccessfail==number_of_failures:time_period_for_failures:wait_time_before_retry
where:
number_of_failures is the number of times that the Messaging Server can fail to access a CRL during the time interval specified by time_period_for_failures. The value must be greater than zero.
time_period_for_failures is the number of seconds over which the Messaging Server counts the failed attempts to access a CRL. The value must be greater than zero.
wait_time_before_retry is the number of seconds that the Messaging Server waits, once it detects the limit on failed attempts over the specified time interval, before trying to access the CRL again. The value must be greater than zero.
Example:
crlaccessfail==10:60:300
In this example, Messaging Server fails 10 times within a minute to access the CRL. It then waits 5 minutes before attempting to access the CRL again. See Trouble Accessing a CRL for more information.
crldir
Specifies the directory information where the Messaging Server downloads a CRL to disk. The default is msg-svr-base/data/store/mboxlist, where msg-svr-base is the directory where Messaging Server is installed. See Using a Stale CRL for more information.
crlenable
Controls whether a certificate is checked against a CRL. If there is a match, the certificate is considered revoked. The values of the send*revoked parameters in the smime.conf file determine whether a key with a revoked certificate is rejected or used by Communications Express Mail. See Verifying Private and Public Keys for more information.
Choose one of these values:
0- each certificate is not checked against a CRL.
1- each certificate is checked against a CRL. This is the default. Ensure that the local.webmail.cert.enable option of the Messaging Server is set to 1, otherwise CRL checking is not done even if crlenable is set to 1.
crlmappingurl
Specifies the LDAP directory information to locate the CRL mapping definitions. This parameter is only required when you have mapping definitions. See Accessing a CRL for more information. This parameter has no default value. You can also optionally add the DN and password that has access to the URL.
Syntax:
crlmappingurl URL[|URL_DN | URL_password]
Example:
crlmappingurl==ldap://mail.siroe.com:389/cn=XYZ Messaging, ou=people, o=mail.siroe.com,o=isp?msgCRLMappingRecord?sub?(objectclass=msgCRLMappingTable)|cn=Directory Manager | pAsSwOrD
crlurllogindn
Specifies the distinguished name of the LDAP entry that has read permission for the CRL mapping definitions (not if the entry is directly from the certificate, see “Accessing a CRL” on page 904. for more information).
If values for crllogindn and crlloginpw are not specified, the Messaging Server uses the log in values for the HTTP server to gain entry to the LDAP directory. If that fails, Messaging Server attempts to access the LDAP directory anonymously.
Example:
crllogindn==cn=Directory Manager
crlurlloginpw
Specifies the password, in ASCII text, for the distinguished name of the crllogindn parameter.
If values for crllogindn and crlloginpw are not specified, Messaging Server uses the log in values for the HTTP server to gain entry to the LDAP directory. If that fails, Messaging Server attempts to access the LDAP directory anonymously.
Example:
crlloginpw==zippy
crlusepastnextupdate
Controls whether a CRL is used when the current date is past the date specified in the CRL’s next-update field. See Using a Stale CRL for more information.
Choose one of these values:
0 - do not use the stale CRL.
1 - use the stale CRL. This is the default.
logindn
Specifies the distinguished name of the LDAP entry that has read permission for the public keys and their certificates, and the CA certificates located in the LDAP directory specified by the certurl and trustedurl parameters.
If values for logindn and loginpw are not specified, the Messaging Server uses the log in values for the HTTP server to gain entry to the LDAP directory. If that fails, Messaging Server attempts to access the LDAP directory anonymously.
Example:
logindn==cn=Directory Manager
loginpw
Specifies the password, in ASCII text, for the distinguished name of the logindn parameter.
If values for logindn and loginpw are not specified, Messaging Server uses the log in values for the HTTP server to gain entry to the LDAP directory. If that fails, Messaging Server attempts to access the LDAP directory anonymously.
Example:
loginpw==SkyKing
platformwin
Specifies one or more library names that are necessary when using smart cards or a local key store on a Windows platform. Change this parameter only if the default value does not work for your client machines. The default is:
platformwin==CAPI:library=capibridge.dll;
See Key Access Libraries for the Client Machines for more information.
readsigncert
Controls whether a public key’s certificate is checked against a CRL to verify an S/MIME digital signature when the message is read. (A private key is used to create a digital signature for a message but it cannot be checked against a CRL, so the certificate of the public key associated with the private key is checked against the CRL.) See Verifying Private and Public Keys for more information.
Choose one of these values:
0 - do not check the certificate against a CRL.
1 - check the certificate against a CRL.This is the default.
revocationunknown
Determines the action to take when an ambiguous status is returned when checking a certificate against a CRL. In this case, it is not certain whether the certificate is valid or has a revoked status. See Verifying Private and Public Keys for more information.
Choose one of these values:
ok - treat the certificate as valid.
revoked - treat the certificate as revoked. This is the default.
sendencryptcert
Controls whether the certificate of a public key that is used to encrypt an outgoing message is checked against a CRL before using it. See Verifying Private and Public Keys for more information.
Choose one of these values:
0 - do not check the certificate against a CRL.
1 - check the certificate against a CRL.This is the default.
sendencryptcertrevoked
Determines the action to take if the certificate of a public key that is used to encrypt an outgoing message is revoked. See Verifying Private and Public Keys for more information.
Choose one of these values:
allow - use the public key.
disallow - do not use the public key.This is the default.
sendsigncert
Controls whether a public key’s certificate is checked against a CRL to determine if a private key can be used to create a digital signature for an outgoing message. (A private key is used for a digital signature but it cannot be checked against a CRL, so the certificate of the public key associated with the private key is checked against the CRL.) See Verifying Private and Public Keys for more information.
Choose one of these values:
0 - do not check the certificate against a CRL.
1 - check the certificate against a CRL.This is the default.
sendsigncertrevoked
Determines the action to take when it is determined that a private key has a revoked status. (A private key is used to create a digital signature for a message but it cannot be checked against a CRL, so the certificate of the public key associated with the private key is checked against the CRL. If the public key certificate is revoked, then it’s corresponding private key is also revoked.) See Verifying Private and Public Keys for more information.
Choose one of these values:
allow - use the private key with a revoked status.
disallow - do not use the private key with a revoked status. This is the default.
sslrootcacertsurl
Specifies the distinguished name and the LDAP directory information to locate the certificates of valid CAs which are used to verify the Messaging Server’s SSL certificates. This is a required parameter when SSL is enabled in the Messaging Server. See Securing Internet Links With SSL for more information.
If you have SSL certificates for a proxy server that receives all requests from client application, the CA certificates for those SSL certificates must also be located in the LDAP directory pointed to by this parameter.
You can also optionally add the DN and password that has access to the URL.
Syntax:
crlmappingurl URL[|URL_DN | URL_password]
Example:
sslrootcacertsurl==ldap://mail.siroe.com:389/cn=SSL Root CA Certs, ou=people, o=siroe.com, o=isp? cacertificate;binary?base?
(objectclass=certificationauthority)|cn=Directory Manager | pAsSwOrDtimestampdelta
Specifies a time interval, in seconds, that is used to determine whether a message’s sent time or received time is used when checking a public key’s certificate against a CRL.
The parameter’s default value of zero directs Communications Express Mail to always use the received time. See Determining Which Message Time to Use for more information.
Example:
timestampdelta==360
trustedurl
Specifies the distinguished name and LDAP directory information to locate the certificates of valid CAs. This is a required parameter.
You can also optionally add the DN and password that has access to the URL.
Syntax:
crlmappingurl URL[|URL_DN | URL_password]
Example:
trustedurl==ldap://mail.siroe.com:389/cn=Directory Manager, ou=people, o=siroe.com,o=ugroot?cacertificate?sub?(objectclass=certificationauthority)|cn=Directory Manager | pAsSwOrD
usercertfilter
Specifies a filter definition for the primary, alternate, and equivalent email addresses of a Communications Express Mail user to ensure that all of a user’s private-public key pairs are found when they are assigned to different mail addresses.
This parameter is required and has no default values.
Messaging Server OptionsTo set the three Messaging Server options that apply to S/MIME, do the following on the machine where the Messaging Server is installed:
- Log in as root. Then enter:
# cd msg-svr-base/sbin
where msg-svr-base is the directory where Messaging Server is installed.
- Set the Messaging Server options, described in the following table, as desired for your system. Use the configutil utility to set them. Unless stated otherwise, an option is not required to be set.
Securing Internet Links With SSLThe Messaging Server supports the use of the Secure Socket Layer (SSL) for Internet links affecting Communications Express Mail, as summarized in the following table.
Link Between:
Description
Messaging Server and Communications Express Mail
Securing this link with SSL requires administrative work for the Messaging Server. The Communications Express Mail user must use the HTTPS protocol, rather than HTTP, when entering the URL information for the Messaging Server in their browser.
See Securing the Link Between Messaging Server and Communications Express Mail for more information.
Messaging Server and S/MIME applet
When checking public keys certificates against a CRL, the S/MIME applet must communicate directly with the Messaging Server. Securing this link with SSL requires administrative work for the Messaging Server in addition to setting sslrootcacertsurl and checkoverssl in the smime.conf file.
See Securing the Link Between the Messaging Server and S/MIME Applet for more information.
Securing the Link Between Messaging Server and Communications Express Mail
The Messaging Server supports the use of Secure Socket Layer (SSL) for the Internet link between it and Communications Express Mail. Once you have set up Messaging Server for SSL, configure Communications Express for SSL See Communications Express Administration Guide (http://docs.sun.com/doc/819-0115). A Communications Express Mail user specifies the Communications Express URL in their browser with the HTTPS protocol:
HTTPS://hostname.domain:secured_port
instead of the HTTP protocol (HTTP://hostname.domain:unsecure_port). When the Communications Express login window displays, the user sees a lock icon in a locked position at the bottom of their window to indicate they have a secure link.
See Configuring Encryption and Certificate-Based Authentication for SSL configuration information for Messaging Server, as well as the Communications Express Administration Guide (http://docs.sun.com/doc/819-0115).
Securing the Link Between the Messaging Server and S/MIME Applet
When checking the certificate of a public key against a CRL, the S/MIME applet must communicate directly with the Messaging Server. To secure this communications link with SSL:
- Do the administrative tasks to configure the Messaging Server for SSL. See Configuring Encryption and Certificate-Based Authentication.
- Set the sslrootcacertsurl parameter in the smime.conf file to specify the information to locate the root SSL CA certificates. These CA certificates are used to verify the Messaging Server’s SSL certificates when the SSL link is established between the Messaging Server and the S/MIME applet.
- Set the checkoverssl parameter in the smime.conf file to 1. This Messaging Server option determines whether SSL is used for the link between the Messaging Server and the S/MIME applet. Regardless of how a Communications Express Mail user specifies the URL for the Messenger Server (HTTP or HTTPS), the link between the Messaging Server and the S/MIME applet is secured with SSL when checkoverssl is set to 1.
Note
A proxy server can be used between the Messaging Server and client applications such as Communications Express Mail. See Proxy Server and CRL Checking for more information about using a proxy server with and without a secured communications link.
Key Access Libraries for the Client MachinesWhether your mail users keep their private-public key pairs and certificates on a smart card or in a local key store of their browsers, key access libraries must be present on the client machines to support the storage methods.
The libraries are supplied by vendors of the smart cards and browsers. You must ensure that the correct libraries are on the client machines and specify the library name or names with the appropriate platform parameter in the smime.conf file. The parameters choices are:
You can specify only the libraries you know are installed on the client machines or you can specify all the library names for a given platform and vendor if you are not sure what is installed. If the S/MIME applet does not find the library it needs among the names you specify, the S/MIME features do not work.
The syntax to specify one or more library filenames is:
platform_parameter==vendor:library=library_name;...
where:
platorm_parameter is the parameter name for the platform of the client machine where Communications Express Mail is accessed. Choose one of these names: platformwin
vendor specifies the vendor of the smart card or browser. Choose one of these literals:
cac (for an ActivCard or NetSign smart card)
capi (for Internet Explorer with CAPI)
mozilla (for Mozilla with Network Security Services)library_name specifies the library filename. See Table 20-5 for the library name for your vendor and operating system.
Example
The following example specifies one smart card library and one Internet Explorer library, and one Mozilla library for a Windows platform:
platformwin==CAC:library=acpkcs211.dll;CAPI:library=capibridge.dll;
MOZILLA:library=softokn3.dll;
Verifying Private and Public KeysBefore Communications Express Mail uses a private or public key, it must pass the verification tests shown in Figure 20-2. The remainder of this section describes the details of checking a public key’s certificate against a CRL.
Figure 20-2 Verifying Private and Public Keys.
Finding a User’s Private or Public Key
When a Communications Express Mail user has multiple private-public key pairs and multiple email addresses (primary, alternate, or alias addresses), it is possible that their keys are associated among their addresses. In this case, it is important that the S/MIME applet finds all the keys for verification purposes. Use the usercertfilter parameter in the smime.conf file to define a filter that creates a list of mail addresses for a key’s owner at the time the public key’s certificate is checked against a CRL. See usercertfilter for more information.
When is a Certificate Checked Against a CRL?
A certificate revocation list, or CRL, is a list of revoked certificates maintained by the CA who issues the key pairs and certificates. When CRL checking is enabled, it causes the system to check the CRL whenever a certificate request has been made to see whether or not that certificate has been revoked.
When crlenable is set to 1 in the smime.conf file, a CRL test is performed after an unexpired key is found. The public key’s certificate is checked against a CRL. There can only be one CRL for each CA, however the same CRL can be located in different places.
Checking a certificate against a CRL is done by the Messaging Server after the S/MIME applet sends it a request to do so. A public key certificate is used to validate a public key. Because a private key is kept secret, only used by the person who owns it, a private key cannot be checked directly against a CRL. To determine if a private key is good, the public key certificate of the key pair is used. When the public key’s certificate passes the CRL test, the associated private key passes the test too.
Revocation of a certificate can happen for a variety of reasons, such as its owner has left your organization or lost the smart card.
There are three situations for checking a certificate against a CRL:
Accessing a CRL
A certificate contains zero or more URLs, known as distribution points, that are used by Messaging Server to locate a CRL. If the certificate does not have a CRL URL, it cannot be checked against a CRL and the private or public key is used to sign or encrypt a message without knowing its true status.
If Messaging Server fails to locate or gain access to a CRL after trying all the URLs available to it, the status of the certificate is treated as unknown. Whether a private or public key with an unknown status is used is determined by the setting of revocationunknown.
While only one CRL for each CA is supported, there can be multiple copies of the same CRL in different locations, reflected in different URLs among a user’s public key certificates. Messaging Server tries all the URL locations for a certificate until it gains access to the CRL.
You can manage multiple copies of a CRL for optimum access by periodically downloading the current CRL from the CA to a place where you want it. While you cannot change the URLs embedded in the certificates, you can redirect Messaging Server to use new CRL locations by mapping the URLs in a certificate to a new URL containing the CRL information. Create a list of one or more mapping definitions in the LDAP directory (see crlmappingurl) with this syntax:
msgCRLMappingRecord=url_in_certificate==new_url[|url_login_DN|url_login_password]
url_in_certificate is the URL in the certificate containing the old information to locate the CRL. new_url is the new URL containing the new CRL information. url_login_DN and url_login_password are the DN and password of the entry allowed access to new_url. Both are are optional, and if specified, will be used for the new URL access only.
If the DN and password fails, LDAP access is denied and no retry with other credentials is attempted. These login credentials are only valid for LDAP URLs. If you use crlurllogindn and crlurlloginpw in smmime.conf, then you don’t need to specify the login DN and password in the mapping record. See Accessing LDAP for Public Keys, CA certificates and CRLs Using Credentials.
Only one layer of mapping is allowed. Different URLs in the certificates can be mapped to the same new URL, but you cannot assign a certificate URL to multiple new URLs. For example, the following mapping list is not valid:
msgCRLMappingRecord=URL12==URL45
msgCRLMappingRecord=URL12==URL66
msgCRLMappingRecord=URL12==URL88
msgCRLMappingRecord=URL20==URL90
msgCRLMappingRecord=URL20==URL93The next example is a correct mapping list:
msgCRLMappingRecord=URL12==URL45
msgCRLMappingRecord=URL14==URL66
msgCRLMappingRecord=URL88==URL66
msgCRLMappingRecord=URL201==URL90
msgCRLMappingRecord=URL202==URL93Once you have created the mapping definitions in your LDAP directory, use crlmappingurl in the smime.conf file to specify the directory information to locate them. See crlmappingurl.
Proxy Server and CRL Checking
If your system uses a proxy server between client applications and the Messaging Server, CRL checking can be blocked despite the fact that you correctly configured the S/MIME applet to perform CRL checking. When this problem occurs, users of Communications Express Mail receive error messages alerting them to revoked or unknown status for valid key certificates.
The following conditions cause the problem:
To solve this problem, you can:
For more information see Securing Internet Links With SSL.
Using a Stale CRL
Checking a certificate against a CRL is done by the Messaging Server after the S/MIME applet sends it a request to do so. Rather than download a CRL to memory each time a certificate is checked, Messaging Server downloads a copy of the CRL to disk and uses that copy for certificate checking. Every CRL has a next-update field which specifies the date after which a newer CRL version should be used. The next-update date can be viewed as an expiration date or time limit for using the CRL. A CRL that is past it’s next-update date is considered old or stale and triggers Messaging Server to download the latest version of the CRL the next time a certificate is checked.
Every time the S/MIME applet requests that a certificate be checked against a CRL, the Messaging Server does the following:
- Compares the current date to the next-update date of the CRL.
- If the CRL is stale, the Messaging Server downloads the latest version of the CRL to replace the stale CRL on disk and checking proceeds. However, if a newer CRL cannot be found or cannot be downloaded, the value of crlusepastnextupdate in the smime.conf file is used to determine what to do.
- If crlusepastnextupdate is set to 0, the stale CRL is not used and the certificate in question has an ambiguous status. The S/MIME applet uses the value of revocationunknown in smime.conf to determine what to do next:
- If revocationunknown is set to ok, the certificate is treated as valid and the private or public key is used to sign or encrypt a message.
- If revocationunknown is set to revoked, the certificate is treated as invalid, the private or public key is not used to sign or encrypt a message, and a pop-up error message alerts the mail user that the key cannot be used.
If crlusepastnextupdate is set to 1, the S/MIME applet continues to use the stale CRL which causes no interruption of processing within Communications Express Mail, however a message is written to the Messaging Server log file to alert you to the situation.
This sequence of events continues to occur as certificates are checked against the CRL. As long as the Messaging Server can download a newer version of the CRL in a timely manner, and depending on the settings in the smime.conf file, mail processing proceeds without interruption. Check the Messaging Server log periodically for repeated messages that indicate a stale CRL is in use. If a newer CRL cannot be downloaded, you need to investigate why it is inaccessible.
Determining Which Message Time to Use
The timestampdelta parameter is used primarily for these purposes:
- To handle the situation of a message that takes a long time to arrive at its destination. For this case, the sender’s key might be treated as an invalid key despite the fact that the key was valid when the message was sent.
- To limit the trust in a message’s sent time because sent times can be faked.
There are two times associated with every message:
Note
View the message header detail by clicking the triangle icon at the right hand side of a message’s From field.
A certificate that was valid when a message was sent can be revoked or expired by the time the message reaches its destination. When this happens, which time should be used when checking the validity of the certificate, the sent time or the received time? Using the sent time would verify that the certificate was valid when the message was sent. But always using the sent time does not take into account the fact that it might take a long time for a message to arrive at its destination, in which case it would be better to use the received time.
You can influence which time to use for CRL checking by using the timestampdelta parameter in the smime.conf file. Set this parameter to a positive integer, representing seconds. If the received time minus the value of timestampdelta is a time before the sent time, the sent time is used. Otherwise, the received time is used. The smaller the value of timestampdelta, the more often the received time is used. When timestampdelta is not set, the received time is always used. See timestampdelta.
Trouble Accessing a CRL
For a variety of reasons, such as network or server problems, a CRL might be unavailable when Messaging Server attempts to check a certificate against it. Rather than let the Messaging Server spend its time constantly trying to gain access to the CRL, you can use the crlaccessfail parameter in the smime.conf file to manage how often it attempts to access the CRL, freeing up the Messaging Server for other tasks.
Define the following with crlaccessfail:
See crlaccessfail for the parameter’s syntax and an example.
When a Certificate is Revoked
When a public key’s certificate does not match any entry on the CRL, the private or public key is used to sign or encrypt an outgoing message. When a certificate matches an entry on the CRL or the certificate’s status is unknown, a private or public key is considered revoked. By default Communications Express Mail does not use a key with a revoked certificate to sign or encrypt an outgoing message. If the private key of a signed message is revoked by the time the recipient reads the message, the recipient receives a warning message indicating that the signature should not be trusted.
If desired, you can change the various default policies for all revoked certificates with the following parameters in the smime.conf file:
- Set sendsigncertrevoked to allow to sign an outgoing message with a private key that is considered revoked because its public key’s certificate is revoked
- Set sendencryptcertrevoked to allow to encrypt an outgoing message with a public key that has a revoked certificate
- Set revocationunknown to ok to treat a certificate as valid whose status is unknown; the private or public key is used to sign or encrypt an outgoing message
Granting Permission to Use S/MIME FeaturesPermission to use the various mail services available through Communications Express Mail can be given or denied with LDAP filters. A filter is defined with the mailAllowedServiceAccess or mailDomainAllowedServiceAccess LDAP attributes. Generally speaking, a filter works in one of three ways:
- Permission to given to all users for all services when no filter is used
- Permission is explicitly given to a list of users for specified service names (a plus sign (+) precedes the service name list)
- Permission is explicitly denied to a list of users for specified service names (a minus sign (-) precedes the service name list)
The required mail service names for S/MIME are http, smime, and smtp. If you need to restrict the use of S/MIME among Communications Express Mail users, use the appropriate LDAP attribute syntax and service names to create a filter. The attributes are created or modified with LDAP commands.
S/MIME Permission Examples
1. The following examples block access to the S/MIME features for one Communications Express Mail user:
mailAllowedServiceAccess: -smime:*$+imap,pop,http,smtp:*
or
mailAllowedServiceAccess: +imap,pop,http,smtp:*
2. The following examples block access to the S/MIME features for all Communications Express Mail users in a domain:
mailDomainAllowedServiceAccess: -smime:*$+imap:*$+pop:*$+smtp:*$+http:*
or
mailDomainAllowedServiceAccess: +imap:*$+pop:*$+smtp:*$+http:*
See Filter Syntax for more information.
Managing CertificatesMost of the following examples use the ldapsearch and ldapmodify commands to search an LDAP directory for user keys and certificates. These commands are provided with Directory Server. See the Sun ONE Directory Server Resource Kit Tools Reference, Release 5.2, for more information about the commands.
CA Certificates in an LDAP Directory
This example adds a certificate for a certificate authority to an LDAP directory. The directory structure for these certificates already exists. The certificate and the LDAP entries where it belongs are entered into an .ldif file named add-root-CA-cert.ldif. All text is entered into the file in ASCII text except for the certificate information, which must be entered as Base64 encoded text:
dn: cn=SMIME Admin,ou=people,o=demo.siroe.com,o=demo
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: certificationAuthority
cn: RootCACerts
sn: CA
authorityRevocationList: novalue
certificateRevocationList: novalue
cacertificate;binary:: MFU01JTUUEjAQBgNVBAsTCU1zZ1NlcnZlcjcMBoGA1UEAxMTydG
QGEwJVUzEOMAwGA1UEMFUJTUUxEjAQBgNVBAsTCU1zZ1NlcnZlcjEMBoGA1UEAxMTQ2VydG
aFw0wNjAxMwODAwMDBaM267hgbX9FExCzAJByrjgNVBAk9STklBMQwCgYDVQQVHR8EgaQwg
YTAlVMRMQYDVQQIEwpDQUxJRk9STklBMQwwCgYDVQQKEwww3ltgYz11lzAdBgNVBpYSE9Vc
5yZWQaddWlm899XBsYW5ldC5jb20wgZ8wDQYJoGBAK1mUTy8vvnOFg4mlHjkghytQUR1k8l
5mvWRf77ntm5mGXRD3XMU4OciUq6zUfIg3ngvxlLyERTIqjUS8HQU4R5pvj+rrVgsAGjggE
+FNAJmtOV2A3wMyghqkVPNDP3Aqq2fkcn4va3C5nRNAYxNNVE84JJ0H3jyPDXhMBlQU6vQn
weMBAAjggEXMIIBEzARBglghkgBhCAQEEBApqlSai4mfuvjh02SQkoPMNDAgTwMB8GA1UdI
QYMBaAEd38IK05AHreiU9OYc6vNMOwZMIGsBgNVHR8EgaQwgaEwb6BtoGuGaWxkYXA6Lyht
bmcucmVkLmlbGFuZXQuY29tL1VJD1DXJ0aWZpY2F0ZSBNYW5hZ2VyLE9VPVBlb3BsZSxPPW
aWxxYT9jZXJ0aZpY2jdu2medXRllkghytQURYFNrkuoCygKoYoaHR0cDovL3Bla2kghytQU
Zy5yZWQuaXBsYW5lC5jb20vcGVranLmNybDAeBgNVHREEFzAVgRNwb3J0aWEuc2hhb0BzdW
4uY29tMA0GCxLm78freCxS3Pp078jyTaDci1AudBL8+RrRUQvxsMJfZeFED+Uuf10Ilt6kw
Tc6W5UekbirfEZGAVQIzlt6DQJfgpifGLvtQ60Kw==The CA’s certificate is added to the LDAP directory with an ldapmodify command:
# ldapmodify -a -h demo.siroe.com -D "cn=Directory Manager" -w mypasswd -v
-f add-root-CA-cert.ldifThe value of the trustedurl parameter in smime.conf specifies the location of the CA certificates in the LDAP directory. For Example 1, trustedurl is set to:
trustedurl==ldap://demo.siroe.com:389/cn=SMIME Admin, ou=people, o=demo.siroe.com,o=demo?cacertificate;binary?sub?(objectclass=certificatio nAuthority)
Public Keys and Certificates in an LDAP Directory
This example demonstrates adding a mail user’s public key and certificate to the LDAP directory. It assumes the mail user already exists in the LDAP directory. The key and certificate, and the LDAP entries where it belongs, are entered into an .ldif file named add-public-cert.ldif. All text is entered into the file as ASCII text except for the key and certificate information, which must be entered as Base64 encoded text.
dn: uid=JohnDoe,ou=People, o=demo.siroe.com,o=demo
changetype: modify
replace: usercertificate
usercertificate;binary:: MFU01JTUUxEjAQBgNVBAsT1zZ1NlcnZlcjMBoGA1UEAxMTydG
QGEwJVUzEAwGA1hMFU01JTUUxEjAQBgNVBAsTCU1zZ1NlcnZlcjEcMBoGA1UEAxMTQ2VydG
aFw0wNjAxMTODAwaM267hgbX9FExCzAJBgwyrjgNVBAk9STklBMQwwCgYDVQQVHR8EgaQwg
AlVzMRMwEQYDVQQIDQUxJRk9STklBMQwwCgYDVQQKEwww3ltgoOYz11lzAdBgNVBpYSE9Vc
5yZWaddiiWlm899XBsYW5ldb20wgZ8wDQYJoGBAK1mUTy8vvO2nOFg4mlHjkghytQUR1k8l
5mvgcWL77ntm5mGXRD3XMU4OcizUfIg3ngvxlLKLyERTIqjUS8HQU4R5pvj+rrVgsAGjggE
+FG9NAqtOV2A3wMyghqkVPNDP3Aqq2BYfkcn4va3RNAYxNNVE84JJ0H3jyPDXhMBlQU6vQn
1NAgMBGjggEXMIIBEzARBglghkgBhvhCAQEEBApqlSai4mfuvjh02SQMNDAgTwMB8GA1UdI
QYMBaEd38IK05AHreiU9OYc6v+ENMOwZMIGsBgNVHR8EgaQwgaEwb6BuGaWxkYXA6Lyht74
tpbmcmVkLmlwbGFuZXQuY29tL1VJRD1DZXJ0aWZpY2F0ZSBNYW5hZ2V9VPVBlb3BsZSxPPW
1haWxT9jZXJ0aWZpY2jdu2medXRllHjkghytQURYFNrkuoCygKoYoaHDovL3Bla2kghytQU
luZy5WQuaXBsYW5ldC5jb20vcGVraW5nLmNybDAeBgNVHREEFzAVgRNw0aWEuc2hhb0BzdW
4uY29A0GCxLm78UfreCxS3Pp078jyTaDv2ci1AudBL8+RrRUQvxsMJfZD+Uuf10Ilt6kwhm
Tc6W5UekbirfEZGAVQIzlt6DQJfgpifGLvtQ60Kw==The ldapmodify command is used to add the public key and certificate to the LDAP directory:
# ldapmodify -a -h demo.siroe.com -D "cn=Directory Manager" -w mypasswd -v
-f add-public-cert.ldifThe value of the certurl parameter in smime.conf specifies the location of the public keys and their certificates in the LDAP directory. For Example 2, certurl is set to:
certurl==ldap://demo.siroe.com:389/ou=people, o=demo.siroe.com, o=demo?userCertificate;binary?sub?
Verifying That Keys and Certificates Exist in the LDAP Directory
The following examples demonstrate searching an LDAP directory for CA certificates and public keys and their certificates.
Searching for One CA Certificate
In the following example, the base DN defined by the -b option, cn=SMIME admin, ou=people,o=demo.siroe.com,o=demo objectclass=*, describes one CA certificate in the LDAP directory. If found in the directory, ldapsearch returns information about the certificate to the ca-cert.lidf file.
# ldapsearch -L -h demo.siroe.com -D "cn=Directory Manager" -w mypasswd
-b "cn=SMIME admin, ou=people,o=demo.siroe.com,o=demo"
"objectclass=*" > ca-cert.ldifThe example below shows the search results in the ca-cert.ldif file. The format of the file’s contents is a result of using the -L option of ldapsearch.
# more ca-cert.ldif
dn: cn=SMIME admin,ou=people,o=demo.siroe.com,o=demo
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: certificationAuthority
cn: RootCACerts
cn: SMIME admin
sn: CA
authorityRevocationList: novalue
certificateRevocationList: novalue
cacertificate;binary:: MFU01JTUUxEjAQBgNVBAsTCU1zZNlcnZlcjcMBoGA1UEAxMTydGQGEwJVEOMAwGA1UEChMFU0UUxEjAQBgNVBAsTCU1zZ1NlcnZlcjEcMBoGA1UEAxMTQ2VydG
aFw0jAxMTIwODAwMDBaM267X9FExCzAJBgwyrjgNVBAk9STklBMQwwCgYDVQQVHR8EgaQwg
YlVzMRMwEQYDVQQIEwpDQUx9STklBMQwwCgYDVQQKEwww3ltgoOYz11lzAdBgNVBpYSE9Vc
5yQuaddiiWlm899XBsYW5ljb20wgZ8wDQYJoGBAK1mUTy8vvO2nOFg4mlHjkghytQUR1k8l
5mcWRfL77ntm5mGXRD3XMciUq6zUfIg3ngvxlLKLyERTIqjUS8HQU4R5pvj+rrVgsAGjggE
+FNAJmqtOV2A3wMyghqkDP3Aqq2BYfkcn4va3C5nRNAYxNNVE84JJ0H3jyPDXhMBlQU6vQn
1NABAAGjggEXMIIBEzglghkgBhvhCAQEEBApqlSai4mfuvjh02SQkoPMNDAgTwMB8GA1UdI
QYMAFEd38IK05AHreOYc6v+ENMOwZMIGsBgNVHR8EgaQwgaEwb6BtoGuGaWxkYXA6Lyht74
tpbucmVkLmlwbGFuZY29tL1VJRD1DZXJ0aWZpY2F0ZSBNYW5hZ2VyLE9VPVBlb3BsZSxPPW
1haWYT9jZXJ0aWZpdu2medXRllHjkghytQURYFNrkuoCygKoYoaHR0cDovL3Bla2kghytQU
luZyZWQuaXBsYW5ldb20vcGVraW5nLmNybDAeBgNVHREEFzAVgRNwb3J0aWEuc2hhb0BzdW
4uYtMA0GCxLm78Ufre3Pp078jyTaDv2ci1AudBL8+RrRUQvxsMJfZeFED+Uuf10Ilt6kwhm
Tc6W5UekbirfEZGAVQIzlt6DQJfgpifGLvtQ60Kw==Searching for a Several Public Keys
In the following example, the base DN defined by the -b option, o=demo.siroe.com,o=demo objectclass=*, is such that all public keys and certificates found at and below the base DN in the LDAP directory are returned to the file usergroup.ldif:
# ldapsearch -L -h demo.siroe.com -D "cn=Directory Manager" -w mypasswd
-b "o=demo.siroe.com,o=demo" "objectclass=*" > usergroup.ldifSearching for One Public Key
In the following example, the base DN defined by the -b option, uid=JohnDoe, ou=people,o=demo.siroe.com,o=demo objectclass=*, describes one public key and its certificate in the LDAP directory:
# ldapsearch -L -h demo.siroe.com -D "cn=Directory Manager" -w mypasswd
-b "uid=JohnDoe, ou=people,o=demo.siroe.com,o=demo" "objectclass=*" > public-key.ldifThe example below shows the search results in the public-key.ldif file. The format of the file’s contents is the result of using the -L option of ldapsearch.
# more public-key.ldif
dn: uid=sdemo1, ou=people, o=demo.siroe.com, o=demo
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: siroe-am-managed-person
objectClass: inetOrgPerson
objectClass: inetUser
objectClass: ipUser
objectClass: userPresenceProfile
objectClass: inetMailUser
objectClass: inetLocalMailRecipient
objectClass: icsCalendarUser
objectClass: sunUCPreferences
mail: JohnDoe@demo.siroe.com
mailHost: demo.siroe.com
..
uid: JohnDoe
..
mailUserStatus: active
inetUserStatus: active
..
usercertificate;binary:: MFU01JTUUxEjAQBgNBAsTCU1zZ1NlcnZjcMBoGA1UEAxMTydG
QGEwJEOwGA1UEChMFU01JTUUxEjAQBgNVBAsTCU1zZ1NlcnZlcjEcMBoGA1UEAxMTQ2VydG
aFw0MTIwODAwMDBaM267hgbX9FExCzAJBgwyrjgNVBAk9STklBMQwwCgYDVQQVHR8EgaQwg
YTAlVEQYDVQQIEwpDQUxJRk9STklBMQwwCgYDVQQKEwww3ltgoOYz11lzAdBgNVBpYSE9Vc
5yZWQdWlm899XBsYW5ldC5jb20wgZ8wDQYJoGBAK1mUTy8vvO2nOFg4mlHjkghytQUR1k8l
5mvgc7ntm5mGXRD3XMU4OciUq6zUfIg3ngvxlLKLyERTIqjUS8HQU4R5pvj+rrVgsAGjggE
+FG9NmV2A3wMyghqkVPNDP3Aqq2BYfkcn4va3C5nRNAYxNNVE84JJ0H3jyPDXhMBlQU6vQn
1NAgMAgEXMIIBEzARBglghkgBhvhCAQEEBApqlSai4mfuvjh02SQkoPMNDAgTwMB8GA1UdI
QYMBaEdK05AHreiU9OYc6v+ENMOwZMIGsBgNVHR8EgaQwgaEwb6BtoGuGaWxkYXA6Lyht74
tpbucmVkwbGFuZXQuY29tL1VJRD1DZXJ0aWZpY2F0ZSBNYW5hZ2VyLE9VPVBlb3BsZSxPPW
1haxYT9jZaWZpY2jdu2medXRllHjkghytQURYFNrkuoCygKoYoaHR0cDovL3Bla2kghytQU
luZyZWQuaYW5ldC5jb20vcGVraW5nLmNybDAeBgNVHREEFzAVgRNwb3J0aWEuc2hhb0BzdW
4u9tMA0GC78UfreCxS3Pp078jyTaDv2ci1AudBL8+RrRUQvxsMJfZeFED+Uuf10Ilt6kwhm
Tc6W5UekbirfEZGAVQIzlt6DQJfgpifGLvtQ60Kw==.
.
Network Security Services Certificates
Various certificates used for Network Security Services (NSS) are stored in their own database, which is not an LDAP database.Two utilities, certutil and crlutil, are provided with Messaging Server to store the certificates and associated CRLs in the database. You can also use these utilities to search the database.
See the Sun Java System Directory Server Administration Guide (http://docs.sun.com/doc/817-7613) for more information about certutil. Use the help text that comes with crlutil for more information about that utility (view the online help of both utilities by executing them without arguments).
Communications Express S/MIME End User InformationThis section consists of information intended for the end user. It contains the following subsections:
Logging In for the First Time
When mail users log in to Communications Express Mail for the first time, they encounter special prompts relating to the S/MIME applet.
Prompts for Windows
When logging in to Communications Express Mail for the first time on Windows 98, 2000 or XP, the following prompts display:
- If the Java 2 Runtime Environment (JRE) is not installed on your computer (client machine), you receive a prompt looking something like this:
Do you want to install and run “Java Plug-in 1.4.2_03 signed on 11/20/03 and distributed by Sun Microsystems, Inc.”?
Publisher authenticity verified by: VeriSign Class 3 Code Signing 2001 CAClick Yes and follow the subsequent prompts to install JRE.
Note
If you desire English language support and also want to read incoming S/MIME messages that contain non-Latin characters, such as Chinese, the charsets.jar file must be in the /lib directory on your computer.
To ensure that the charsets.jar file is installed in the /lib directory, use the custom installation to install the English version of JRE. During the installation process, select the “Support for Additional Languages” option.
See Multi-language Support for more information.
Click Finish at the last installation prompt. Restart your computer and log in to Communications Express Mail again.
- A prompt asking you:
Do you want to trust the signed applet distributed by “Sun Microsystems, Inc.”?
Publisher authenticity verified by: Thawte Consulting ccClick one of the following responses:
- Yes, to accept the S/MIME applet for this Communications Express Mail session. The prompt displays each time you log in.
- No, to reject the S/MIME applet. You cannot use the S/MIME features.
- Always, to accept the S/MIME applet for this and all subsequent Communications Express Mail sessions. You will not see the prompt again.
- A prompt asking you:
Do you want to trust the signed applet distributed by “sun microsystems, inc.”?
Publisher authenticity verified by: VeriSign, Inc.Click one of the following responses:
- Yes, to accept the S/MIME applet for this Communications Express Mail session. The prompt displays each time you log in.
- No, to reject the S/MIME applet. You cannot use the S/MIME features.
- Always, to accept the S/MIME applet for this and all subsequent Communications Express Mail sessions. You will not see the prompt again.
Signature and Encryption Settings
There are initial signature and encryption settings that you can set to control whether all users’ outgoing messages are:
The initial settings also control whether the signature and encryption checkboxes located at the bottom of a Communications Express Mail window and in the Options - Settings window are displayed as checked (feature turned on) or unchecked (feature turned off). Use the alwaysencrypt and alwayssign parameters in the smime.conf file to specify the initial settings.
Let your mail users know that they can change the initial settings for their mail messages. After they log in to Communications Express Mail, a user can temporarily override a setting for one message, or for all their messages on an on-going basis.
Table 20-6 summarizes the use of the checkboxes.
Enabling the Java Console
A variety of operating messages can be written to the Java Console by the S/MIME applet as a Communications Express Mail user processes signed and encrypted messages. The Java Console messages can be helpful when troubleshooting a problem reported by a mail user. However, operating messages are only generated when the Java Console is enabled for the user by adding a nswmExtendedUserPrefs attribute to the inetMailUser object class of their LDAP entry. For example:
nswmExtendedUserPrefs: meSMIMEDebug=on
Do not enable the Java Console for all mail users all the time because this significantly decreases the performance of Communications Express Mail.
