Manage S/MIME for Outlook Web App: Exchange 2010 Help

Manage S/MIME for Outlook Web App: ...

Collapse All

More Resources

Related Blog Articles

Visit the Exchange Team Blog

more...

Related Forum Discussions

Ask a question

Visit the forums

Manage S/MIME for Outlook Web App

Applies to: Exchange Server 2010 SP2

Topic Last Modified: 2011-03-19

You can edit the registry on a Microsoft Exchange Server 2010 Client Access server so you can manage the behavior of Secure/Multipurpose Internet Mail Extensions (S/MIME) for Outlook Web App.

You can change the registry on an Exchange 2010 server that has the Client Access server role installed to control the behavior of S/MIME in Outlook Web App. 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 App users the next time that they take any action that uses the S/MIME control. You do not have to force users to sign out or to restart any services.

Looking for other management tasks related to Outlook Web App security? Check out Managing Outlook Web App Security.

Prerequisites

If you're unfamiliar with managing public key infrastructures (PKIs) and certificates, we recommend that you start by reviewing the Active Directory Certificate Services and Public Key Management.

S/MIME Control Settings

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

Check CRL on Send

Exchange 2010 value name and type	CheckCRLOnSend (DWORD)
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 (CRL) distribution point in a sender's certificate chain cannot be accessed during revocation verification when sending signed or encrypted e-mail, Outlook Web App 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 CRL distribution point in a sender's certificate chain cannot be accessed during revocation verification when sending signed or encrypted e-mail, Outlook Web App will indicate a failure and prevent the e-mail message from being sent.

Distribution List Expansion Timeout

Exchange 2010 value name and type	DLExpansionTimeout (DWORD)
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 App will wait until the distribution list is expanded, regardless of how long expansion takes.
Explanation	This attribute controls how long Outlook Web App 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 App 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 App. This attribute specifies how long Outlook Web App 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 2010 value name and type	UseSecondaryProxiesWhenFindingCertificates (DWORD)
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 App 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 App will accept certificates that do not match the primary SMTP address of the recipient as valid. If UseSecondaryProxiesWhenFindingCertificates is set to false, Outlook Web App will accept as valid only certificates that match the primary SMTP address of the recipient.

CRL Connection Timeout

Exchange 2010 value name and type	CRLConnectionTimeout (DWORD)
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 App will wait while connecting to retrieve a single 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 2010 value name and type	CRLRetrievalTimeout (DWORD)
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 App 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 App 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 2010 value name and type	DisableCRLCheck (DWORD)
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 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.

Allow User Choice of Signing Certificate

Exchange 2010 value name and type	AllowUserChoiceOfSigningCertificate (DWORD)
Exchange 2007 value name and type	AllowUserChoiceOfSigningCertificate (DWORD)
Exchange 2003 value name and type	Not available. This was a new feature in Exchange 2007.
Values and defaults	1=True, 0=False (default)
Explanation	When set to true, AllowUserChoiceOfSigningCertificate lets users select which signing certificate to use to digitally sign e-mail when they use Outlook Web App with the S/MIME control. This is controlled only from the S/MIME options tab.

Always Sign

Exchange 2010 value name and type	AlwaysSign (DWORD)
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 App 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 2010 value name and type	AlwaysEncrypt (DWORD)
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 App 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 2010 value name and type	ClearSign (DWORD)
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 App to be clear-signed. The default setting for this attribute is true. Setting this value to false will cause Outlook Web App 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 2010 value name and type	IncludeCertificateChainWithoutRootCertificate (DWORD)
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 App 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 certification authorities (CAs) cannot be reached by using the Authority Information Access attribute or by having the intermediate CA trusted in the Computer account of the Exchange 2010 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 2010 value name and type	IncludeCertificateChainAndRootCertificate (DWORD)
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 2010 value name and type	EncryptTemporaryBuffers (DWORD)
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 App 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 2010 value name and type	SignedEmailCertificateInclusion (DWORD)
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 App 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 App 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 2010 value name and type	BccEncryptedEmailForking (DWORD)
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 Bc forking
Explanation	By default, Outlook Web App 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 App 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 2010 value name and type	IncludeSMIMECapabilitiesInMessage (DWORD)
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 App 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 App.

Copy Recipient Headers

Exchange 2010 value name and type	CopyRecipientHeaders (DWORD)
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 2010 value name and type	OnlyUseSmartCard (DWORD)
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 smart card-based certificates for signing and decryption when you use Outlook Web App together with the S/MIME control. Users cannot use certificates not on a smartcard.

Triple Wrap Encrypted Mail

Exchange 2010 value name and type	TripleWrapSignedEncryptedMail (DWORD)
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 2010 value name and type	UseKeyIdentifier (DWORD)
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 App 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 App 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 2010 value name and type	EncryptionAlgorithms (Reg-SZ)
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 App 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 App 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 App 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 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 App 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 App will not allow encryption.

S/MIME Default Signing Algorithm

Exchange 2010 value name and type	SigningAlgorithms (Reg_SZ)
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 App 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 App 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 App together with the S/MIME control.

Force S/MIME Client Upgrade

Exchange 2010 value name and type	ForceSMIMEClientUpgrade (DWORD)
Exchange 2007 value name and type	ForceSMIMEClientUpgrade (DWORD)
Exchange 2003 value name and type	Not available. This was 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.

Use Registry Editor to change the S/MIME control settings for Outlook Web App