Supporting Outlook Web Access with the S/MIME Control in Your PKI
In an Exchange 2003-based message security system, most S/MIME functionality is the result of interaction between the e-mail clients and the PKI. As a PKI administrator, your primary source of information for configuration options and requirements is the documentation for your specific PKI. In addition, you should consult with the e-mail client administrator for information related to PKI requirements to support your specific e-mail clients.
Exchange 2003 provides S/MIME e-mail client functionality with Outlook Web Access using the S/MIME control. This section provides PKI administrators with information for integrating their PKI with Outlook Web Access using the S/MIME control.
Outlook Web Access and Digital Certificates
This section details how Outlook Web Access with the S/MIME control interacts with digital certificates in the following areas:
Certificate handling in Outlook Web Access with the S/MIME control.
Outlook Web Access with the S/MIME control and retrieval of digital certificates.
Outlook Web Access with the S/MIME control and certificate validation.
Outlook Web Access with the S/MIME control and S/MIME operations.
Outlook Web Access with the S/MIME control and smart cards.
Outlook Web Access with the S/MIME control and S/MIME encryption capabilities.
Certificate Handling in Outlook Web Access with the S/MIME Control
The user's Exchange server provides digital certificate validation for all certificates. When using Outlook Web Access with the S/MIME control, the user's Exchange server also performs most certificate handling related to public keys. However, when handling digital certificates related to the user's private keys, the S/MIME control on the user's client system obtains the digital certificate that is stored on the user's client system.
Having the user's Exchange server handle all digital certificate validation operations reduces the amount of traffic that must pass between the client system and the Exchange server and results in better performance. Certificate management is simplified, because only the user's Exchange server has to be configured to support certificate validation. Because the client system only provides certificate storage, there are no requirements for enabling certificate handling on the client system. Having the client system store the digital certificate with the user's private key ensures that the user's private key is never sent across the network. Outlook Web Access with the S/MIME control has no direct handling of the private key. Instead, all private key handling is performed by the operating system. Outlook Web Access with the S/MIME control interacts with the cryptographic capabilities of the operating system. The following figure shows the architecture of Outlook Web Access with the S/MIME control.
Outlook Web Access with the S/MIME control architecture
.gif "e3fc5d17-8881-4073-a552-9fe22b043348")
As shown in this figure, certificate processing when using Outlook Web Access with the S/MIME control is a series of operations with clear and discrete ownership. The user's Exchange server handles all certificate validation processing and obtains most digital certificates for public keys, while the user's client system stores any digital certificates with private keys.
The user's Exchange server relies on the certificate store of the underlying operating system for all certificate handling functions, using the Personal certificate store for the LocalSystem account on the user's Exchange server. The personal certificate store is the CryptoAPI My store in the user profile. Because Exchange 2003 requires either Microsoft Windows® 2000 Server or Windows Server 2003, both of which provide the Personal certificate store, there are no special operating system requirements to support Outlook Web Access with the S/MIME control on the Exchange server.
Outlook Web Access with the S/MIME control has the following requirements:
Windows 2000 or later (to provide the Personal certificate store capabilities for storing digital certificates with private keys).
Internet Explorer 6 or later (to take advantage of security enhancements).
Although versions of Windows prior to Windows 2000 and browsers other than Internet Explorer 6 or later cannot be used with Outlook Web Access with the S/MIME control, they can be used with Outlook Web Access without the S/MIME control.
Outlook Web Access with the S/MIME Control and Retrieval of Digital Certificates
Although the user's Exchange server relies on Windows 2000 or later to handle certificate validation, it retrieves digital certificates for most public keys. Outlook Web Access with the S/MIME control retrieves digital certificates for private keys on the user's client system.
Certificate Searching with Outlook Web Access with the S/MIME Control
When using Outlook Web Access with the S/MIME control, both it and the user's Exchange server search for and match certificates based on the following criteria:
Match the e-mail message routing addresses with those found in the certificate The user's Exchange server or Outlook Web Access with the S/MIME control attempts to match the e-mail message routing addresses with those found in the certificate. An attempt is made to match the e-mail message routing addresses with the certificate subject. If a match cannot be found, an attempt is made to match the e-mail message routing addresses with the subject alternative name. If the e-mail message routing addresses cannot be matched, an attempt is made to match the e-mail message routing addresses based on Simple Mail Transfer Protocol (SMTP) proxy addresses in the directory. Searching for SMTP proxy addresses can be disabled by setting the CertMatchingDoNotUseProxies value in the registry.
Note
For more information, see Outlook Web Access S/MIME Control-Related Settings.
Determine the certificates' capabilities If multiple certificates for the subject are located, each certificate's key usage is reviewed to determine what capabilities the certificates have, including digital signing, message encryption, or both. If a certificate that has a single key usage that matches the current operation is found, that certificate will be chosen over other certificates with multiple key usages. For example, if the current operation is a digital signature, and two certificates are located, one certificate with a key usage for digital signatures only and another certificate with key usages for digital signatures and encryption, the certificate with the key usage for digital signature only will be selected.
Select certificates based on start and expiration dates Only digital certificates that are valid based on their start dates and expiration dates will be selected.
Examine digital certificates propagated from smart cards When retrieving the user's private keys, if the SmartCardOnly value has been set on the user's Exchange server, only digital certificates propagated from smart cards will be examined.
Note
For more information, see Outlook Web Access S/MIME Control-Related Settings.
After a digital certificate has been obtained, the full trust list for the certificate is checked.
Obtaining Digital Certificates for Public Keys
When validating a digital signature, the S/MIME control retrieves the digital certificate included with the signed message and uses that certificate for validation.
When retrieving digital certificates to obtain public keys from a directory for sending encrypted messages, the user's Exchange server looks in sequence at the following places until it finds a valid digital certificate for the operation requested. As soon as a valid certificate is found, that certificate is used and the processing halts.
The userCertificate attribute in the other user's object in Active Directory.
The userSMIMECertificate attribute in the other user's object in Active Directory.
The userCertificate attribute in the other user's contact object in Active Directory (located in the Contacts folder in the user's Inbox on the Exchange server).
The userSMIMECertificate attribute in the other user's contact object in Active Directory (located in the Contacts folder in the user's Inbox on the Exchange server).
Note
Although Outlook Web Access can use a digital certificate that is attached to an item in the Contacts folder in Exchange, you cannot add a digital certificate to an item in the Contacts folder using Outlook Web Access. Instead, you must use Outlook to add a digital certificate to a contact.
If the user's Exchange server is unable to locate a certificate for another user's public key in any of these locations, a warning is raised. When attempting to send an encrypted e-mail message, the sender has the option either to send the message unencrypted or to send the message encrypted with the warning that some users may be unable to read the message.
Obtaining Digital Certificates for User's Private Keys
When choosing a digital certificate to obtain the user's private key, Outlook Web Access with the S/MIME control looks in the Personal certificate store of the current logged on user. Outlook Web Access with the S/MIME control searches through the available certificates in the certificate store until it finds a valid digital certificate for the operation requested. Outlook Web Access with the S/MIME control always uses hardware-based digital certificates, including smart cards, if both a software-based certificate and a hardware-based certificate are located. Note that, if the SmartCardOnly value has been set on the user's Exchange server, only digital certificates propagated from smart cards will be examined.
If Outlook Web Access with the S/MIME control is unable to locate a certificate for the user's private key, a warning is raised. When attempting to read an encrypted e-mail message, the recipient is unable to decrypt and display the message. When sending a signed e-mail message, Outlook Web Access displays a warning message.
Note
When using hardware-based certificates, users must activate the device to make the certificate available. For example, when using smart cards, the smart card must be inserted into a reader and a Personal Identification Number (PIN) must be entered before the certificate will be available for use.
Outlook Web Access with the S/MIME Control and Certificate Validation
Selecting a digital certificate includes determining whether an available digital certificate is valid. The user's Exchange server relies on the certificate handling capabilities of the underlying Windows operating system to perform certificate validation. A detailed overview of the process of certificate checking is available in Troubleshooting Certificate Status and Revocation. When the PKI administrator looks at certificate checking in Outlook Web Access with the S/MIME control, the following should be considered:
Time validity verification (performed on all certificates).
Certificate revocation check (performed unless certificate revocation list (CRL) checking has been disabled through the DisableCRLCheck registry setting).
Trust verification (performed if the certification authority [CA] that issued the certificate is not present in the certificate store of the system that has retrieved the certificate).
Time Validity Verification
When a CA creates a certificate, the certificate is marked with a validity period. The validity period is specified by the Valid from and Valid to attributes on the certificate. Together, these attributes provide a time window in which the certificate is valid.
When a digital certificate is retrieved for use, the user's Exchange server verifies that the current date falls within the time frame specified by the Valid from and Valid to attributes. If the certificate has expired because the current date is later than the Valid to date, or the certificate is not yet valid because the date is earlier than the Valid from attribute, Outlook Web Access displays a warning that the certificate it not valid.
Certificate Revocation Check
A CRL is a list of certificates that are currently valid in terms of time validity, but are rendered invalid by the CA. The CA makes this list available through CRL distribution points, which is a location specified in the digital certificate. This list can be obtained through HTTP, Lightweight Directory Access Protocol (LDAP), or other means by systems that need to validate digital certificates from that PKI.
Using CRLs, PKI administrators can render certificates invalid before their window of time validity has expired. This revocation is done where the certificate has been compromised (such as through the loss or disclosure of the certificate holder's private key) or because the issuer can no longer vouch for the certificate holder (such as through termination of employment).
In accordance with the X.509 specification, any S/MIME e-mail client can check a digital certificate for revocation. One method to perform this check is with a CRL issued by the PKI. The user's Exchange server performs CRL checking by using the cryptographic capabilities of the Windows 2000 or later operating system. By default, CRL checking is enabled for Outlook Web Access with the S/MIME control, but can be disabled by setting the DisableCRLCheck value on the user's Exchange server to True. For more information, see Outlook Web Access S/MIME Control-Related Settings.
Because the process of retrieving a CRL can be time consuming, after a system obtains a CRL from a PKI, it caches that CRL until the CRL expires. In addition, Exchange administrators can configure the length of time allowed for retrieving CRLs before returning an error through the RevocationURLRetrievalTimeout and CertURLRetrievalTimeout registry settings. For more information, see Outlook Web Access S/MIME Control-Related Settings.
After the user's Exchange server obtains a digital certificate and has verified its time validity, the following sequence occurs.
The Exchange server attempts to verify the certificate against the CRL. The user's Exchange server checks to see if CRL checking is enabled for this certificate.
If CRL checking is enabled, the Exchange server attempts to locate a cached copy of the CRL.
If the Exchange server cannot locate a cached copy of the CRL, it attempts to contact the CRL distribution point and obtain an updated CRL.
If the Exchange server cannot obtain a CRL, it takes action depending on the CheckCRL registry setting. By default, Outlook Web Access does not raise an error and allows the message to be sent.
If the CheckCRL registry setting has been changed from the default, Outlook Web Access raises an error but allows the message to be sent. For more information about the CheckCRL registry setting, see Outlook Web Access S/MIME Control-Related Settings.
If the user's Exchange server can obtain the CRL or locates a cached copy of the CRL, the current certificate is checked against the CRL.
If the certificate is found on the CRL, it is marked as invalid and is not used.
If the certificate is not found on the CRL, it is presumed to be valid and is used.
Trust Verification
Trust verification is performed on all digital certificates. The user's Exchange server invokes the cryptographic capabilities of the operating system to attempt to validate the certificate by validating each certificate in the certificate chain until it reaches a trusted root certificate. In most cases, this is done by obtaining the intermediate certificates through the authority information access path in the certificate until a trusted root certificate is located. Intermediate certificates can also be included with digitally signed e-mail messages. If the system locates a trusted root certificate, the digital certificate's chain for that digital certificate is considered valid and trusted and can be used.
If the system fails to locate a trusted root certificate, or if the digital certificate that was initially obtained is located in the Untrusted certificates store of the Exchange server, that certificate is considered invalid and not trusted. Outlook Web Access with the S/MIME control will raise an error when attempting to use this untrusted digital certificate.
As a PKI administrator, you may choose to trust digital certificates issued by other PKIs to prevent errors that occur when using digital certificates issued by PKIs whose root certificate is not trusted. You can choose to trust the root certificate of the other PKI, but that would implicitly trust every certificate issued by that PKI. As an alternative, you could choose a strategy of cross-certification to trust only a selected set of certificates from this other PKI.
For information about the risks and benefits of each approach and how to implement cross-certification in your PKI, consult your PKI documentation. For information about cross-certification in Windows Server 2003, see Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003. In general, a strategy of cross-certification is recommended.
Regardless of the specific strategy you choose, you will need to ensure that the appropriate root certificates are available on the Exchange server to enable trust validation. These root certificates can be added manually or propagated using Group Policy. It is recommended that you use Group Policy whenever possible.
For information about using Group Policy to propagate digital certificates, see the Windows Server 2003 documentation. For information about steps to manually add digital certificates to a user's system, see Troubleshooting S/MIME in Exchange Server 2003.
After a digital certificate is checked for time validity against the CRL, and its trust is verified, it is recognized by the Exchange server as a valid certificate and can be used for digital signatures and encryption, depending on the purposes for which the certificate was issued.
Outlook Web Access with the S/MIME Control and S/MIME Operations
The following S/MIME operations are discussed in this section:
Digital signatures in Outlook Web Access with the S/MIME control.
Encryption operations in Outlook Web Access with the S/MIME control.
Digital signatures and encryption in Outlook Web Access with the S/MIME control.
Digital Signatures in Outlook Web Access with the S/MIME Control
The following operations are discussed in this section:
Sending a digitally signed e-mail message.
Validating a digitally signed e-mail message.
Sending a Digitally Signed E-Mail Message
In sending a digitally signed e-mail message, Outlook Web Access must obtain the sender's private key. The client system that is running Outlook Web Access (rather than the user's Exchange server) is responsible for obtaining the digital certificate and private key.
Note
This sequence describes messages that are clear signed, which is the default behavior for Outlook Web Access with the S/MIME control. This behavior is controlled by the ClearSign registry setting on the sender's Exchange server. By default, this setting is enabled. For information about the ClearSign registry setting, see Outlook Web Access S/MIME Control-Related Settings.
When sending a digitally signed e-mail message, the following sequence occurs.
Message is captured (performed by client system).
Hash value of the message is calculated using the algorithm specified by the defaultSigningAlgorithms key (performed by client system and user's Exchange server).
For more details on the defaultSigningAlgorithms registry setting, see Outlook Web Access S/MIME Control-Related Settings.
Sender's digital certificate private key is retrieved (performed by client system).
Sender's digital certificate is verified (performed by user's Exchange server).
Hash value is encrypted with the sender's private key (performed by client system and user's Exchange server).
Encrypted hash value is appended to the message as a digital signature (performed by client system).
Message is sent (performed by client system).
Validating a Digitally Signed E-Mail Message
In validating a digitally signed e-mail message, Outlook Web Access must obtain the sender's public key. The recipient's Exchange server is responsible for obtaining the digital certificate and public key.
When validating a digitally signed e-mail message, the following sequence occurs.
Message is received (performed by user's Exchange server).
Digital signature containing the encrypted hash value is retrieved from the message (performed by client system).
Message is retrieved (performed by client system).
Hash value of the message is calculated (performed by client system and user's Exchange server).
Sender's public key is retrieved from the e-mail message (performed by client system).
Encrypted hash value is decrypted with the sender's public key (performed by client system).
Decrypted hash value is compared against the hash value produced on receipt (performed by client system).
If the values match, the message has not been modified while in transit (performed by client system).
Sender's digital certificate is verified (performed by user's Exchange server).
Note
The message is displayed while the certificate is validated to improve the performance of reading digitally signed e-mail messages.
Encryption Operations in Outlook Web Access with the S/MIME Control
The following operations are discussed in this section:
Sending an encrypted e-mail message.
Viewing an encrypted e-mail message.
Sending an Encrypted E-Mail Message
In sending an encrypted e-mail message, Outlook Web Access must obtain the recipient's public key. The sender's Exchange server is responsible for obtaining the digital certificate and public key.
When sending an encrypted e-mail message, the following sequence occurs.
Message is captured (performed by client system).
Public key is retrieved from the recipient's digital certificate (performed by user's Exchange server).
Recipient's digital certificate is verified (performed by user's Exchange server).
One-time symmetric session key is generated (performed by client system).
Encryption operation is performed on the message using the session key (performed by client system).
Session key is encrypted using the recipient's public key (performed by client system).
Encrypted session key is included with the encrypted message (performed by client system).
Message is sent (performed by client system).
Viewing an Encrypted E-Mail Message
In viewing an encrypted e-mail message, Outlook Web Access must obtain the recipient's private key. The client system that is running Outlook Web Access (rather than the user's Exchange server) is responsible for obtaining the digital certificate and private key.
When viewing an encrypted e-mail message, the following sequence occurs.
Message is received (performed by user's Exchange server).
Encrypted message and encrypted session key are retrieved from the message (performed by client system).
Recipient's digital certificate private key is retrieved (performed by client system).
Session key is decrypted with the recipient's digital certificate private key (performed by client system).
Message is decrypted with the decrypted session key (performed by client system).
Unencrypted message is returned to the recipient (performed by client system).
Digital Signatures and Encryption in Outlook Web Access with the S/MIME Control
The following operations are examined:
Sending a digitally signed and encrypted e-mail message.
Viewing a digitally signed and encrypted e-mail message.
Sending a Digitally Signed and Encrypted E-Mail Message
In sending a digitally signed and encrypted e-mail message, Outlook Web Access must obtain both the sender's private key and the recipient's public key. The client system that is running Outlook Web Access (rather than the user's Exchange server) obtains the sender's digital certificate and private key. The sender's Exchange server obtains the recipient's digital certificate and public key.
When sending a digitally signed and encrypted e-mail message, the following sequence occurs.
Note
This sequence describes messages where the message is signed, encrypted, and then signed again. This process is referred to as "triple wrapped," which is the default behavior for Outlook Web Access with the S/MIME control. This behavior is controlled by the TripleWrap registry setting on the sender's Exchange server. By default, this setting is enabled. For information about the TripleWrap registry setting, see Outlook Web Access S/MIME Control-Related Settings.
Message is captured (performed by client system).
Hash value of the message is calculated (performed by client system).
Sender's digital certificate private key is retrieved (performed by client system).
Sender's digital certificate is verified (performed by user's Exchange server).
Public key is retrieved from the recipient's digital certificate (performed by user's Exchange server).
Recipient's digital certificate is verified (performed by user's Exchange server).
Hash value is encrypted with the sender's private key (performed by client system).
Encrypted hash value is appended to the message as a digital signature (performed by client system and user's Exchange server).
One-time symmetric session key is generated (performed by client system).
Encryption operation is performed on the message using the session key (performed by client system).
Session key is encrypted using the recipient's public key (performed by client system).
Encrypted session key is included with the encrypted message (performed by user's Exchange server).
Hash value of the message with the encrypted session key is calculated (performed by client system).
Hash value is encrypted with the sender's private key (performed by client system).
Encrypted hash value is appended to the message as a digital signature (performed by client system and user's Exchange server).
Message is sent (performed by client system).
Viewing a Digitally Signed and Encrypted E-Mail Message
In viewing a digitally signed and encrypted e-mail message, Outlook Web Access must obtain both the recipient's private key to display the message and the sender's public key to verify the signature on the message. The client system that is running Outlook Web Access (rather than the user's Exchange server) obtains the recipient's digital certificate and private key. The user's Exchange server obtains the sender's digital certificate and public key.
When sending a digitally signed and encrypted e-mail message, the following sequence occurs.
Note
This sequence describes messages that have been triple wrapped, which is the default behavior for Outlook Web Access with the S/MIME control. This behavior is controlled by the TripleWrap registry setting on the sender's Exchange server. By default, this setting is enabled. For information about the TripleWrap registry setting, see Outlook Web Access S/MIME Control-Related Settings.
Message is received (performed by user's Exchange server).
Digital signature containing the encrypted hash value of the message with the encrypted session key is retrieved from the message (performed by client system).
Message and encrypted session key is retrieved from the message (performed by client system).
Hash value of the message and the encrypted session key is calculated (performed by client system).
Sender's public key is retrieved from the message (performed by user's Exchange server).
Encrypted hash value of the message with the encrypted session key is decrypted with the sender's public key (performed by client system).
Decrypted hash value of the message with the encrypted session key is compared against the hash value of the message with the encrypted session key produced on receipt (performed by client system).
If the values match, the message has not been modified while in transit (performed by client system).
Encrypted message and encrypted session key are retrieved from the message (performed by client system).
Recipient's digital certificate private key is retrieved (performed by client system).
Session key is decrypted with the recipient's digital certificate private key (performed by client system).
Message is decrypted with the decrypted session key (performed by client system).
Digital signature containing the encrypted hash value is retrieved from the message (performed by client system).
Hash value of the message is calculated (performed by client system).
Encrypted hash value is decrypted with the sender's public key (performed by client system).
Decrypted hash value is compared against the hash value produced on receipt (performed by client system).
If the values match, the message has not been modified while in transit (performed by client system).
Unencrypted message is returned to the recipient (performed by client system).
Sender's digital certificate is verified (performed by user's Exchange server).
Note
The message is displayed while the certificate is validated to improve the performance of reading digitally signed e-mail messages.
Outlook Web Access with the S/MIME Control and Smart Cards
PKI administrators can use their smart cards to store user digital certificates and private keys with Outlook Web Access with the S/MIME control. Smart cards are preferred for Outlook Web Access with the S/MIME control on multiple client systems.
Because Outlook Web Access with the S/MIME control relies on the a Windows 2000 or later operating system, digital certificate support for smart cards is directly tied to the support provided by the operating system. When you implement support for smart cards in your PKI, consult your Windows 2000 or later documentation. The following information is specific for integrating smart card support with Outlook Web Access with the S/MIME control. This information augments your PKI documentation and the Windows 2000 or later documentation.
How Outlook Web Access with the S/MIME Control Works with Smart Cards
Support for smart cards in Outlook Web Access with the S/MIME control is provided by the operating system on which the client is running. The operating system integrates smart cards seamlessly into its certificate handling capabilities so that Outlook Web Access does not need to handle or manage these certificates. Outlook Web Access with the S/MIME control monitors the smart card for any changes and instructs the operating system when to move additional digital certificates from the smart card into the Personal certificate store, and removes these certificates when the user logs off Outlook Web Access.
Smart cards make digital certificates available by copying the certificate into the Personal certificate store when a smart card is inserted and the digital certificate is unlocked with the user's private key. This places the digital certificate in the same location as when software-based certificates are used. Applications do not need to take any special actions to use smart card-based digital certificates, because the Windows operating system handles all operations specific to smart card-based certificates.
When using smart cards with Outlook Web Access, ensure that the digital certificates that are issued provide digital signature and encryption capabilities, based on the needs in your implementation.
You can configure Outlook Web Access with the S/MIME control to require only smart card-based digital certificates, using the SmartCardOnly registry setting on the user's Exchange Server. By default, this setting is not enabled. For more information about the SmartCardOnly registry setting, see Outlook Web Access S/MIME Control-Related Settings.
Terminal Services Support
The Remote Desktop client that ships with Windows Server 2003 supports smart card redirection. Using Windows Server 2003 Remote Desktop client, smart cards that are inserted in a reader attached to the Remote Desktop client, such as a kiosk, can be used within the terminal session.
Smart card redirection can be used with Outlook Web Access with the S/MIME control to enable users to use smart card-based certificates in a terminal session.
Windows Server 2003 Remote Desktop client imposes limitations on what client and server combinations smart card redirection can be used with. Table 6.1 lists the supported client and server combinations when using the Windows Server 2003 Remote Desktop client for smart card redirection.
Table 6.1 Supported client and server platforms for smart card redirection with Windows Server 2003 Remote Desktop client
| Client system running Windows Server 2003 Remote Desktop | Server system running Remote Desktop Services |
|---|---|
Windows XP |
Windows XP Remote Desktop |
Windows XP |
Windows Server 2003 |
Windows 2000 |
Windows XP Remote Desktop |
Windows 2000 |
Windows Server 2003 |
Windows Server 2003 |
Windows XP Remote Desktop |
Windows Server 2003 |
Windows Server 2003 |
As Table 6.1 shows, the server providing Terminal Services must be either Windows XP or Windows Server 2003. Windows 2000, Windows XP, and Windows Server 2003 can all be used as client platforms to run Windows Server 2003 Remote Desktop. No other versions of Windows can be used with the Windows Server 2003 Remote Desktop client to provide smart card redirection. For more information on smart card redirection, see Windows Server 2003 Remote Desktop client documentation.
Outlook Web Access with the S/MIME Control and S/MIME Encryption Capabilities
When using Outlook Web Access with the S/MIME control, you can force users to encrypt e-mail messages to a specified encryption algorithm. Rather than rely solely on the S/MIME encryption capabilities detailed in the user's encryption certificate, Outlook Web Access with the S/MIME control reviews information in the registry on the sender's Exchange server to determine what encryption algorithm and strength should be used. This capability enables you to enforce the organization's specific policies regarding e-mail message encryption. The EncryptionAlgorithms registry setting governs the choice of encryption algorithm. For more information about the EncryptionAlgorithms registry setting, see Outlook Web Access S/MIME Control-Related Settings.
If the sender's Exchange server is unable to obtain an encryption certificate for a recipient whose capabilities match the requirements set in the registry, Outlook Web Access with the S/MIME control handles the message according to the AlwaysEncrypt registry setting. If AlwaysEncrypt is not enabled, which is the default setting, the sender has the option to send the message to that recipient unencrypted. If AlwaysEncrypt is enabled, the sender cannot send the message. For more information about the AlwaysEncrypt registry setting, see Outlook Web Access S/MIME Control-Related Settings. If Outlook Web Access with the S/MIME control locates an encryption certificate for a recipient, but it either does not support the specified algorithm or supports the specified algorithm but not at the specified encryption strength, it is treated as if no certificate were found. The message will be handled in accordance with the AlwaysEncrypt setting.
Supporting S/MIME Messages from Other Organizations
When you use Outlook Web Access with the S/MIME control to exchange S/MIME e-mail messages with users in other organizations, the user's Exchange server performs certification validation operations on S/MIME messages on behalf of the user. To successfully validate S/MIME messages from other organizations, the user's Exchange server must validate the entire certificate chain to a trusted root certificate. If you plan to use S/MIME to exchange e-mail messages with other organizations and you want to validate other organizations' certificates to validate the digital signature, you must implement trust of other organizations' certificates in your PKI.
Exchange 2003 can trust the certificate either by trusting the issuer's root certificate or through a process of cross-certification with your PKI. The Exchange administrator can enable trust for the issuer's root certificate by adding that root certificate to the Trusted Root Certification Authorities folder in the Local Computer certificate store of the user's Exchange server. To implement this, confer with the Exchange administrator. For more information, including step-by-step instructions about how to import a cross-certified certificate, see Cannot verify sender's digital signatures when the sender's root CA digital certificate is not present in the Local Computer certificate store of the recipient's Exchange server.
Although adding the issuer's root certificate addresses this issue, it implicitly grants trust to all certificates issued by that PKI. This level of trust may exceed what is acceptable under your organization's security policy. An alternative solution is to cross-certify only those certificates in the other organization's PKI that are acceptable by issuing a certificate from your PKI and adding that certificate to the Trusted Personal certificates folder in the Local Computer certificate store of the user's Exchange server.
For information about how to implement cross-certification, see your PKI documentation. For information about implementing cross-certification in Windows Server 2003, see "Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003" (https://go.microsoft.com/fwlink/?LinkId=17806).
In addition to trusting the root certificate of the issuer of a certificate, a user's Exchange server must access and successfully validate any intermediate certificates. Depending on how the PKI administrator of the other organization has chosen to configure the PKI, these intermediate certificates may be included with signed e-mail messages or they may be made accessible at a location specified in the authority information access parameter of a digital certificate. To provide access to any intermediate certificates, the Exchange administrator must ensure that the user's Exchange server can successfully connect to and retrieve certificates made available through the authority information access parameter of a digital certificate. To provide validation of intermediate certificates, the Exchange administrator must ensure the user's Exchange server can successfully connect to the CRL distribution point and verify that the CRL is specified in the digital certificate. Thus, for a user's Exchange server to access and successfully validate any intermediate certificates, the Exchange administrator must ensure connectivity between the user's Exchange server and the locations specified in the authority information access and CRL distribution point parameters of the digital certificate. For most organizations, that place is a proxy server located between the Exchange servers and the Internet. The Exchange administrator must ensure that the appropriate proxy client software is installed and configured. If you cannot access intermediate certificates for validation, consider having the Exchange administrator disable CRL checking through the disableCRLCheck registry key. For more information about this setting, see Outlook Web Access S/MIME Control-Related Settings.
For more information, the Exchange administrator can consult "Configuring Exchange Servers" in Implementing Outlook Web Access with the S/MIME Control.
Configuring Intermediate Certificate Handling in Your PKI
By default, e-mail messages sent using Outlook Web Access with the S/MIME control include only the signing and encrypting certificates with a message. The root certificate and the intermediate certificates are not included. This setting is configurable using the SecurityFlags registry key. For more information about this setting, see Outlook Web Access S/MIME Control-Related Settings.
By default, Outlook Web Access with the S/MIME control sends only the signing and encrypting certificates. Because of this, it is recommended that you configure your PKI to use the authority information access parameter in the certificate and make your intermediate certificates publicly available through LDAP or HTTP. For more information about how to use this capability, see your PKI documentation.
If you cannot make intermediate certificates available using authority information access, Outlook Web Access with the S/MIME control should be configured to include intermediate certificates with e-mail messages. Confer with the Exchange administrator for any changes needed. For information about configuring the SecurityFlags registry key, see Outlook Web Access S/MIME Control-Related Settings.