Nouvel Outlook : signature S/MIME non vérifiable dans le compte secondaire, pièces jointes absentes

Dans le nouvel Outlook pour Windows, l’ouverture d’un e-mail signé numériquement dans une boîte aux lettres partagée affiche une barre rouge : « Le signe S/MIME ne peut pas être vérifié lors de l’affichage dans le compte secondaire. » L’e-mail lui-même s’affiche, mais pas les pièces jointes, bien que l’expéditeur en ait envoyées. Les collègues qui utilisent la même boîte aux lettres comme compte principal voient les pièces jointes sans problème.

Deux éléments se renforcent mutuellement : le nouvel Outlook ne traite S/MIME que dans le compte principal, et l’expéditeur a signé l’e-mail de manière opaque. Avec cette forme de signature, l’intégralité du contenu, y compris les pièces jointes, se trouve dans un unique conteneur cryptographique. Si le client ne peut pas ouvrir ce conteneur, les pièces jointes restent invisibles. Ces deux problèmes peuvent être résolus séparément.

Ce que signifie le message

« Compte secondaire » désigne dans le nouvel Outlook toute boîte aux lettres autre que le compte utilisé pour vous connecter. Cela concerne les boîtes aux lettres partagées (Shared Mailboxes) affichées via l’accès complet et l’automapping, mais aussi les boîtes aux lettres ajoutées via « Ajouter une boîte aux lettres partagée » ainsi que les délégations. Dans le nouvel Outlook, le traitement S/MIME est strictement lié au compte principal. Si un message signé arrive dans un autre compte, le client ne vérifie pas la signature et affiche ce message à la place.

Cela ne dit rien sur la validité de la signature et ne signale pas un problème de certificat chez l’expéditeur. Le même e-mail peut être vérifié et ouvert dans le compte principal ou dans Outlook classique.

Clear Signing et Opaque Signing

La norme S/MIME (RFC 8551) prévoit deux formats pour les messages signés. Tous deux fournissent la même signature, mais emballent le message différemment.

Dans la source du message, vous reconnaissez les deux formats à l’en-tête Content-Type. Un e-mail signé en clair commence ainsi :

Content-Type: multipart/signed; protocol="application/pkcs7-signature";
    micalg=sha-256; boundary="----=_Part_4711"

Un e-mail signé de manière opaque ainsi :

Content-Type: application/pkcs7-mime; smime-type=signed-data;
    name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"

Cette différence explique entièrement le comportement du nouvel Outlook. Pour un e-mail signé en clair, le client affiche le texte et les pièces jointes même s’il ne vérifie pas la signature ; seul l’état de la signature manque. Pour un e-mail signé de manière opaque, le client doit d’abord extraire le conteneur via le traitement S/MIME pour accéder au texte et aux pièces jointes. S’il refuse de le faire parce que le message se trouve dans un compte secondaire, le conteneur reste fermé. Si le texte reste tout de même lisible, c’est grâce à Exchange Online : le service restitue la partie texte côté serveur, mais pas les pièces jointes du conteneur.

Les deux formats ne chiffrent rien. Même la variante opaque est seulement encodée en Base64 et peut être lue par toute personne ayant accès au message. Microsoft le précise explicitement dans la documentation Exchange Online.

Quel format choisit l’expéditeur

Dans Outlook classique, l’option « Envoyer les messages signés en texte brut » (Fichier > Options > Centre de gestion de la confidentialité > Sécurité de la messagerie) contrôle le format. Elle est activée par défaut : Outlook signe donc en clair. Si cette option est désactivée, Outlook envoie une signature opaque. Le nouvel Outlook et Outlook sur le web ne proposent pas ce réglage.

Les passerelles de messagerie qui signent de manière centralisée disposent de leur propre réglage de format de signature. Certains produits signent de manière opaque par défaut pour des raisons de robustesse, car la signature reste alors valide même après une modification par des systèmes en aval. Si vous recevez régulièrement des e-mails d’un expéditeur précis avec des pièces jointes manquantes, il vaut la peine de vérifier la configuration de sa passerelle.

Pourquoi le nouvel Outlook ne traite S/MIME que dans le compte principal

Microsoft documente cette limitation, sans toutefois en indiquer la raison technique. Celle-ci découle de l’architecture du client.

Le nouvel Outlook est essentiellement le client web d’Outlook sur le web dans une enveloppe native. Dans le navigateur, JavaScript ne peut pas accéder au magasin de certificats Windows. C’est pourquoi Outlook sur le web a eu besoin pendant des années d’une extension de navigateur S/MIME distincte. Le nouvel Outlook remplace cette extension par un pont intégré entre l’interface web et la cryptographie Windows. Ce pont est initialisé lors de la connexion au compte principal et reçoit sa session de boîte aux lettres, ses certificats et ses paramètres S/MIME depuis Paramètres > E-mail > S/MIME.

Les boîtes aux lettres partagées et les comptes secondaires empruntent d’autres chemins de données. Les comptes secondaires disposent de leurs propres sessions, tandis que les boîtes aux lettres partagées sont chargées via la délégation du compte principal. Jusqu’à présent, le pont n’était pas connecté à ces chemins. Cela vaut également pour la simple vérification d’une signature, bien qu’aucune clé privée ne soit nécessaire : l’analyse et l’extraction de la structure PKCS#7 passent par le même composant.

Dans Outlook classique, ce problème ne se produit pas, car le traitement S/MIME s’effectue dans la pile MAPI pour chaque message, indépendamment du Store dont provient le message.

Microsoft ajoute cette connexion manquante : l’entrée de feuille de route 565861 étend S/MIME dans le nouvel Outlook aux boîtes aux lettres partagées et déléguées rattachées au compte principal. La disponibilité générale est annoncée pour juillet 2026, avec un déploiement progressif. Si le message apparaît toujours, la modification n’est pas encore arrivée dans votre tenant ou votre version du client. L’entrée ne couvre pas les comptes secondaires ajoutés séparément avec leur propre connexion.

Solutions possibles

La solution appropriée dépend de la manière dont la boîte aux lettres est intégrée et de votre besoin de vérifier la signature ou simplement d’accéder aux pièces jointes.

Extraire manuellement le conteneur

Pour un cas ponctuel, il suffit d’ouvrir le conteneur en dehors d’Outlook. La signature est alors vérifiée mathématiquement, mais pas la chaîne de confiance du certificat. Enregistrez le message au format .eml ou sauvegardez la pièce jointe smime.p7m dans un dossier.

Sous Windows, PowerShell suffit. Le .NET Framework fournit la classe SignedCms, qui lit le conteneur PKCS#7 :

Add-Type -AssemblyName System.Security
$bytes = [IO.File]::ReadAllBytes("C:\Temp\smime.p7m")
$cms = New-Object System.Security.Cryptography.Pkcs.SignedCms
$cms.Decode($bytes)
$cms.CheckSignature($true)
[IO.File]::WriteAllBytes("C:\Temp\inhalt.eml", $cms.ContentInfo.Content)

Sous Linux, macOS ou avec Git pour Windows, OpenSSL est disponible. Si l’e-mail entier est disponible au format .eml, OpenSSL effectue aussi le décodage Base64 :

openssl cms -verify -noverify \
  -in nachricht.eml \
  -out inhalt.eml

Le fichier inhalt.eml contient le texte original du message et toutes les pièces jointes sous forme de parties MIME normales. Un double-clic l’ouvre dans Outlook, où vous pouvez enregistrer les pièces jointes comme d’habitude.