How to Manage S/MIME for Outlook Web Access
Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
Applies to: Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3
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:
For more information about certificates, see Understanding Digital Certificates.
For more information about best practices for implementing a Windows PKI, see Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure.
For more information about how to deploy a Windows PKI, see the Windows Server 2003 PKI Operations Guide.
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. |
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 (feature introduced in Exchange 2007) |
Values and defaults |
1=True, 0=False (default) |
Explanation |
When set to true, AllowUserChoiceOfSigningCertificate lets users select a signing certificate to digitally sign e-mail when they use Outlook Web App together with the S/MIME control. This is controlled only on the S/MIME options tab. |
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:
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
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
Start Registry Editor (regedit).
Locate the following registry subkey:
HKLM\System\CurrentControlSet\Services\MSExchange OWA\SMIME
Find the key that you want to change.
Set the key to the value that is required by your organization.
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: