Prise en charge d'Outlook Web Access avec le contrôle S/MIME dans votre infrastructure à clé publique

 

Dernière rubrique modifiée : 2006-09-11

Dans un système de sécurité des messages basé sur Exchange 2003, la plupart des fonctionnalités S/MIME sont assurées par l'interaction entre les clients de messagerie électronique et l'infrastructure à clé publique. En tant qu'administrateur d'infrastructures à clé publique, votre principale source d'informations concernant les options et impératifs de configuration reste la documentation de votre infrastructure à clé publique spécifique. En outre, vous devez vous procurer auprès de l'administrateur de clients de messagerie électronique des informations relatives aux conditions que l'infrastructure à clé publique doit remplir pour prendre en charge vos clients de messagerie.

Exchange 2003 offre des fonctionnalités de client de messagerie S/MIME avec Outlook Web Access à l'aide du contrôle S/MIME. La section suivante explique aux administrateurs d'infrastructures à clé publique comment intégrer leur infrastructure avec Outlook Web Access à l'aide du contrôle S/MIME.

Outlook Web Access et certificats numériques

Cette section décrit en détail comment Outlook Web Access avec le contrôle S/MIME interagit avec les certifications numériques dans les domaines suivants :

• Gestion des certificats dans Outlook Web Access avec le contrôle S/MIME.
• Outlook Web Access avec le contrôle S/MIME et récupération des certificats numériques.
• Outlook Web Access avec le contrôle S/MIME et validation des certificats.
• Outlook Web Access avec le contrôle S/MIME et opérations S/MIME.
• Outlook Web Access avec le contrôle S/MIME et cartes à puce.
• Outlook Web Access avec le contrôle S/MIME et fonctionnalités de cryptage S/MIME.

Gestion des certificats dans Outlook Web Access avec le contrôle S/MIME

Le serveur Exchange de l'utilisateur assure la validation de tous les certificats numériques. Lorsque Outlook Web Access avec le contrôle S/MIME est utilisé, le serveur Exchange de l'utilisateur se charge également de la plupart des opérations de gestion portant sur les clés publiques. Cependant, dans le cas de certificats numériques portant sur les clés privées de l'utilisateur, c'est le contrôle S/MIME du système client de l'utilisateur qui récupère le certificat numérique stocké sur le système client de l'utilisateur.

Le fait de confier au serveur Exchange de l'utilisateur la gestion de toutes les opérations de validation des certificats numériques permet de réduire le trafic entre le système client et le serveur Exchange et d'obtenir ainsi des performances plus élevées. La gestion des certificats est simplifiée puisque seul le serveur Exchange de l'utilisateur doit être configuré pour la prise en charge de la validation des certificats. Étant donné que le système client ne fait qu'assurer le stockage des certificats, aucune opération n'est nécessaire au niveau du système client pour permettre la gestion des certificats. Le stockage des certificats numériques comportant la clé privée de l'utilisateur sur le système client permet de garantir que la clé privée ne sera jamais transmise à travers le réseau. Outlook Web Access avec le contrôle S/MIME ne gère pas directement la clé privée. La gestion des clés privées est intégralement assurée par le système d'exploitation. Outlook Web Access avec le contrôle S/MIME interagit avec les fonctionnalités cryptographiques du système d'exploitation. La figure suivante illustre l'architecture d'Outlook Web Access avec le contrôle S/MIME.

Comme l'indique la figure suivante, le traitement des certificats en cas d'utilisation d'Outlook Web Access avec le contrôle S/MIME consiste en une série d'opérations dont les responsables sont clairement définis. Le serveur Exchange de l'utilisateur gère l'ensemble de la validation des certificats et se procure la plupart des certificats numériques pour clés publiques tandis que le système client de l'utilisateur assure le stockage des certificats numériques contenant des clés privées.

Le serveur Exchange de l'utilisateur s'appuie sur le magasin de certificats du système d'exploitation sous-jacent pour toutes les fonctions de gestion des certificats, utilisant le magasin de certificats personnel comme compte LocalSystem. Le magasin de certificats personnel est Mon magasin CryptoAPI dans le profil utilisateur. Étant donné qu'Exchange 2003 requiert Microsoft Windows® 2000 Server ou Windows Server 2003, qui offrent tous deux une fonctionnalité de magasin de certificats personnel, aucune condition spéciale ne doit être remplie par le système d'exploitation pour prendre en charge Outlook Web Access avec le S/MIME sur le serveur Exchange.

Outlook Web Access avec le contrôle S/MIME nécessite les programmes suivants :

• Windows 2000 ou versions ultérieures (pour disposer des fonctionnalités de magasin de certificats personnel en vue du stockage des certificats numériques comportant des clés privées).
• Internet Explorer 6 ou versions ultérieures (pour tirer parti des améliorations de la sécurité).

Bien que les versions de Windows antérieures à Windows 2000 et les navigateurs autres qu'Internet Explorer 6 ou versions supérieures ne puissent pas être utilisées avec Outlook Web Access avec le contrôle S/MIME, elles peuvent l'être avec Outlook Web Access sans contrôle S/MIME.

Outlook Web Access avec le contrôle S/MIME et récupération des certificats numériques

Le serveur Exchange de l'utilisateur s'appuie sur Windows 2000 ou versions ultérieures pour gérer la validation des certificats mais c'est lui qui récupère les certificats numériques pour la plupart des clés publiques. Outlook Web Access avec le contrôle S/MIME récupère quant à lui les certificats numériques des clés privées sur le système client de l'utilisateur.

Recherche des certificats à l'aide d'Outlook Web Access avec le contrôle S/MIME

Lors de l'utilisation d'Outlook Web Access avec le contrôle S/MIME, ce dernier et le serveur Exchange de l'utilisateur recherchent les certificats et effectuent la mise en correspondance sur la base des critères suivants :

• Mise en correspondance des adresses de routage des messages électroniques avec celles qui se trouvent dans le certificat   Le serveur Exchange de l'utilisateur ou Outlook Web Access avec le contrôle S/MIME tente de mettre en correspondance les adresses de routage des messages avec celles qui se trouvent dans le certificat. Il tente tout d'abord de trouver une correspondance entre les adresses de routage et le sujet du certificat. S'il n'y parvient pas, il tente de trouver une correspondance entre les adresses de routage et l'autre sujet du certificat. Si aucune correspondance ne peut être établie, il tente de trouver une correspondance sur la base des adresses proxy SMTP (SMTP, Simple Mail Transfer Protocol) dans l'annuaire. Vous pouvez désactiver la recherche des adresses proxy SMTP en modifiant la valeur CertMatchingDoNotUseProxies dans le Registre.

  Remarque :
  Pour plus d'informations, voir le document sur les Paramètres relatifs au contrôle S/MIME d'Outlook Web Access.

• Détermination des fonctionnalités du certificat   Si plusieurs certificats sont trouvés pour le sujet, l'utilisation de la clé de chaque certificat est analysée pour déterminer les fonctionnalités disponibles, notamment la signature numérique, le cryptage de messages ou les deux. Si le serveur Exchange ou Outlook Web Access avec le contrôle S/MIME trouve un certificat comportant une utilisation de clé unique qui correspond à l'opération en cours, il choisit ce certificat plutôt qu'un certificat à utilisations de clé multiples. Par exemple, si l'opération en cours est une signature numérique et que deux certificats sont trouvés, un certificat comportant une clé servant uniquement aux signatures numériques et un autre dont la clé peut être utilisée pour les signatures numériques et le cryptage, c'est le certificat dont la clé est utilisée uniquement pour les signatures numériques qui sera sélectionné.

• Sélection des certificats sur la base de dates de début et d'expiration   Seuls les certificats numériques considérés comme valides sur la base de leur date de début et de leur date d'expiration sont sélectionnés.

• Analyse des certificats numériques propagés à partir de cartes à puce   Lors de la récupération des clés privées de l'utilisateur, si la valeur SmartCardOnly a été définie sur le serveur Exchange, seuls les certificats numériques propagés depuis les cartes à puce seront analysés.

  Remarque :
  Pour plus d'informations, voir le document sur les Paramètres relatifs au contrôle S/MIME d'Outlook Web Access.

Une fois qu'un certificat numérique a été récupéré, la liste de confiance intégrale du certificat est vérifiée.

Obtention de certificats numériques pour des clés publiques

Lors de la validation d'une signature numérique, le contrôle S/MIME récupère le certificat numérique inclus dans le message signé et l'utilise pour procéder à la validation.

Lorsqu'il récupère les certificats numériques afin de se procurer les clés publiques à partir d'un annuaire afin d'envoyer des messages cryptés, le serveur Exchange de l'utilisateur consulte l'un après l'autre les attributs suivants jusqu'à ce qu'il trouve un certificat numérique valide pour l'opération requise. Dès qu'il y parvient, le processus s'interrompt.

• Attribut userCertificate dans l'objet de l'autre utilisateur dans Active Directory.
• Attribut userSMIMECertificate dans l'objet de l'autre utilisateur dans Active Directory.
• Attribut userCertificate dans l'objet contact de l'autre utilisateur dans Active Directory (situé dans le dossier Contacts dans la Boîte de réception de l'utilisateur sur le serveur Exchange).
• Attribut userSMIMECertificate dans l'objet contact de l'autre utilisateur dans Active Directory (situé dans le dossier Contacts dans la Boîte de réception de l'utilisateur sur le serveur Exchange).

Remarque :
Bien qu'Outlook Web Access puisse utiliser un certificat numérique joint à un élément dans le dossier Contacts dans Exchange, vous ne pouvez pas ajouter de certificat numérique à un élément de ce dossier à l'aide d'Outlook Web Access. Vous devez utiliser Outlook à la place.

Si le serveur Exchange de l'utilisateur ne parvient pas à trouver un certificat pour la clé publique d'un autre utilisateur à l'un de ces emplacements, il émet un avertissement. Lorsqu'il essaie d'envoyer un message électronique crypté, l'expéditeur a le choix entre envoyer un message non crypté et envoyer un message crypté accompagné d'un avertissement signalant que certains utilisateurs peuvent ne pas être en mesure de lire le message.

Obtention de certificats numériques pour les clés privées d'un utilisateur

Lorsqu'il doit choisir un certificat numérique pour se procurer la clé privée de l'utilisateur, Outlook Web Access avec le contrôle S/MIME recherche dans le magasin de certificats personnel de l'utilisateur actuellement connecté. Outlook Web Access avec le contrôle S/MIME cherche parmi les certificats présents dans le magasin de certificats jusqu'à ce qu'il trouve un certificat numérique valide pour l'opération requise. S'il trouve un certificat logiciel et un certificat matériel, y compris sur des cartes à puce, il l'utilise toujours de préférences aux autres. Si la valeur SmartCardOnly a été définie sur le serveur Exchange, seuls les certificats numériques propagés depuis les cartes à puce seront analysés.

Si Outlook Web Access avec le contrôle S/MIME ne parvient pas à trouver de certificat pour la clé privé de l'utilisateur, il émet un avertissement. Lorsque le destinataire d'un message électronique crypté tente de lire le message, il ne peut pas le décrypter ni l'afficher. Lors de l'envoi d'un message numérique signé, Outlook Web Access affiche un message d'avertissement.

Remarque :
En cas d'utilisation de certificats basés sur du matériel, les utilisateurs doivent activer le périphérique pour que l'accès aux certificats soit possible. Par exemple, si vous utilisez une carte à puce, il faut que cette carte soit insérée dans le lecteur et que le code confidentiel soit saisi pour que le certificat puisse être utilisé.

Outlook Web Access avec le contrôle S/MIME et validation des certificats

Le processus de sélection d'un certificat numérique comporte une étape de vérification de la validité de ce certificat. Le serveur Exchange s'appuie sur les fonctionnalités de gestion des certificats du système d'exploitation Windows sous-jacent pour procéder à la validation des certificats. Une description détaillée du processus de vérification des certificats est disponible dans l'article sur la résolution des problèmes d'état et de révocation de certificats. Lorsque l'administrateur d'infrastructures à clé publique envisage d'effectuer une vérification des certificats dans Outlook Web Access avec le contrôle S/MIME, il doit tenir compte des éléments suivants :

• Vérification de la période de validité (effectuée sur tous les certificats).
• Vérification de la révocation des certificats (effectuée automatiquement sauf si la vérification de la liste de révocation de certificats a été désactivée à l'aide du paramètre de Registre DisableCRLCheck).
• Vérification de confiance (effectuée si l'Autorité de certification [CA] responsable de l'émission du certificat ne figure pas dans le magasin de certificats du système qui a récupéré le certificat).

Vérification de la limite de validité

Lorsqu'une Autorité de certification crée un certificat, celui-ci est marqué d'une période de validité. Cette période est spécifiée à l'aide des attributs Valide à partir du et Valide jusqu'au sur le certificat. Ces deux attributs définissent un intervalle de temps pendant lequel le certificat est valide.

Lorsqu'un certificat numérique est récupéré, le serveur Exchange de l'utilisateur vérifie que la date du jour se situe dans l'intervalle de temps spécifié par les attributs Valide à partir du et Valide jusqu'au. Si le certificat est arrivé à expiration parce que la date du jour se situe après la date indiquée dans Valide jusqu'au ou s'il n'est pas encore valide parce la date du jour se situe avant celle qui est indiquée dans Valide à partir du, Outlook Web Access affiche un message d'avertissement signalant que le certificat n'est pas valide.

Vérification de révocation des certificats

Une liste de révocation de certificats (CRL, Certificate Revocation List) est une liste des certificats valides si l'on s'en tient à leur période de validité mais qui ont été rendus invalides par l'Autorité de certification. L'Autorité de certification donne accès à cette liste via des points de distribution de CRL, dont l'emplacement est spécifié dans le certificat numérique. Cette liste peut être obtenue via HTTP, LDAP (Lightweight Directory Access Protocol) ou autres par des systèmes qui ont besoin de valider des certificats numériques à partir de cette infrastructure à clé publique.

Les administrateurs d'infrastructures à clé publique peuvent utiliser les CRL pour invalider des certificats avant que leur période de validité n'ait expiré. Cette révocation a lieu dans les cas où le certificat a été compromis (suite à la perte ou à la divulgation de la clé privée du détenteur du certificat) ou parce que l'émetteur du certificat ne peut plus attester du détenteur du certificat (comme dans le cas d'un licenciement).

Conformément à la norme X.509, tout client de messagerie S/MIME peut vérifier si un certificat numérique a fait l'objet d'une révocation. Une autre méthode permet d'effectuer cette vérification. Elle consiste à utiliser une CRL émise par l'infrastructure à clé publique. Le serveur Exchange de l'utilisateur procède à une vérification de la CRL en utilisant les fonctionnalités cryptographiques de Windows 2000 ou versions ultérieures. Par défaut, pour Outlook Web Access avec le contrôle S/MIME, la vérification de la CRL est activée. Vous pouvez toutefois la désactiver en définissant la valeur DisableCRLCheck du serveur Exchange de l'utilisateur sur True. Pour plus d'informations, voir le document sur les Paramètres relatifs au contrôle S/MIME d'Outlook Web Access.

Le processus de récupération d'une CRL pouvant être long, une fois qu'un système a obtenu une CRL de l'infrastructure à clé publique, il la met en cache jusqu'à ce qu'elle arrive à expiration. En outre, les administrateurs Exchange peuvent utiliser les paramètres de Registre RevocationURLRetrievalTimeout et CertURLRetrievalTimeout pour configurer la durée allouée à l'opération de récupération des CRL avant qu'une erreur ne soit renvoyée. Pour plus d'informations, voir le document sur les Paramètres relatifs au contrôle S/MIME d'Outlook Web Access.

Une fois que le serveur Exchange de l'utilisateur a obtenu un certificat numérique et vérifié sa période de validité, il effectue les opérations suivantes.

1. Il vérifie si le certificat apparaît dans la CRL. Il vérifie si la vérification de CRL est activée pour ce certificat.
2. Si c'est le cas, il recherche une copie du CRL dans le cache.
3. S'il ne parvient pas à trouver une copie du CRL dans le cache, il cherche à contacter le point de distribution de CRL afin d'obtenir une CRL mise à jour.
4. S'il ne parvient pas à obtenir de CRL, il prend les mesures spécifiées par le paramètre de Registre CheckCRL. Par défaut, Outlook Web Access ne signale pas d'erreur et autorise l'envoi du message.
5. Si la valeur du paramètre de Registre CheckCRL a été modifiée par rapport à la valeur par défaut, Outlook Web Access signale une erreur mais autorise l'envoi du message. Pour plus d'informations sur le paramètre de Registre CheckCRL, voir le document sur les Paramètres relatifs au contrôle S/MIME d'Outlook Web Access.
6. Si le serveur Exchange de l'utilisateur trouve la CRL ou une copie mise en cache de la CRL, il vérifie si le certificat en cours y apparaît.
   • Si c'est le cas, il le marque comme invalide et ne l'utilise pas.
   • Sinon, il présume que le certificat est valide et l'utilise.

Vérification d'approbation

La vérification de confiance est effectuée sur tous les certificats numériques. Le serveur Exchange de l'utilisateur fait appel aux fonctionnalités cryptographiques du système d'exploitation pour essayer de valider le certificat en validant chaque certificat de la chaîne jusqu'à ce qu'il atteigne un certificat racine approuvé. Dans la plupart des cas, il se procure les certificats intermédiaires via le chemin d'accès aux informations de l'autorité spécifié dans le certificat jusqu'à ce qu'il trouve un certificat racine approuvé. Les certificats intermédiaires peuvent également être inclus dans des messages électroniques à signature numérique. Si le système trouve un certificat racine approuvé, la chaîne de ce certificat numérique est considérée comme valide et de confiance et peut donc être utilisée.

S'il ne parvient pas à trouver de certificat racine approuvé ou si le certificat numérique obtenu initialement se trouve dans le magasin de certificats non autorisés du serveur Exchange, ce certificat sera considéré comme invalide et non approuvé. Outlook Web Access avec le contrôle S/MIME signalera une erreur s'il y a tentative d'utilisation de ce certificat non autorisé.

En tant qu'administrateur d'infrastructure à clé publique, vous pouvez décider d'approuver des certificats numériques émis par d'autres infrastructures afin d'éviter les erreurs qui se produisent en cas d'utilisation de certificats numériques émis par des infrastructures à clé publique dont le certificat racine n'est pas approuvé. Vous pouvez choisir d'approuver le certificat racine d'une autre infrastructure à clé publique mais cela revient implicitement à approuver chaque certificat émis par cette infrastructure à clé publique. Au lieu de cela, vous pouvez mettre en place une stratégie de certification croisée afin de n'approuver qu'un ensemble de certificats spécifiques provenant de cette autre infrastructure à clé publique.

Pour obtenir des informations sur les risques et les avantages de chaque stratégie et sur procédure de mise en œuvre d'une certification croisée dans votre infrastructure à clé publique, voir la documentation qui l'accompagne. Pour plus d'informations sur la certification croisée dans Windows Server 2003, voir le document sur la planification et la mise en œuvre de la certification croisée et de la subordination qualifiée dans Windows Server 2003. En général, il est conseillé d'avoir recours à une stratégie de certification croisée.

Quelle que soit la stratégie spécifique à laquelle vous avez recours, veillez à que les certificats racines appropriés soient disponibles sur le serveur Exchange pour que la vérification de confiance puisse avoir lieu. Ces certificats racines peuvent être ajoutés manuellement ou propagés à l'aide de la stratégie de groupe. Il est recommandé d'utiliser la stratégie de groupe chaque fois que possible.

Pour obtenir des informations sur l'utilisation de la stratégie de groupe pour propager des certificats numériques, voir la documentation de Windows Server 2003. Pour des informations sur la procédure d'ajout manuel de certificats numériques au système d'un utilisateur, voir la rubrique sur la Résolution des problèmes de S/MIME dans Exchange Server 2003.

Une fois que la période de validité et la confiance d'un certificat numérique ont été confirmées, le certificat est reconnu par le serveur Exchange comme valide et peut être utilisé pour les signatures numériques et le cryptage, selon les motifs pour lesquels le certificat a été émis.

Outlook Web Access avec le contrôle S/MIME et opérations S/MIME

Cette section décrit les opérations S/MIME suivantes :

• Signatures numériques dans Outlook Web Access avec le contrôle S/MIME
• Opération de cryptage dans Outlook Web Access avec le contrôle S/MIME
• Signatures numériques et cryptage dans Outlook Web Access avec le contrôle S/MIME

Signatures numériques dans Outlook Web Access avec le contrôle S/MIME

Cette section décrit les opérations suivantes :

• Envoi d'un message électronique signé numériquement
• Validation d'un message électronique signé numériquement

Envoi d'un message électronique signé numériquement

Pour envoyer un message électronique signé numériquement, Outlook Web Access doit obtenir la clé privée de l'expéditeur. Le système client qui exécute Outlook Web Access (et non le serveur Exchange de l'utilisateur) est chargé de récupérer le certificat numérique et la clé privée.

Remarque :

Cette séquence utilise des messages signés en clair, ce qui est le cas par défaut pour Outlook Web Access avec le contrôle S/MIME. Ce réglage est contrôlé par le paramètre de Registre ClearSign sur le serveur Exchange de l'expéditeur. Par défaut, ce paramètre est activé. Pour plus d'informations sur le paramètre de Registre ClearSign, voir le document sur les Paramètres relatifs au contrôle S/MIME d'Outlook Web Access.

Lors de l'envoi d'un message électronique signé numériquement, les opérations suivantes se produisent :

1. Le message est capturé (opération effectuée par le système client).
2. La valeur de hachage du message est calculée à l'aide de l'algorithme spécifié par la clé defaultSigningAlgorithms (opération effectuée par le système client et le serveur Exchange de l'utilisateur).
   Pour obtenir des informations détaillées sur le paramètre de Registre defaultSigningAlgorithms, voir le document sur les Paramètres relatifs au contrôle S/MIME d'Outlook Web Access.
3. La clé privée de l'expéditeur est extraite du certificat numérique de l'expéditeur (opération effectuée par le système client).
4. Le certificat numérique de l'expéditeur est vérifié (opération effectuée par le serveur Exchange de l'utilisateur).
5. La valeur de hachage est cryptée à l'aide de la clé privée de l'expéditeur (opération effectuée par le système client et le serveur Exchange de l'utilisateur).
6. La valeur de hachage cryptée est ajoutée au message sous la forme d'une signature numérique (opération effectuée par le système client).
7. Le message est envoyé (opération effectuée par le système client).

Validation d'un message électronique signé numériquement

Pour valider un message électronique signé numériquement, Outlook Web Access doit obtenir la clé publique de l'expéditeur. C'est le serveur Exchange du destinataire qui est chargé d'obtenir le certificat numérique et la clé publique.

Lors de la validation d'un message électronique signé numériquement, les opérations suivantes se produisent :

1. Le message est reçu (opération effectuée le serveur Exchange de l'utilisateur).
2. La signature numérique contenant la valeur de hachage cryptée est extraite du message (opération effectuée par le système client)
3. Le message est récupéré (opération effectuée par le système client).
4. La valeur de hachage du message est calculée (opération effectuée par le système client et le serveur Exchange de l'utilisateur).
5. La clé publique de l'expéditeur est extraite du message électronique (opération effectuée par le système client).
6. La valeur de hachage est décryptée à l'aide de la clé publique de l'expéditeur (opération effectuée par le système client).
7. La valeur de hachage décryptée est comparée à la valeur de hachage produite lors de la réception (opération effectuée par le système client).
8. Si les valeurs correspondent, cela signifie que le message n'a pas été modifié en cours de transit (vérification effectuée par le système client).
9. Le certificat numérique de l'expéditeur est vérifié (opération effectuée par le serveur Exchange de l'utilisateur).

   Remarque :
   Le message s'affiche pendant la validation du certificat afin d'améliorer les performances de lecture des messages électroniques signés numériquement.

Opération de cryptage dans Outlook Web Access avec le contrôle S/MIME

Cette section décrit les opérations suivantes :

• Envoi d'un message électronique crypté
• Affichage d'un message électronique crypté

Envoi d'un message électronique crypté

Pour envoyer un message électronique signé numériquement, Outlook Web Access doit obtenir la clé publique du destinataire. C'est le serveur Exchange de l'expéditeur qui est chargé d'obtenir le certificat numérique et la clé publique.

Lors de l'envoi d'un message électronique crypté, les opérations suivantes se produisent :

1. Le message est capturé (opération effectuée par le système client).
2. La clé publique est extraite du certificat numérique du destinataire (opération effectuée par le serveur Exchange de l'utilisateur).
3. Le certificat numérique du destinataire est vérifié (opération effectuée par le serveur Exchange de l'utilisateur).
4. Une clé de session symétrique à usage unique est générée (opération effectuée par le système client).
5. L'opération de cryptage est effectuée sur le message à l'aide de la clé de session (opération effectuée par le système client).
6. La clé de session est cryptée à l'aide de la clé publique du destinataire (opération effectuée par le système client).
7. La clé de session cryptée est ajoutée au message crypté (opération effectuée par le système client).
8. Le message est envoyé (opération effectuée par le système client).

Affichage d'un message électronique crypté

Pour afficher un message électronique crypté, Outlook Web Access doit obtenir la clé privée du destinataire. Le système client qui exécute Outlook Web Access (et non le serveur Exchange de l'utilisateur) est chargé de récupérer le certificat numérique et la clé privée.

Lors de l'affichage d'un message électronique crypté, les opérations suivantes se produisent :

1. Le message est reçu (opération effectuée le serveur Exchange de l'utilisateur).
2. Le message crypté et la clé de session cryptée sont extraits du message (opération effectuée par le système client).
3. La clé privée est extraite du certificat numérique du destinataire (opération effectuée par le système client).
4. La clé de session est décryptée à l'aide de la clé privée du destinataire (opération effectuée par le système client).
5. Le message est décrypté à l'aide de la clé de session décryptée (opération effectuée par le système client).
6. Le message décrypté est envoyé au destinataire (opération effectuée par le système client).

Signatures numériques et cryptage dans Outlook Web Access avec le contrôle S/MIME

Cette section décrit les opérations suivantes :

• Envoi d'un message électronique crypté et signé numériquement
• Affichage d'un message électronique crypté et signé numériquement

Envoi d'un message électronique crypté et signé numériquement

Pour envoyer un message électronique crypté et signé numériquement, Outlook Web Access doit obtenir la clé privée de l'expéditeur et la clé publique du destinataire. Le système client qui exécute Outlook Web Access (et non le serveur Exchange de l'utilisateur) est chargé de récupérer le certificat numérique et la clé privée de l'expéditeur. Le serveur Exchange de l'expéditeur s'occupe quant à lui d'obtenir le certificat numérique et la clé publique du destinataire.

Lors de l'envoi d'un message électronique crypté et signé numériquement, les opérations suivantes se produisent :

Remarque :

Cette séquence décrit un processus dans lequel le message est signé, crypté puis resigné. Ce processus, appelé « triple traitement », est le processus par défaut mis en œuvre par Outlook Web Access avec le contrôle S/MIME. Ce réglage est contrôlé par le paramètre de Registre TripleWrap sur le serveur Exchange de l'expéditeur. Par défaut, ce paramètre est activé. Pour plus d'informations sur le paramètre de Registre TripleWrap, voir le document sur les Paramètres relatifs au contrôle S/MIME d'Outlook Web Access.

1. Le message est capturé (opération effectuée par le système client).
2. La valeur de hachage du message est calculée (opération effectuée par le système client).
3. La clé privée de l'expéditeur est extraite du certificat numérique de l'expéditeur (opération effectuée par le système client).
4. Le certificat numérique de l'expéditeur est vérifié (opération effectuée par le serveur Exchange de l'utilisateur).
5. La clé publique est extraite du certificat numérique du destinataire (opération effectuée par le serveur Exchange de l'utilisateur).
6. Le certificat numérique du destinataire est vérifié (opération effectuée par le serveur Exchange de l'utilisateur).
7. La valeur de hachage est cryptée à l'aide de la clé privée de l'expéditeur (opération effectuée par le système client).
8. La valeur de hachage cryptée est ajoutée au message sous la forme d'une signature numérique (opération effectuée par le système client et le serveur Exchange de l'utilisateur).
9. Une clé de session symétrique à usage unique est générée (opération effectuée par le système client).
10. L'opération de cryptage est effectuée sur le message à l'aide de la clé de session (opération effectuée par le système client).
11. La clé de session est cryptée à l'aide de la clé publique du destinataire (opération effectuée par le système client).
12. La clé de session cryptée est ajoutée au message crypté (opération effectuée par le serveur Exchange de l'utilisateur).
13. La valeur de hachage du message avec la clé de session cryptée est calculée (opération effectuée par le système client).
14. La valeur de hachage est cryptée à l'aide de la clé privée de l'expéditeur (opération effectuée par le système client).
15. La valeur de hachage cryptée est ajoutée au message sous la forme d'une signature numérique (opération effectuée par le système client et le serveur Exchange de l'utilisateur).
16. Le message est envoyé (opération effectuée par le système client).

Affichage d'un message électronique crypté et signé numériquement

Pour afficher un message électronique crypté et signé numériquement, Outlook Web Access doit obtenir la clé privée de l'expéditeur afin d'afficher le message et la clé publique du destinataire pour en vérifier la signature. Le système client qui exécute Outlook Web Access (et non le serveur Exchange de l'utilisateur) est chargé de récupérer le certificat numérique et la clé privée du destinataire. Le serveur Exchange de l'expéditeur s'occupe quant à lui d'obtenir le certificat numérique et la clé publique de l'expéditeur.

Lors de l'envoi d'un message électronique crypté et signé numériquement, les opérations suivantes se produisent :

Remarque :

Cette séquence décrit des messages qui ont fait l'objet d'un triple traitement, qui est le processus mis en œuvre par défaut pour Outlook Web Access avec le contrôle S/MIME. Ce réglage est contrôlé par le paramètre de Registre TripleWrap sur le serveur Exchange de l'expéditeur. Par défaut, ce paramètre est activé. Pour plus d'informations sur le paramètre de Registre TripleWrap, voir le document sur les Paramètres relatifs au contrôle S/MIME d'Outlook Web Access.

1. Le message est reçu (opération effectuée le serveur Exchange de l'utilisateur).
2. La signature numérique contenant la valeur de hachage cryptée du message avec la clé de session cryptée est extraite du message (opération effectuée par le système client)
3. Le message et la clé de session cryptée sont extraits du message (opération effectuée par le système client).
4. La valeur de hachage du message avec la clé de session cryptée est calculée (opération effectuée par le système client).
5. La clé publique de l'expéditeur est extraite du message (opération effectuée par le serveur Exchange de l'utilisateur).
6. La valeur de hachage du message avec la clé de session cryptée est décryptée à l'aide de la clé publique de l'expéditeur (opération effectuée par le système client).
7. La valeur de hachage décryptée est comparée à la valeur de hachage du message avec la clé de session cryptée produite à la réception (opération effectuée par le système client).
8. Si les valeurs correspondent, cela signifie que le message n'a pas été modifié en cours de transit (vérification effectuée par le système client).
9. Le message crypté et la clé de session cryptée sont extraits du message (opération effectuée par le système client).
10. La clé privée est extraite du certificat numérique du destinataire (opération effectuée par le système client).
11. La clé de session est décryptée à l'aide de la clé privée du destinataire (opération effectuée par le système client).
12. Le message est décrypté à l'aide de la clé de session décryptée (opération effectuée par le système client).
13. La signature numérique contenant la valeur de hachage cryptée est extraite du message (opération effectuée par le système client)
14. La valeur de hachage du message est calculée (opération effectuée par le système client).
15. La valeur de hachage est décryptée à l'aide de la clé publique de l'expéditeur (opération effectuée par le système client).
16. La valeur de hachage décryptée est comparée à la valeur de hachage produite lors de la réception (opération effectuée par le système client).
17. Si les valeurs correspondent, cela signifie que le message n'a pas été modifié en cours de transit (vérification effectuée par le système client).
18. Le message décrypté est envoyé au destinataire (opération effectuée par le système client).
19. Le certificat numérique de l'expéditeur est vérifié (opération effectuée par le serveur Exchange de l'utilisateur).

Remarque :
Le message s'affiche pendant la validation du certificat afin d'améliorer les performances de lecture des messages électroniques signés numériquement.

Outlook Web Access avec le contrôle S/MIME et cartes à puce

Les administrateurs d'infrastructures à clé publique peuvent utiliser leurs cartes à puce pour stocker des certificats numériques et des clés privées à l'aide d'Outlook Web Access avec le contrôle S/MIME. Les cartes à puce sont idéales pour Outlook Web Access avec le contrôle S/MIME lorsqu'il est installé sur plusieurs systèmes clients.

Étant donné qu'Outlook Web Access avec le contrôle S/MIME s'appuie sur Windows 2000 ou versions ultérieures, la prise en charge des certificats numériques pour les cartes à puce dépend directement de la prise en charge assurée par le système d'exploitation. Avant de mettre en œuvre la prise en charge des cartes à puce dans votre infrastructure à clé publique, consultez la documentation de Windows 2000 ou des versions ultérieures. Les informations suivantes portent spécifiquement sur l'intégration de la prise en charge des cartes à puce dans Outlook Web Access avec le contrôle S/MIME. Elles viennent compléter la documentation de votre infrastructure à clé publique et celle de Windows 2000 et versions ultérieures.

Fonctionnement d'Outlook Web Access avec le contrôle S/MIME avec les cartes à puce

La prise en charge des cartes à puces dans Outlook Web Access avec le contrôle S/MIME est assurée par le système d'exploitation que le client exécute. Ce dernier intègre les cartes à puce de manière transparente dans ses fonctionnalités de gestion des certificats si bien qu'Outlook Web Access n'a pas à manipuler ni gérer ces certificats. Outlook Web Access avec le contrôle S/MIME vérifie si des changements se produisent sur la carte à puce et indique au système d'exploitation à quel moment des certificats numériques supplémentaires doivent être déplacés de la carte à puce vers le magasin de certificats personnel. En outre, il supprime ces certificats lorsque l'utilisateur se déconnecte.

Lorsque la carte à puce est insérée, une copie du certificat est copiée dans le magasin de certificats personnel et le certificat numérique est déverrouillé à l'aide de la clé privée de l'utilisateur. Le certificat numérique est donc placé au même endroit que s'il s'agissait d'un certificat logiciel. Les applications n'ont pas besoin d'exécuter d'opérations spéciales pour utiliser des certificats basés sur cartes à puce puisque le système d'exploitation Windows gère toutes les opérations relatives à ce type de certificat.

Pour utiliser des cartes à puce avec Outlook Web Access, veillez à ce que les certificats numériques émis offrent des fonctionnalités de signature numérique et de cryptage, selon les besoins de votre mise en œuvre.

Vous pouvez configurer Outlook Web Access avec le contrôle S/MIME pour qu'il ne demande que des certificats numériques basés sur cartes à puce en définissant le paramètre de Registre SmartCardOnly sur le serveur Exchange de l'utilisateur. Par défaut, ce paramètre n'est pas activé. Pour plus d'informations sur le paramètre de Registre SmartCardOnly, voir le document sur les Paramètres relatifs au contrôle S/MIME d'Outlook Web Access.

Prise en charge des services Terminal Server

Le client Bureau à distance fourni avec Windows Server 2003 prend en charge la redirection de carte à puce. Vous pouvez utiliser, au sein de la session de terminal, des cartes à puces qui sont insérées dans un lecteur relié au client Bureau à distance, tel qu'une borne d'accès à Internet.

La redirection de carte à puce peut être utilisée avec Outlook Web Access avec le contrôle S/MIME pour permettre aux utilisateurs d'avoir recours à des certificats basés sur carte à puce dans une session de terminal.

Le client Bureau à distance Windows Server 2003 impose des restrictions quant aux combinaisons serveur/client permettant la redirection de carte à puce. Le tableau 6.1 fournit la liste des combinaisons serveur/client prises en charge lors de l'utilisation du client Bureau à distance Windows Server 2003 pour la redirection de carte à puce.

Tableau 6.1   Plates-formes serveur et client prises en charge lors de l'utilisation du client Bureau à distance Windows Server 2003 pour la redirection de carte à puce

Système client exécutant Bureau à distance Windows Server 2003	Système serveur exécutant les services Bureau à distance
Windows XP	Bureau à distance Windows XP
Windows XP	Windows Server 2003
Windows 2000	Bureau à distance Windows XP
Windows 2000	Windows Server 2003
Windows Server 2003	Bureau à distance Windows XP
Windows Server 2003	Windows Server 2003

Comme l'indique le tableau 6.1, le serveur assurant les serveurs Terminal Server doit exécuter Windows XP ou Windows Server 2003. Windows 2000, Windows XP, et Windows Server 2003 peuvent tous être utilisés comme plates-formes clientes pour exécuter Bureau à distance Windows Server 2003. Aucune autre version de Windows ne peut être utilisée avec le client Bureau à distance Windows Server 2003 pour assurer la redirection de carte à puce. Pour plus d'informations sur la redirection de carte à puce, voir la documentation du client Bureau à distance Windows Server 2003.

Outlook Web Access avec le contrôle S/MIME et fonctionnalités de cryptage S/MIME.

Lorsque vous utilisez Outlook Web Access avec le contrôle S/MIME, vous pouvez obliger les utilisateurs à crypter les messages électroniques selon un algorithme de cryptage spécifique. Plutôt que de faire appel uniquement aux fonctionnalités de cryptage S/MIME détaillées dans le certificat de cryptage de l'utilisateur, Outlook Web Access avec le contrôle S/MIME passe en revue les informations contenues dans le Registre du serveur Exchange de l'expéditeur afin de déterminer l'algorithme et le niveau de cryptage à utiliser. Ceci vous permet d'appliquer la stratégie spécifique de votre organisation en matière de cryptage des messages électroniques. Le paramètre de Registre EncryptionAlgorithms régit le choix de l'algorithme de cryptage. Pour plus d'informations sur le paramètre de Registre EncryptionAlgorithms, voir le document sur les Paramètres relatifs au contrôle S/MIME d'Outlook Web Access.

Si le serveur Exchange de l'expéditeur ne parvient pas à obtenir pour un destinataire un certificat de cryptage dont les fonctionnalités correspondent à celles requises dans le Registre, Outlook Web Access avec le contrôle S/MIME gère le message selon le paramètre de Registre AlwaysEncrypt. Si AlwaysEncrypt n'est pas activé, ce qui est le cas par défaut, l'expéditeur a encore la possibilité d'envoyer le message non crypté à ce destinataire. Sinon, l'expéditeur ne peut pas envoyer le message. Pour plus d'informations sur le paramètre de Registre AlwaysEncrypt, voir le document sur les Paramètres relatifs au contrôle S/MIME d'Outlook Web Access. Si Outlook Web Access avec le contrôle S/MIME trouve un certificat de cryptage pour le destinataire mais que ce certificat ne prend pas en charge l'algorithme spécifié ou qu'il le fait à un autre niveau de cryptage, il procède comme s'il n'avait pas trouvé de certificat. Le message sera alors géré conformément au paramètre AlwaysEncrypt.

Prise en charge de messages S/MIME provenant d'autres organisations

Lorsque vous utilisez Outlook Web Access avec le contrôle S/MIME pour échanger des messages électroniques S/MIME avec des utilisateurs appartenant à d'autres organisations, le serveur Exchange de l'utilisateur effectue des opérations de validation de certification sur les messages, au nom de l'utilisateur. Pour que des messages S/MIME provenant d'autres organisations soient validés, le serveur Exchange de l'utilisateur doit valider l'ensemble de la chaîne de certificats jusqu'à un certificat racine approuvé. Si vous avez l'intention d'utiliser S/MIME pour échanger des messages électroniques avec d'autres organisations et souhaitez valider les certificats de ces organisations afin de valider la signature numérique des messages, vous devez mettre en œuvre la confiance dans ces certificats dans votre infrastructure à clé publique.

Exchange 2003 peut approuver le certificat en approuvant le certificat racine de l'émetteur ou en procédant à une certification croisée avec votre infrastructure à clé publique. L'administrateur Exchange peut approuver le certificat racine de l'émetteur en ajoutant ce certificat dans le dossier Autorités de certification racine de confiance dans le magasin de certificats de l'ordinateur local du serveur Exchange. Consultez pour cela l'administrateur Exchange. Pour plus d'informations, notamment sur la procédure détaillée d'importation d'un certificat à certification croisée, voir la rubrique sur l'Impossible de vérifier les signatures numériques de l'expéditeur lorsque le certificat numérique de l'Autorité de certification racine de l'expéditeur ne figure pas dans le magasin de certificats de l'ordinateur local sur le serveur Exchange du destinataire.

Bien que l'ajout du certificat racine de l'émetteur permette de remédier au problème, il entraîne implicitement l'approbation de tous les certificats émis par cette infrastructure à clé publique. Le niveau d'approbation risque alors dépasser le plafond toléré aux termes de la stratégie de sécurité de votre organisation. L'autre solution consiste à ne procéder à une certification croisée que pour les certificats acceptables de l'infrastructure à clé publique de l'autre organisation en émettant un certificat à partir de votre infrastructure à clé publique et en l'ajoutant au dossier Certificats personnels approuvés dans le magasin de certificats de l'ordinateur local sur le serveur Exchange de l'utilisateur.

Pour obtenir des informations sur la procédure de mise en œuvre de la certification croisée, voir la documentation qui accompagne votre infrastructure à clé publique. Pour plus d'informations sur la mise en œuvre de la certification croisée dans Windows Server 2003, voir la rubrique sur la planification et la mise en œuvre de la certification croisée et de la subordination qualifiée dans Windows Server 2003 (https://go.microsoft.com/fwlink/?LinkId=17806).

Le serveur Exchange doit non seulement approuver le certificat racine de l'émetteur d'un certificat mais aussi accéder aux éventuels certificats intermédiaires et réussir à les valider. Selon la façon dont l'administrateur d'infrastructure à clé publique de l'autre organisation a choisi de configurer l'infrastructure, ces certificats intermédiaires peuvent être inclus dans des messages numériques signés ou être accessibles à partir d'un emplacement spécifié dans le paramètre d'accès aux informations de l'Autorité d'un certificat numérique. Pour permettre l'accès aux certificats intermédiaires, l'administrateur Exchange doit s'assurer que le serveur Exchange de l'utilisateur peut se connecter et récupérer les certificats accessibles via le paramètre d'accès aux informations de l'Autorité d'un certificat numérique. Pour valider des certificats intermédiaires, l'administrateur Exchange doit s'assurer que le serveur Exchange de l'utilisateur peut se connecter au point de distribution de la liste de révocation de certificats et vérifier que cette dernière est spécifiée dans le certificat numérique. Ainsi, pour que le serveur Exchange d'un utilisateur puisse accéder aux certificats intermédiaires et les valider, il faut que l'administrateur Exchange garantisse la connectivité entre le serveur Exchange et les emplacements spécifiés dans les paramètres relatifs aux accès aux informations de l'Autorité et au point de distribution de la liste de révocation de certificats du certificat numérique. Pour la plupart des organisations, cet emplacement correspond à un serveur proxy situé les serveurs Exchange et l'Internet. L'administrateur Exchange doit veiller à ce que les logiciels clients proxy appropriés soient installés et configurés. Si vous ne parvenez pas à accéder aux certificats intermédiaires pour les valider, demandez à l'administrateur Exchange de désactiver la vérification de la liste de révocation de certificats à l'aide de la clé de Registre disableCRLCheck. Pour plus d'informations sur ce paramètre, voir le document sur les Paramètres relatifs au contrôle S/MIME d'Outlook Web Access.

Pour plus d'informations, l'administrateur d'Exchange peut se référer à la section sur la configuration des serveurs Exchange dans la rubrique sur la Mise en œuvre d'Outlook Web Access avec le contrôle S/MIME.

Configuration de la gestion des certificats intermédiaires dans votre infrastructure à clé publique

Par défaut, les messages électroniques envoyés à l'aide d'Outlook Web Access avec le contrôle S/MIME ne comportent que les certificats de signature et de cryptage. Le certificat racine et les certificats intermédiaires ne sont pas inclus. Ce paramètre est configurable à l'aide de la clé de Registre SecurityFlags. Pour plus d'informations sur ce paramètre, voir le document sur les Paramètres relatifs au contrôle S/MIME d'Outlook Web Access.

Par défaut, Outlook Web Access avec le contrôle S/MIME envoie uniquement les certificats de signature et de cryptage. De ce fait, il est recommandé de configurer l'infrastructure à clé publique pour qu'elle utilise le paramètre d'accès aux informations de l'Autorité spécifié dans le certificat et de permettre l'accès public aux certificats intermédiaires via LDAP ou HTTP. Pour plus d'informations sur la procédure de mise en œuvre de cette fonctionnalité, voir la documentation qui accompagne votre infrastructure à clé publique.

Si vous n'êtes pas en mesure de permettre l'accès aux certificats intermédiaires à l'aide du paramètre relatif aux informations de l'Autorité, configurez Outlook Web Access avec le contrôle S/MIME de façon à ce que les certificats intermédiaires soient inclus dans les messages électroniques. Consultez l'administrateur Exchange pour tous les changements nécessaires. Pour plus d'informations sur la configuration de la clé de Registre SecurityFlags, voir le document sur les Paramètres relatifs au contrôle S/MIME d'Outlook Web Access.