Gérer S/MIME pour Outlook Web App
S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3
Dernière rubrique modifiée : 2016-11-28
Vous pouvez modifier le Registre sur un serveur d’accès au client Microsoft Exchange Server 2010 de façon à gérer le comportement de S/MIME (Secure/Multipurpose Internet Mail Extensions) pour Outlook Web App.
Vous pouvez modifier le Registre sur un serveur Exchange 2010 sur lequel le rôle serveur d’accès au client est installé pour contrôler le comportement de S/MIME dans Outlook Web App. Ces modifications sont apportées par serveur. Si vous avez plusieurs serveurs d’accès au client et voulez avoir le même comportement S/MIME sur tous les serveurs d’accès au client, vous devez apporter les mêmes modifications sur chaque serveur. Les modifications apportées aux paramètres de S/MIME dans le Registre prennent effet immédiatement et affectent les utilisateurs d’Outlook Web App la prochaine fois qu’ils exécutent une action utilisant le contrôle S/MIME. Il n’est pas nécessaire de forcer les utilisateurs à se déconnecter ou à redémarrer des services.
Souhaitez-vous rechercher les autres tâches de gestion relatives à la sécurité d’Outlook Web App ? Consultez la rubrique Gestion de la sécurité d’Outlook Web App.
Conditions préalables
Si vous n’êtes pas familiarisé avec la gestion des infrastructures à clé publique et des certificats, nous vous recommandons de commencer par prendre connaissance de la page Active Directory Certificate Services and Public Key Management.
Paramètres de contrôle S/MIME
Les tableaux suivants répertorient les noms, les valeurs possibles, les valeurs par défaut et le comportement des paramètres de Registre que vous pouvez utiliser pour contrôler le comportement du contrôle S/MIME dans Outlook Web App.
Vérifier la liste de révocation de certificats (CRL) lors de l’envoi
Nom et type de valeur Exchange 2010 |
CheckCRLOnSend (DWORD) |
Nom et type de valeur Exchange 2007 |
CheckCRLOnSend (DWORD) |
Nom et type de valeur Exchange 2003 |
CheckCRL (DWORD) |
Valeurs et paramètres par défaut |
1=Vrai, 0=Faux (par défaut) |
Explication |
Par défaut, si un point de distribution de liste de révocation de certificat (CRL) dans la chaîne de certificats d’un expéditeur est inaccessible durant la vérification de la révocation lors de l’envoi de messages signés ou chiffrés, Outlook Web App n’affiche pas d’avertissement informant l’expéditeur que le certificat est invérifiable. Au lieu de cela, il autorise l’envoi du message. Lorsque CheckCRLonSend est défini sur Vrai, si un point de distribution de liste de révocation de certificat dans la chaîne de certificats d’un expéditeur est inaccessible durant la vérification de la révocation lors de l’envoi de messages signés ou chiffrés, Outlook Web App signale une défaillance et empêche l’envoi du message électronique. |
Délai d’attente pour l’extension de la liste de distribution
Nom et type de valeur Exchange 2010 |
DLExpansionTimeout (DWORD) |
Nom et type de valeur Exchange 2007 |
DLExpansionTimeout (DWORD) |
Nom et type de valeur Exchange 2003 |
DLExpansionTimeout (DWORD) |
Valeurs et paramètres par défaut |
Le délai d’attente pour l’extension de la liste de distribution représente le temps, exprimé en millisecondes, qui s’écoule avant qu’une demande d’extension d’une liste de distribution expire. La valeur par défaut est 60000 (60 secondes). La valeur minimale est 0. La définition de DLExpansionTimeout sur 0 désactive la possibilité d’envoyer des messages électroniques chiffrés à des listes de distribution. La valeur maximale est 2147483647. Quand DLExpansionTimeout est défini sur la valeur maximale, il n’y a pas de délai d’attente pour l’extension de la liste de distribution et Outlook Web App attend jusqu’à ce que la liste de distribution soit étendue, indépendamment du temps nécessaire pour l’extension. |
Explication |
Cet attribut contrôle le temps, exprimé en millisecondes, pendant lequel Outlook Web App attend qu’une liste de distribution dans Active Directory s’étende lors de l’envoi de messages chiffrés avant l’échec de l’opération. Lors de l’envoi d’un message chiffré à une liste de distribution, Outlook Web App doit étendre la liste de distribution pour récupérer le certificat de chiffrement de chaque destinataire à utiliser dans l’opération de chiffrement. Le délai nécessaire à cette opération varie en fonction de la taille de la liste de distribution et des performances de l’infrastructure Active Directory sous-jacente. Pendant que la liste de distribution est en cours d’extension, l’expéditeur ne reçoit aucune réponse d’Outlook Web App. Cet attribut spécifie le délai pendant lequel Outlook Web App doit attendre que la liste de distribution complète soit étendue. Si l’opération n’est pas terminée dans le délai spécifié par cette valeur, elle échoue et le message n’est pas envoyé. L’expéditeur est renvoyé au formulaire de composition qui inclut une barre d’informations contenant le message d’erreur suivant : Impossible de terminer l’action. Veuillez réessayer. Si le problème persiste, contactez le support technique de votre organisation. |
Utiliser des proxys secondaires lors de la recherche de certificats
Nom et type de valeur Exchange 2010 |
UseSecondaryProxiesWhenFindingCertificates (DWORD) |
Nom et type de valeur Exchange 2007 |
UseSecondaryProxiesWhenFindingCertificates (DWORD) |
Nom et type de valeur Exchange 2003 |
CertMatchingDoNotUseProxies (DWORD) |
Valeurs et paramètres par défaut |
1=Vrai (par défaut), 0=Faux |
Explication |
Lors de l’envoi d’un message électronique chiffré, Outlook Web App tente de trouver dans Active Directory le certificat qui convient pour un destinataire. Les valeurs d’objet et d’autre nom de l’objet du certificat peuvent contenir chacune une adresse SMTP. Un destinataire pouvant posséder plusieurs adresses proxy SMTP dans l’annuaire, les valeurs d’objet et d’autre nom de l’objet du certificat peuvent ne pas correspondre à l’adresse SMTP principale, mais à l’une des adresses proxy. Si UseSecondaryProxiesWhenFindingCertificates est défini sur Vrai, Outlook Web App accepte comme valides des certificats ne correspondant pas à l’adresse SMTP principale du destinataire. Si UseSecondaryProxiesWhenFindingCertificates est défini sur Faux, Outlook Web App n’accepte comme valides que des certificats correspondant à l’adresse SMTP principale du destinataire. |
Délai d’attente pour la connexion aux listes de révocation de certificats
Nom et type de valeur Exchange 2010 |
CRLConnectionTimeout (DWORD) |
Nom et type de valeur Exchange 2007 |
CRLConnectionTimeout (DWORD) |
Nom et type de valeur Exchange 2003 |
RevocationURLRetrievalTimeout (DWORD) |
Valeurs et paramètres par défaut |
Le délai d’attente de connexion aux listes de révocation de certificats représente le temps, exprimé en millisecondes, qui s’écoule avant qu’une demande de connexion aux listes de révocation de certificats expire. La valeur par défaut est 60000 (60 secondes). La valeur minimale est 5000 (5 secondes). Vous pouvez spécifier une valeur maximale de 2147483647. Si CRLConnectionTimeout est défini sur la valeur maximale, la connexion n’expire pas. |
Explication |
Le délai d’attente de connexion aux listes de révocation de certificats spécifie la durée, en millisecondes, pendant laquelle Outlook Web App attend, au moment de la connexion, avant de recevoir une seule liste de révocation de certificats dans le cadre d’une opération de validation de certificat. La validation d’un certificat requiert la récupération de la liste de révocation de certificats de l’autorité de certification à partir du point de distribution spécifié dans le certificat. Cette opération doit être effectuée pour chaque certificat de la chaîne de certificats complète. Si plusieurs listes de révocation de certificats doivent être récupérées, la clé s’applique à chaque connexion. Par exemple, si trois listes de révocation de certificats doivent être récupérées et que CRLConnectionTimeout est défini sur 60 secondes, chaque opération de récupération de liste de révocation de certificats doit s’exécuter dans un délai de 60 secondes. Si la liste de révocation de certificats n’est pas récupérée dans le délai spécifié, l’opération échoue. Si CRLConnectionTimeout est défini sur une valeur inférieure à 5000, la valeur par défaut (60000) est utilisée. Si CRLConnectionTimeout est défini sur la valeur maximale, 2147483647, la connexion n’expire pas. |
Délai d’attente pour la récupération des listes de révocation de certificats
Nom et type de valeur Exchange 2010 |
CRLRetrievalTimeout (DWORD) |
Nom et type de valeur Exchange 2007 |
CRLRetrievalTimeout (DWORD) |
Nom et type de valeur Exchange 2003 |
CertURLRetrievalTimeout (DWORD) |
Valeurs et paramètres par défaut |
Le délai d’attente pour la récupération des listes de révocation de certificats spécifie la durée, exprimée en millisecondes, pendant laquelle Outlook Web App attend, au moment de la connexion, pour l’accomplissement de la récupération de toutes les listes de révocation de certificats pour un message. La valeur par défaut est 10000 (10 secondes). La valeur minimale est 0 et la valeur maximale 2147483647. |
Explication |
Cet attribut ressemble au délai d’attente de connexion aux listes de révocation de certificats, mais il indique le temps, exprimé en millisecondes, pendant lequel Outlook Web App attend avant de récupérer tous les listes de révocation de certificats lors de la validation d’un certificat. Si les listes de révocation de certificats ne sont pas toutes récupérées dans le délai spécifié, l’opération échoue. Lorsque vous définissez cette valeur, il est important de garder à l’esprit que, dans une opération de validation de certificat, un délai d’attente de connexion aux listes de révocation de certificats est appliqué à chaque récupération de listes de révocation de certificats et à l’opération globale de toutes les récupérations. Par exemple, si trois listes de révocation de certificats doivent être récupérées et si CRLConnectionTimeout est défini sur 60 secondes et CRLRetrievalTimeout sur 120 secondes, chaque opération de récupération de listes de révocation de certificats aura un délai de 60 secondes alors que l’opération globale aura un délai d’attente de 120 secondes. Dans cet exemple, si l’une des récupérations de listes de révocation de certificats dépasse le délai imparti de 60 secondes, l’opération échoue. De même, si l’ensemble des récupérations prend plus de 120 secondes, l’opération échoue. |
Désactiver la vérification de la liste de révocation de certificats
Nom et type de valeur Exchange 2010 |
DisableCRLCheck (DWORD) |
Nom et type de valeur Exchange 2007 |
DisableCRLCheck (DWORD) |
Nom et type de valeur Exchange 2003 |
DisableCRLCheck (DWORD) |
Valeurs et paramètres par défaut |
1=Vrai, 0=Faux (par défaut) |
Explication |
Lorsque DisableCRLCheck est défini sur Vrai, la vérification des listes de révocation de certificats ne s’effectue pas pendant la validation des certificats. La désactivation de cette vérification peut allonger le temps nécessaire pour la validation des signatures de messages signés. Toutefois, elle présente également les messages révoqués signés avec des certificats révoqués comme valides au lieu de non valides. |
Toujours signer
Nom et type de valeur Exchange 2010 |
AlwaysSign (DWORD) |
Nom et type de valeur Exchange 2007 |
AlwaysSign (DWORD) |
Nom et type de valeur Exchange 2003 |
AlwaysSign (DWORD) |
Valeurs et paramètres par défaut |
1=Vrai, 0=Faux (par défaut) |
Explication |
Lorsque AlwaysSign est défini sur Vrai, les utilisateurs doivent signer numériquement les messages lorsqu’ils utilisent Outlook Web App avec le contrôle S/MIME. De même, la page Options et la boîte de dialogue Options de message présentent l’option « Envoyer message signé » comme activée. |
Toujours chiffrer
Nom et type de valeur Exchange 2010 |
AlwaysEncrypt (DWORD) |
Nom et type de valeur Exchange 2007 |
AlwaysEncrypt (DWORD) |
Nom et type de valeur Exchange 2003 |
AlwaysEncrypt (DWORD) |
Valeurs et paramètres par défaut |
1=Vrai, 0=Faux (par défaut) |
Explication |
Lorsque AlwaysEncrypt est défini sur Vrai, les utilisateurs doivent chiffrer les messages lorsqu’ils utilisent Outlook Web App avec le contrôle S/MIME. De même, la page Options et la boîte de dialogue Options de message présentent l’option « Envoyer message chiffré » comme activée. |
Signature lisible
Nom et type de valeur Exchange 2010 |
ClearSign (DWORD) |
Nom et type de valeur Exchange 2007 |
ClearSign (DWORD) |
Nom et type de valeur Exchange 2003 |
ClearSign (DWORD) |
Valeurs et paramètres par défaut |
1=Vrai (par défaut), 0=Faux |
Explication |
Lorsque ClearSign est défini sur Vrai, tout message numérique signé envoyé à partir d’Outlook Web App doit être signé en texte clair. La valeur par défaut de cet attribut est Vrai. Si cette valeur est définie sur Faux, Outlook Web App utilise une signature opaque. Les messages électroniques signés en texte clair sont plus volumineux que si la signature est opaque, mais ils peuvent être ouverts et lus à l’aide de la plupart des clients de messagerie, y compris ceux qui ne prennent pas en charge S/MIME. |
Inclure la chaîne de certificats sans le certificat racine
Nom et type de valeur Exchange 2010 |
IncludeCertificateChainWithoutRootCertificate (DWORD) |
Nom et type de valeur Exchange 2007 |
IncludeCertificateChainWithoutRootCertificate (DWORD) |
Nom et type de valeur Exchange 2003 |
SecurityFlags (valeur 0x001) |
Valeurs et paramètres par défaut |
1=Vrai, 0=Faux (par défaut) |
Explication |
Le comportement par défaut d’Outlook Web App, lors de l’envoi de messages chiffrés ou signés, consiste à inclure uniquement les certificats de signature et de chiffrement et non les chaînes de certificat correspondantes. Cette option peut s’avérer nécessaire pour interagir avec d’autres clients ou dans des environnements où les autorités de certification intermédiaires ne sont pas accessibles à l’aide de l’attribut Accès aux informations de l’Autorité ni en approuvant l’autorité de certification intermédiaire dans le compte d’ordinateur du serveur de boîtes aux lettres Exchange 2010. Lorsque IncludeCertificateChainWithoutRootCertificate est défini sur Vrai, les messages signés ou chiffrés incluent la chaîne de certificats complète, à l’exception du certificat racine. Ce paramètre augmente la taille des messages signés et chiffrés. |
Inclure la chaîne de certificats et la racine
Nom et type de valeur Exchange 2010 |
IncludeCertificateChainAndRootCertificate (DWORD) |
Nom et type de valeur Exchange 2007 |
IncludeCertificateChainAndRootCertificate (DWORD) |
Nom et type de valeur Exchange 2003 |
SecurityFlags (valeur 0x002) |
Valeurs et paramètres par défaut |
1=Vrai, 0=Faux (par défaut) |
Explication |
L’attribut d’inclusion de la chaîne de certificats et de la racine ressemble à l’attribut d’inclusion de la chaîne de certificats sans le certificat racine, sauf que, lorsqu’il est défini sur Vrai, il inclut le certificat racine et la chaîne de certificats complète. Lorsque IncludeCertificateChainAndRootCertificate est défini sur Vrai, cela augmente la taille des messages signés et chiffrés plus que ne le fait l’attribut IncludeCertificateChainWithoutRootCertificate. |
Chiffrer les tampons temporaires
Nom et type de valeur Exchange 2010 |
EncryptTemporaryBuffers (DWORD) |
Nom et type de valeur Exchange 2007 |
EncryptTemporaryBuffers (DWORD) |
Nom et type de valeur Exchange 2003 |
SecurityFlags (valeur 0x004) |
Valeurs et paramètres par défaut |
1=Vrai (par défaut), 0=Faux |
Explication |
Par défaut, tous les tampons temporaires côté client utilisés pour enregistrer les données de message sont chiffrés à l’aide d’une clé éphémère et de l’algorithme 3DES. Ce paramétrage permet d’activer ou de désactiver le chiffrement des tampons temporaires. La désactivation du chiffrement des tampons peut améliorer les performances du client Outlook Web App. Toutefois, cela laisse des informations non chiffrées dans le tampon du système local. Avant de désactiver cette fonctionnalité, vérifiez la stratégie de sécurité de votre organisation. |
Inclure le certificat de courrier électronique signé
Nom et type de valeur Exchange 2010 |
SignedEmailCertificateInclusion (DWORD) |
Nom et type de valeur Exchange 2007 |
SignedEmailCertificateInclusion (DWORD) |
Nom et type de valeur Exchange 2003 |
SecurityFlags (valeur 0x008) |
Valeurs et paramètres par défaut |
1=Vrai (par défaut), 0=Faux |
Explication |
Par défaut, Outlook Web App avec le contrôle S/MIME installé inclut des certificats de signature et de chiffrement avec les messages électroniques signés. Lorsque vous désactivez ce paramètre en définissant SignedEmailCertificateInclusion sur Faux, la taille des messages envoyés à partir d’Outlook Web App avec le contrôle S/MIME diminue. Toutefois, les destinataires n’ont pas accès au certificat de chiffrement de l’expéditeur dans le message reçu et doivent se le procurer soit en le récupérant dans un annuaire, soit en s’adressant à l’expéditeur. |
Duplication du courrier électronique Cci chiffré
Nom et type de valeur Exchange 2010 |
BccEncryptedEmailForking (DWORD) |
Nom et type de valeur Exchange 2007 |
BccEncryptedEmailForking (DWORD) |
Nom et type de valeur Exchange 2003 |
SecurityFlags (valeurs 0x040, 0x080) |
Valeurs et paramètres par défaut |
0=Un message chiffré par destinataire de Cci (par défaut) 1=Un message chiffré pour tous les destinataires de Cci 2=Un message chiffré sans duplication Cci |
Explication |
Par défaut, Outlook Web App envoie un message chiffré séparé pour chaque destinataire figurant sur la ligne Cci d’un message chiffré. Cette option offre une sécurité optimale pour les destinataires de Cci d’un message chiffré. En modifiant la valeur de BccEncryptedEmailForking, vous pouvez exiger qu’Outlook Web App crée un message chiffré unique pour tous les destinataires de Cci ou un seul message chiffré sans message séparé pour chaque destinataire de Cci. |
Inclure les fonctionnalités S/MIME dans un message
Nom et type de valeur Exchange 2010 |
IncludeSMIMECapabilitiesInMessage (DWORD) |
Nom et type de valeur Exchange 2007 |
IncludeSMIMECapabilitiesInMessage (DWORD) |
Nom et type de valeur Exchange 2003 |
SecurityFlags (valeur 0x100) |
Valeurs et paramètres par défaut |
1=Vrai, 0=Faux (par défaut) |
Explication |
Lorsque IncludeSMIMECapabilitiesInMessage est défini sur Vrai, Outlook Web App ajoute des attributs aux messages signés et chiffrés sortants qui indiquent les algorithmes de chiffrement et de signature, ainsi que les longueurs de clés, pris en charge. L’activation de cet attribut augmente la taille des messages. Toutefois, son activation peut faciliter, pour certains clients de messagerie, l’interaction avec Outlook Web App. |
Copier les en-têtes des destinataires
Nom et type de valeur Exchange 2010 |
CopyRecipientHeaders (DWORD) |
Nom et type de valeur Exchange 2007 |
CopyRecipientHeaders (DWORD) |
Nom et type de valeur Exchange 2003 |
SecurityFlags (valeur 0x200) |
Valeurs et paramètres par défaut |
1=Vrai, 0=Faux (par défaut) |
Explication |
Lorsque CopyRecipientHeaders est défini sur Vrai, une copie des en-têtes de destinataire De, À et Cc est placée dans la partie signée du message. Cela permet au destinataire de vérifier que ces en-têtes n’ont pas été falsifiés pendant que le message était en transit. L’activation de cette fonctionnalité augmente la taille du message. |
Utiliser uniquement la carte à puce
Nom et type de valeur Exchange 2010 |
OnlyUseSmartCard (DWORD) |
Nom et type de valeur Exchange 2007 |
OnlyUseSmartCard (DWORD) |
Nom et type de valeur Exchange 2003 |
SmartCardOnly (DWORD) |
Valeurs et paramètres par défaut |
1=Vrai, 0=Faux (par défaut) |
Explication |
Lorsque OnlyUseSmartCard est défini sur Vrai, cela force l’utilisation de certificats basés sur carte à puce pour la signature et le déchiffrement lorsque vous utilisez Outlook Web App avec le contrôle S/MIME. Les utilisateurs ne peuvent pas utiliser de certificats ne figurant pas sur une carte à puce. |
Message chiffré par triple traitement
Nom et type de valeur Exchange 2010 |
TripleWrapSignedEncryptedMail (DWORD) |
Nom et type de valeur Exchange 2007 |
TripleWrapSignedEncryptedMail (DWORD) |
Nom et type de valeur Exchange 2003 |
TripleWrap (DWORD) |
Valeurs et paramètres par défaut |
1=Vrai (par défaut), 0=Faux |
Explication |
Lorsque TripleWrapSignedEncryptedMail est défini sur Vrai, les messages électroniques chiffrés qui sont signés numériquement sont entourés de trois couches de protection. Quand un message est entouré de trois couches de protection, le message signé numériquement est chiffré et le message chiffré est signé numériquement. Lorsque cet attribut est défini sur Faux, le message signé numériquement est simplement chiffré ; il n’y a pas de signature numérique supplémentaire pour le message chiffré. Par défaut, cet attribut est défini sur Vrai. Les messages entourés de trois couches de protection offrent le niveau de sécurité le plus élevé pour les messages signés numériquement et chiffrés conformément à la norme S/MIME, mais leur taille est plus importante. |
Utiliser l’identificateur de la clé
Nom et type de valeur Exchange 2010 |
UseKeyIdentifier (DWORD) |
Nom et type de valeur Exchange 2007 |
UseKeyIdentifier (DWORD) |
Nom et type de valeur Exchange 2003 |
UseKeyIdentifier (DWORD) |
Valeurs et paramètres par défaut |
1=Vrai, 0=Faux (par défaut) |
Explication |
Par défaut, lors du chiffrement d’un message électronique, Outlook Web App code le référentiel sécurisé dans lequel est stocké le jeton chiffré de façon asymétrique requis pour déchiffrer le reste du message. Il code le référentiel sécurisé en indiquant l’émetteur et un numéro de série pour chaque certificat du destinataire. Cela peut permettre de localiser le certificat et la clé privée pour le déchiffrement du message. Une autre solution permettant de localiser le certificat et la clé privée pour le déchiffrement du message consiste à utiliser l’identificateur de clé d’un certificat en définissant UseKeyIdentifier sur Vrai. Une paire de clés pouvant être réutilisée dans de nouveaux certificats, l’utilisation de l’identificateur de clé pour les messages électroniques chiffrés permet aux utilisateurs de ne garder que le certificat le plus récent et la clé qui lui est associée, au lieu de tous les anciens certificats, qui ne peuvent être mis en correspondance que par émetteur et numéro de série. Par défaut, étant donné que certains clients de messagerie ne prennent pas en charge la recherche de certificats à l’aide d’un identificateur de clé, Outlook Web App utilise l’émetteur et le numéro de série du certificat de chaque destinataire. Cependant, l’activation de cette fonctionnalité peut faciliter la gestion des messages chiffrés, car elle dispense les utilisateurs de garder des certificats anciens et expirés sur leur système. |
Algorithmes de chiffrement S/MIME
Nom et type de valeur Exchange 2010 |
EncryptionAlgorithms (Reg-SZ) |
Nom et type de valeur Exchange 2007 |
EncryptionAlgorithms (Reg-SZ) |
Nom et type de valeur Exchange 2003 |
EncryptionAlgorithms (Reg_SZ) |
Valeurs et paramètres par défaut |
La clé est une liste des algorithmes de chiffrement symétriques, séparés par des points-virgules, à utiliser pour le chiffrement des messages en cas d’utilisation d’Outlook Web App avec le contrôle S/MIME. Format de liste : {ID d’algorithme bien connu}[:longueur de clé à utiliser]|[,ID d’objet de l’algorithme de remplacement personnalisé]; {ID d’algorithme bien connu}[:longueur de clé à utiliser]|[,ID d’objet de l’algorithme de remplacement personnalisé]; … Algorithmes pris en charge et leurs ALG_ID :
La longueur de clé ne s’applique à des algorithmes de longueur de clé variable que lorsque la longueur de clé n’est pas codée dans l’Id d’algorithme. RC2 est le seul algorithme de ce type dans la liste précédente. ID d’objet de l’algorithme de remplacement personnalisé Vous pouvez fournir votre propre algorithme en l’implémentant avec un fournisseur de services de chiffrement (CSP), en lui affectant un ID d’objet personnalisé et en spécifiant l’ID d’objet à l’aide de la clé EncryptionAlgorithms. Un ID d’objet doit être spécifié avec un ID d’algorithme bien connu. Outlook Web App a besoin d’un ID d’algorithme bien connu pour pouvoir inférer la manière d’utiliser l’algorithme. Par exemple, pour fournir un remplacement personnalisé pour l’algorithme 3DES, vous devez spécifier l’ALG_ID de 3DES (0x6603) et l’ID d’objet personnalisé de l’algorithme de remplacement. Les valeurs de la clé de Registre doivent être listées de la plus longue vers la plus courte longueur de clé, car cet ordre correspond à l’ordre selon lequel elles doivent être utilisées. Par exemple, pour lister les valeurs 3DES, RC2-128, RC2-64, DES, RC2-56 et RC2-40, tapez-les dans l’ordre suivant : 6603;6602:128;6602:64;6601;6602:56;6602:40 Si la clé de registre est présente, les algorithmes spécifiés dans la clé sont toujours utilisés. Si la clé n’est pas présente, Outlook Web App se rabat sur sa liste interne par défaut. Cette liste commence par AES256 sur les ordinateurs exécutant Windows Vista et par 3DES sur les ordinateurs exécutant Windows XP. Les algorithmes AES ne sont utilisés que si l’ordinateur de l’utilisateur les prend en charge. AES n’est pas pris en charge sur Windows XP et les messages chiffrés à l’aide d’AES ne peuvent pas être lus sur des ordinateurs exécutant Windows XP. |
Explication |
Outlook Web App tente d’utiliser l’algorithme le plus puissant avec la longueur de clé disponible la plus importante sur l’ordinateur de l’utilisateur. Si l’algorithme de chiffrement ou la longueur de clé minimale n’est pas disponible sur l’ordinateur de l’utilisateur, Outlook Web App n’autorise pas le chiffrement. |
Algorithme de signature par défaut de S/MIME
Nom et type de valeur Exchange 2010 |
SigningAlgorithms (Reg_SZ) |
Nom et type de valeur Exchange 2007 |
SigningAlgorithms (Reg_SZ) |
Nom et type de valeur Exchange 2003 |
DefaultSigningAlgorithm (reg_SZ) |
Valeurs et paramètres par défaut |
La clé SigningAlgorithms spécifie les algorithmes de signature à utiliser pour la signature de messages à l’aide d’Outlook Web App avec le contrôle S/MIME. Le tableau suivant présente les algorithmes de signature, leur ID et les longueurs de clé prises en charge par chacun d’eux. Format : {ID d’algorithme bien connu} ID d’algorithmes bien connus et leurs longueurs de clés
Si la clé de registre est présente, l’algorithme spécifié dans la clé est toujours utilisé. Si la clé n’est pas présente, Outlook Web App se rabat sur sa liste interne par défaut. Cette liste commence par SHA-1. Les messages signés numériquement à l’aide de CALG_SHA_256 ne peuvent pas être vérifiés sur des ordinateurs exécutant Windows XP. |
Explication |
Cet attribut spécifie l’algorithme de signature numérique à utiliser lors de la signature numérique de messages à l’aide d’Outlook Web App avec le contrôle S/MIME. |
Forcer la mise à niveau de client S/MIME
Nom et type de valeur Exchange 2010 |
ForceSMIMEClientUpgrade (DWORD) |
Nom et type de valeur Exchange 2007 |
ForceSMIMEClientUpgrade (DWORD) |
Nom et type de valeur Exchange 2003 |
Non disponible. Il s’agit d’une nouvelle fonctionnalité d’Exchange 2007. |
Valeurs et paramètres par défaut |
1=Vrai (par défaut), 0=Faux |
Explication |
Lorsque ForceSMIMEClientUpgrade est défini sur Vrai, si la version de contrôle du client sur l’ordinateur de l’utilisateur est antérieure à la version sur le serveur, l’utilisateur doit télécharger et installer le nouveau contrôle avant de pouvoir continuer à utiliser tout formulaire de lecture ou de composition S/MIME. Lorsque la valeur est définie sur Faux, l’utilisateur reçoit un avertissement si le contrôle S/MIME sur son ordinateur est plus ancien que la version du serveur. Toutefois, il est en mesure d’utiliser S/MIME sans mise à jour du contrôle. |
Utiliser l’Éditeur du Registre pour modifier les paramètres de contrôle S/MIME pour Outlook Web App
Des autorisations doivent vous être attribuées avant de pouvoir exécuter cette procédure. Pour voir les autorisations qui vous sont nécessaires, voir Entrée « Éditeur de registre » dans la rubrique Autorisations d'accès client.
.gif "Attention") Attention : |
|---|
| Une modification incorrecte du Registre peut être à l’origine de problèmes graves qui vous obligeront peut-être à réinstaller votre système d’exploitation. Il se peut que les problèmes résultant d’une modification incorrecte du Registre soient impossibles à résoudre. Avant de modifier le Registre, sauvegardez les données importantes. |
Démarrez l’Éditeur du Registre (regedit).
Recherchez la sous-clé de Registre suivante :
HKLM\System\CurrentControlSet\Services\MSExchange OWA\SMIME
Recherchez la clé que vous voulez modifier.
Définissez la clé sur la valeur requise par votre organisation.
Si la clé dont vous avez besoin n’existe pas, créez un nouveau DWORD portant ce nom, puis définissez-le sur la valeur requise par votre organisation.
© 2010 Microsoft Corporation. Tous droits réservés.