test

Sun Java System Messaging Server 6.3 Administration Guide

24.9 Verifying Private and Public Keys

Before Communications Express Mail uses a private or public key, it must pass the verification tests shown in Figure 24–2. The remainder of this section describes the details of checking a public key’s certificate against a CRL.

Figure 24–2 Verifying Private and Public Keys.

Graphics shows a flowchart for verifying private and public keys.

24.9.1 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 usercerfilter in 24.5 Parameters of the smime.conf File for more information.

24.9.2 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:

24.9.3 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 in Table 24–3) 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 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 24.4.3 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==URL93

The next example is a correct mapping list:

msgCRLMappingRecord=URL12==URL45
msgCRLMappingRecord=URL14==URL66
msgCRLMappingRecord=URL88==URL66
msgCRLMappingRecord=URL201==URL90
msgCRLMappingRecord=URL202==URL93

Once 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 24.5 Parameters of the smime.conf File.

24.9.4 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:

  1. Set up the communications link between the client machines and proxy server as a secured link with SSL and leave all the configuration values as they are. Or,

  2. Leave the communications link unsecured and set checkoverssl to 0.

For more information see 24.7 Securing Internet Links With SSL.

24.9.5 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:

  1. Compares the current date to the next-update date of the CRL.

  2. 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.

  3. 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:

    1. 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.

    2. 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.

24.9.6 Determining Which Message Time to Use

The timestampdelta parameter is used primarily for these purposes:

  1. 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.

  2. 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 in Table 24–3.

24.9.7 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 in Table 24–3 for the parameter’s syntax and an example.

24.9.8 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: