Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1
Topic Last Modified: 2007-08-22

This topic explains how to edit the registry on a Microsoft Exchange Server 2007 server that has the Client Access server role installed so that you can manage the behavior of S/MIME for Microsoft Office Outlook Web Access.

Note:
Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

Before You Begin

To perform this procedure, the account you use must be delegated membership in the local Administrators group on the target server.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange 2007, see Permission Considerations.

If you are unfamiliar with managing Public Key Infrastructures (PKIs) and certificates, we recommend that you start by reviewing the following:

S/MIME Control Settings

You can change the registry on an Exchange 2007 server that has the Client Access server role installed to control the behavior of S/MIME in Outlook Web Access. These changes are made per server. If you have more than one Client Access server and need the same S/MIME behavior on all Client Access servers, you must make the same changes on each server. Changes to the S/MIME settings in the registry take effect immediately and will affect Outlook Web Access users the next time that they take any action that uses the S/MIME control. You do not have to force users to log off or to restart any services.

The following tables list the names, possible values, defaults, and behavior of the registry settings that you can use to control the behavior of the S/MIME control in Outlook Web Access.

Check CRL on Send

Exchange 2007 value name and type

CheckCRLOnSend (DWORD)

Exchange 2003 value name and type

CheckCRL (DWORD)

Values and defaults

1=True, 0=False (default)

Explanation

By default, if a Certificate Revocation List Distribution Point (CDP) in a sender's certificate chain cannot be accessed during revocation verification when sending signed or encrypted e-mail, Outlook Web Access will not display a warning notifying the sender that the certificate cannot be verified. Instead, it allows the e-mail to be sent.

When CheckCRLonSend is set to true, if a CDP in a sender's certificate chain cannot be accessed during revocation verification when sending signed or encrypted e-mail, Outlook Web Access will indicate a failure and prevent the e-mail message from being sent.

Distribution List Expansion Timeout

Exchange 2007 value name and type

DLExpansionTimeout (DWORD)

Exchange 2003 value name and type

DLExpansionTimeout (DWORD)

Values and defaults

Distribution List Expansion Timeout represents the time that it will take, in milliseconds, before a request to expand a distribution list will time out. The default value is 60000 (60 seconds). The minimum value is 0. Setting DLExpansionTimeout to 0 disables the ability to send encrypted e-mail to distribution lists. The maximum value is 2147483647. When DLExpansionTimeout is set to the maximum value, there is no distribution list expansion time-out and Outlook Web Access will wait until the distribution list is expanded, regardless of how long expansion takes.

Explanation

This attribute controls how long Outlook Web Access will wait, in milliseconds, for a distribution list in Active Directory to expand when sending encrypted e-mail before the operation fails.

When sending encrypted e-mail to a distribution list, Outlook Web Access must expand the distribution list to retrieve the encryption certificate of each recipient for use in the encryption operation. The time this operation takes varies depending on the size of the distribution list and the performance of the underlying Active Directory infrastructure. While the distribution list is being expanded, the sender will receive no response from Outlook Web Access. This attribute specifies how long Outlook Web Access should wait for the full distribution list to be expanded. If the operation has not completed in the time specified by this value, the operation will fail and the mail will not be sent. The sender will be returned to the compose form, which will include an infobar that includes the following error message:

The action could not be completed. Please try again. If the problem continues, contact technical support for your organization.

Use Secondary Proxies When Finding Certificates

Exchange 2007 value name and type

UseSecondaryProxiesWhenFindingCertificates (DWORD)

Exchange 2003 value name and type

CertMatchingDoNotUseProxies (DWORD)

Values and defaults

1=True (default), 0=False

Explanation

Outlook Web Access tries to find the correct certificate in Active Directory for a recipient when sending encrypted e-mail. The certificate subject or subject alternative name values can contain an SMTP address as one of its values. Because a recipient can have multiple SMTP proxy addresses in the directory, the subject or subject alternative name of the certificate may not match the primary SMTP address. Instead it may match one of the proxy addresses.

If UseSecondaryProxiesWhenFindingCertificates is set to true, Outlook Web Access will accept certificates that do not match the primary SMTP address of the recipient as valid. If UseSecondaryProxiesWhenFindingCertificates is set to false, Outlook Web Access will accept as valid only certificates that match the primary SMTP address of the recipient.

CRL Connection Timeout

Exchange 2007 value name and type

CRLConnectionTimeout (DWORD)

Exchange 2003 value name and type

RevocationURLRetrievalTimeout (DWORD)

Values and defaults

CRL Connection Timeout represents the time it will take, in milliseconds before a CRL Connection request will time out. The default value is 60000 (60 seconds). The minimum value is 5000 (5 seconds). A maximum value of 2147483647 can be specified. If CRLConnectionTimeout is set to the maximum value, the connection will not time out.

Explanation

CRL Connection Timeout specifies the time, in milliseconds, that Outlook Web Access will wait while connecting to retrieve a single Certificate Revocation List (CRL) as part of a certificate validation operation.

Validating a certificate requires retrieving the certification authority's CRL from the CRL distribution point that is specified within the certificate. This operation must be performed for each certificate in the complete certificate chain.

When multiple CRLs must be retrieved, this key will apply to each connection. For example, if three CRLs must be retrieved and CRLConnectionTimeout is set to 60 seconds, each CRL retrieval operation will have a time-out limit of 60 seconds. If the CRL is not retrieved before the time-out limit that is specified, the operation fails. If CRLConnectionTimeout is set to less than 5000, the default value (60000) will be used. If CRLConnectionTimeout is set to the maximum, 2147483647, the connection will not time out.

CRL Retrieval Timeout

Exchange 2007 value name and type

CRLRetrievalTimeout (DWORD)

Exchange 2003 value name and type

CertURLRetrievalTimeout (DWORD)

Values and defaults

CRL Retrieval Timeout specifies the time, in milliseconds, that Outlook Web Access will wait while connecting to complete all of the CRL retrievals for a single message. The default value is 10000 (10 seconds). The minimum value is 0. The maximum value is 2147483647.

Explanation

This attribute resembles CRL Connection Timeout, however it specifies the time, in milliseconds, that Outlook Web Access will wait to retrieve all CRLs when validating a certificate. If all CRLs are not retrieved before the time-out limit that is specified, the operation will fail.

When you set this value, it is important to remember that, in a certificate validation operation, CRL Connection Timeout is applied to each CRL retrieval and to the overall operation of all CRL retrievals. For example, if three CRLs must be retrieved and CRLConnectionTimeout is set to 60 seconds, and CRLRetrievalTimeout is set to 120 seconds, each CRL retrieval operation will have a time-out of 60 seconds and the overall operation will have a time-out of 120 seconds. In this example, if any individual CRL retrieval takes more than 60 seconds, the operation will fail. Also, if all the CRL retrievals take more than 120 seconds, the operation will fail.

Disable CRL Check

Exchange 2007 value name and type

DisableCRLCheck (DWORD)

Exchange 2003 value name and type

DisableCRLCheck (DWORD)

Values and defaults

1=True, 0=False (default)

Explanation

When set to true, DisableCRLCheck prevents Certificate Revocation Lists (CRLs) from being checked while certificates are being validated. Disabling CRL checking can increase the time it takes to validate the signatures of signed e-mail. However, it will also show revoked e-mail signed with revoked certificates as valid instead of not valid.

Always Sign

Exchange 2007 value name and type

AlwaysSign (DWORD)

Exchange 2003 value name and type

AlwaysSign (DWORD)

Values and defaults

1=True, 0=False (default)

Explanation

When set to true, AlwaysSign will force users to digitally sign e-mail when they use Outlook Web Access with the S/MIME control. Also, the Options page and the Message Options dialog box will show the "Send signed e-mail" option as selected.

Always Encrypt

Exchange 2007 value name and type

AlwaysEncrypt (DWORD)

Exchange 2003 value name and type

AlwaysEncrypt (DWORD)

Values and defaults

1=True, 0=False (default)

Explanation

When set to true, AlwaysEncrypt will force users to encrypt e-mail when they use Outlook Web Access with the S/MIME control. Also, the Options page and the Message Options dialog box will display the "Send encrypted e-mail" option as selected.

Clear Sign

Exchange 2007 value name and type

ClearSign (DWORD)

Exchange 2003 value name and type

ClearSign (DWORD)

Values and defaults

1=True (default), 0=False

Explanation

When set to true, ClearSign forces any digitally signed e-mail message that is sent from Outlook Web Access to be clear-signed. The default setting for this attribute is true. Setting this value to false will cause Outlook Web Access to use an opaque signature. Clear-signed e-mail messages are larger than opaque-signed signatures, but they can be opened and read with most e-mail clients, including clients that do not support S/MIME.

Include Certificate Chain Without Root Certificate

Exchange 2007 value name and type

IncludeCertificateChainWithoutRootCertificate (DWORD)

Exchange 2003 value name and type

SecurityFlags (value 0x001)

Values and defaults

1=True, 0=False (default)

Explanation

The default behavior of Outlook Web Access is to include only the signing and encrypting certificates, not their corresponding certificate chains, when sending signed or encrypted e-mail. This option may be necessary for interoperating with other clients, or in environments where intermediate certificate authorities cannot be reached by using the Authority Information Access attribute or by having the intermediate CA trusted in the Computer account of the Exchange 2007 mailbox server. When IncludeCertificateChainWithoutRootCertificate is set to true, signed or encrypted e-mail will include the full certificate chain, except for the root certificate.

This setting increases the size of signed and encrypted messages.

Include Certificate Chain and Root

Exchange 2007 value name and type

IncludeCertificateChainAndRootCertificate (DWORD)

Exchange 2003 value name and type

SecurityFlags (value 0x002)

Values and defaults

1=True, 0=False (default)

Explanation

Include Certificate Chain and Root resembles Include Certificate Chain Without Root Certificate, but, when it is set to true, it includes the root certificate and the full certificate chain.

When set to true, IncludeCertificateChainAndRootCertificate increases the size of signed and encrypted messages more than IncludeCertificateChainWithoutRootCertificate.

Encrypt Temporary Buffers

Exchange 2007 value name and type

EncryptTemporaryBuffers (DWORD)

Exchange 2003 value name and type

SecurityFlags (value 0x004)

Values and defaults

1=True (default), 0=False

Explanation

By default, all client-side temporary buffers that are used to store message data are encrypted by using an ephemeral key and the 3DES algorithm. This setting can be used to enable or disable encrypting the temporary buffers. Disabling encryption of the buffers can increase performance of the Outlook Web Access client. However, it leaves information unencrypted in the buffer of the local system. Before you disable this feature, see your organization's security policy.

Signed E-mail Certificate Inclusion

Exchange 2007 value name and type

SignedEmailCertificateInclusion (DWORD)

Exchange 2003 value name and type

SecurityFlags (value 0x008)

Values and defaults

1=True (default), 0=False

Explanation

By default Outlook Web Access with the S/MIME control installed includes both signing and encrypting certificates with signed e-mail. When you disable this setting by setting SignedEmailCertificateInclusion to false, the size of messages that are sent from Outlook Web Access with the S/MIME control will decrease. However, recipients will not have access to the sender's encryption certificate in the received message. They will have to obtain that certificate another way, either by retrieving it from a directory or obtaining it from the sender.

BCC Encrypted E-mail Forking

Exchange 2007 value name and type

BccEncryptedEmailForking (DWORD)

Exchange 2003 value name and type

SecurityFlags (values 0x040, 0x080)

Values and defaults

0=One encrypted message per BCC recipient (default)

1=One single encrypted message for all BCC recipients

2=One encrypted message without BCC forking

Explanation

By default, Outlook Web Access will submit a separate encrypted message for each recipient on the Bcc line of an encrypted message. This option provides the most security for Bcc recipients of an encrypted message. By changing the value of BCCEncryptedEmailForking, you can require Outlook Web Access to create a single encrypted message for all Bcc recipients or one encrypted message without a separate message for each Bcc recipient. 

Include S/MIME Capabilities in Message

Exchange 2007 value name and type

IncludeSMIMECapabilitiesInMessage (DWORD)

Exchange 2003 value name and type

SecurityFlags (value 0x100)

Values and defaults

1=True, 0=False (default)

Explanation

When IncludeSMIMECapabilitiesInMessage is set to true, Outlook Web Access will add attributes to outgoing signed and encrypted messages that indicate which encryption and signing algorithms and key lengths are supported.

Enabling this attribute will increase the size of messages. However, enabling it can make it easier for some e-mail clients to interoperate with Outlook Web Access.

Copy Recipient Headers

Exchange 2007 value name and type

CopyRecipientHeaders (DWORD)

Exchange 2003 value name and type

SecurityFlags (value 0x200)

Values and defaults

1=True, 0=False (default)

Explanation

When it is set to true, CopyRecipientHeaders puts a copy of the From, To, and Cc recipient headers in the signed part of the message. This allows the recipient to verify that these headers were not tampered with while the message was in transit. Enabling this feature increases the message size.

Only Use Smart Card

Exchange 2007 value name and type

OnlyUseSmartCard (DWORD)

Exchange 2003 value name and type

SmartCardOnly (DWORD)

Values and defaults

1=True, 0=False (default)

Explanation

When it is set to true, OnlyUseSmartCard forces the use of smartcard-based certificates for signing and decryption when you use Outlook Web Access together with the S/MIME control. Users cannot use certificates not on a smartcard.

Triple Wrap Encrypted Mail

Exchange 2007 value name and type

TripleWrapSignedEncryptedMail (DWORD)

Exchange 2003 value name and type

TripleWrap (DWORD)

Values and defaults

1=True (default), 0=False

Explanation

When TripleWrapSignedEncryptedMail is set to true, encrypted e-mail messages that are digitally signed are triple-wrapped. When a message is tripled-wrapped, the digitally-signed message is encrypted, and then the encrypted message is digitally signed. When set to false, the digitally signed message is only encrypted, there is no additional digital signing of the encrypted message. By default, this attribute is set to true. Triple-wrapped messages afford the most security for digitally-signed and encrypted e-mail under the S/MIME standard, but they are larger than messages that are not triple-wrapped.

Use Key Identifier

Exchange 2007 value name and type

UseKeyIdentifier (DWORD)

Exchange 2003 value name and type

UseKeyIdentifier (DWORD)

Values and defaults

1=True, 0=False (default)

Explanation

By default, when encrypting e-mail, Outlook Web Access will encode the lockbox where the asymmetrically-encrypted token that is required to decrypt the rest of the message is stored. It encodes the lockbox by indicating the issuer and serial number of each recipient's certificate. This can then be used to locate the certificate and private key for decrypting the message.

An alternative way to locate the certificate and private key for decrypting the message is to use a certificate's key identifier by setting UseKeyIdentifier to true. Because a key pair can be reused in new certificates, using the key identifier for encrypted e-mail enables users to keep only the most recent certificate and the associated private key, instead of all old certificates, which can only be matched by issuer and serial number.

By default, because some e-mail clients do not support finding certificates with a key identifier, Outlook Web Access uses the issuer and serial number of each recipient's certificate. However, enabling this feature can make it easier to manage encrypted messages by eliminating the need for users to keep old, expired certificates on their system.

S/MIME Encryption Algorithms

Exchange 2007 value name and type

EncryptionAlgorithms (Reg-SZ)

Exchange 2003 value name and type

EncryptionAlgorithms (Reg_SZ)

Values and defaults

This key is a semicolon-separated list that represents the symmetric encryption algorithms to use when encrypting messages when using Outlook Web Access together with the S/MIME control.

List format: {Well-known algorithm ID}[:key length to use]|[,Custom replacement algorithm OID]; {Well-known algorithm ID}[:key length to use]|[,Custom replacement algorithm OID]; …

Supported algorithms and their ALG_IDs:

  • DES6601

  • 3DES6603

  • RC26602

  • AES128660E

  • AES192660F

  • AES2566610

Key length is only applicable to variable-key length algorithms when the key length is not encoded into the algorithm ID itself. RC2 is the only such algorithm in the previous list.

Custom replacement algorithm OID   You can supply your own algorithm by implementing it within a cryptographic service provider (CSP), assigning it a custom object ID, and specifying the OID by using the EncryptionAlgorithms key. An OID must be specified together with a well-known algorithm ID. Outlook Web Access needs a well-known algorithm ID so that it can infer how the algorithm should be used. For example, to provide a custom replacement for the 3DES algorithm, you would specify the ALG_ID of 3DES (0x6603) and the custom OID of the replacement algorithm.

The values of the registry key should be listed from the longest key length to the shortest because the order reflects priority of use. For example, to list 3DES, RC2-128, RC2-64, DES, RC2-56, and RC2-40, type the value in the following way:

6603;6602:128;6602:64;6601;6602:56;6602:40

If the registry key is present, algorithms that are specified in the key will always be used. If the key is not present, Outlook Web Access will fall back to its default internal list. This list begins with AES256 in computers that are running Windows Vista and with 3DES in computers that are running Microsoft Windows XP.

The AES algorithms are only used if the user's computer supports them. AES is not supported on Windows XP and messages that are encrypted by using AES cannot be read on computers that are running Windows XP.

Explanation

Outlook Web Access will try to use the strongest algorithm with the longest available key length on the user's computer. If the encryption algorithm or minimum key length is not available on the user's computer, Outlook Web Access will not allow encryption.

S/MIME Default Signing Algorithm

Exchange 2007 value name and type

SigningAlgorithms (Reg_SZ)

Exchange 2003 value name and type

DefaultSigningAlgorithm (reg_SZ)

Values and defaults

The SigningAlgorithms key specifies the list of signing algorithms to use when signing messages using Outlook Web Access with the S/MIME control installed. The following table enumerates the signing algorithms, their algorithm IDs, and the supported key lengths for each.

Format: {Well-known algorithm ID}

Well-known algorithm IDs, and key lengths

  • CALG_SHA_512800E

  • CALG_SHA_384800D

  • CALG_SHA_256800C

  • SHA10x8004

  • MD50x8003

If the registry key is present, the algorithm that is specified in the key will always be used. If the key is not present, Outlook Web Access will fall back to its internal default list. This list begins with SHA-1.

Messages that are digitally signed by using CALG_SHA_256 cannot be verified on computers that are running Windows XP.

Explanation

This attribute specifies the digital signing algorithm to use when digitally signing messages by using Outlook Web Access together with the S/MIME control.

Force S/MIME Client Upgrade

Exchange 2007 value name and type

ForceSMIMEClientUpgrade (DWORD)

Exchange 2003 value name and type

Not available. This is a new feature in Exchange 2007.

Values and defaults

1=True (default), 0=False

Explanation

When ForceSMIMEClientUpgrade is set to true, if the client control version on the user's computer is older than the version on the server, the user must download and install the new control before they can continue to use any S/MIME Read or Compose forms. If this value is set to false, the user will receive a warning if the S/MIME control on their computer is older than the version on the server. However, they will be able to use S/MIME without updating the control.

Procedure

To use Registry Editor to change the S/MIME control settings for Outlook Web Access

  1. Start Registry Editor (regedit).

  2. Locate the following registry subkey:

    HKLM\System\CurrentControlSet\Services\MSExchange OWA\SMIME

  3. Find the key that you want to change.

  4. Set the key to the value that is required by your organization.

  5. If the key that you need does not exist, create a new DWORD with that name, and then set it to the value that is required by your organization.

For More Information

For more information about S/MIME and Outlook Web Access, see: