Outlook New: firma S/MIME non verificabile nell'account secondario, allegati mancanti

Nel nuovo Outlook per Windows, quando si apre un’e-mail firmata digitalmente in una cassetta postale condivisa, compare una barra rossa: “La firma S/MIME non può essere verificata durante la visualizzazione nell’account secondario.” L’e-mail viene visualizzata, ma gli allegati no, anche se il mittente li ha inviati. Le colleghe e i colleghi che usano la stessa cassetta postale come account principale vedono gli allegati senza problemi.

Alla base vi sono due fattori che si rafforzano a vicenda: il nuovo Outlook elabora S/MIME solo nell’account principale e il mittente ha firmato l’e-mail in modo opaco. In questa forma di firma, l’intero contenuto, inclusi gli allegati, si trova in un unico contenitore crittografico. Se il client non riesce ad aprire il contenitore, gli allegati rimangono invisibili. Entrambi i problemi possono essere risolti singolarmente.

Cosa significa il messaggio

Nel nuovo Outlook, “account secondario” indica qualsiasi cassetta postale diversa dall’account con cui è stato effettuato l’accesso. Ciò vale per le cassette postali condivise (Shared Mailboxes) visualizzate tramite accesso completo e automapping, per le cassette postali aggiunte tramite “Aggiungi cassetta postale condivisa” e per le deleghe. L’elaborazione S/MIME nel nuovo Outlook è vincolata all’account principale. Se un messaggio firmato arriva in un altro account, il client non verifica la firma e mostra invece il messaggio.

Questo non dice nulla sulla validità della firma e non indica un problema di certificato presso il mittente. La stessa e-mail può essere verificata e aperta nell’account principale o in Outlook classico.

Clear Signing e Opaque Signing

Lo standard S/MIME (RFC 8551) prevede due formati per i messaggi firmati. Entrambi forniscono la stessa firma, ma impacchettano il messaggio in modo diverso.

Nel sorgente del messaggio, è possibile riconoscere i due formati dall’intestazione Content-Type. Un’e-mail con firma clear inizia così:

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

Un’e-mail con firma opaque invece così:

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

La differenza spiega completamente il comportamento nel nuovo Outlook. Con un’e-mail firmata clear, il client mostra testo e allegati anche se non verifica la firma; manca solo lo stato della firma. Con un’e-mail firmata opaque, il client deve prima estrarre il contenitore tramite l’elaborazione S/MIME per accedere a testo e allegati. Se lo rifiuta perché il messaggio si trova in un account secondario, il contenitore resta chiuso. Il fatto che il testo sia comunque leggibile è dovuto a Exchange Online: il servizio esegue il rendering lato server della parte testuale, ma non degli allegati nel contenitore.

Nessuno dei due formati cifra alcunché. Anche la variante opaca è solo codificata in Base64 e leggibile da chiunque entri in possesso del messaggio. Microsoft lo sottolinea espressamente nella documentazione di Exchange Online.

Il formato scelto dal mittente

In Outlook classico, l’opzione “Invia messaggi firmati come testo normale” (File > Opzioni > Centro protezione > Sicurezza posta elettronica) determina il formato. È attivata per impostazione predefinita, quindi Outlook firma in formato clear. Chi disattiva l’opzione invia in formato opaco. Il nuovo Outlook e Outlook sul web non offrono questa impostazione.

I gateway di posta che firmano centralmente dispongono di una propria impostazione per il formato di firma. Alcuni prodotti firmano in formato opaco per impostazione predefinita per ragioni di robustezza, poiché la firma rimane valida anche dopo una modifica da parte di sistemi a valle. Se si ricevono regolarmente e-mail con allegati mancanti da un determinato mittente, vale la pena controllare la configurazione del suo gateway.

Perché il nuovo Outlook elabora S/MIME solo nell’account principale

Microsoft documenta la limitazione, ma non ne indica un motivo tecnico. Il motivo emerge dall’architettura del client.

Il nuovo Outlook è essenzialmente il client web di Outlook sul web in un involucro nativo. Nel browser, JavaScript non può accedere all’archivio certificati di Windows. Per questo Outlook sul web ha richiesto per anni un’estensione separata del browser per S/MIME. Il nuovo Outlook sostituisce questa estensione con un ponte integrato tra l’interfaccia web e la crittografia di Windows. Questo ponte viene inizializzato all’accesso dell’account principale e riceve la sessione della relativa cassetta postale, i relativi certificati e le relative impostazioni S/MIME da Impostazioni > Posta > S/MIME.

Le cassette postali condivise e gli account secondari utilizzano altri percorsi dati. Gli account secondari hanno sessioni proprie, mentre le cassette postali condivise vengono caricate tramite la delega dell’account principale. Finora il ponte non era collegato a questi percorsi. Ciò vale anche per la semplice verifica di una firma, sebbene a tal fine non sarebbe necessaria alcuna chiave privata: l’analisi e l’estrazione della struttura PKCS#7 avvengono tramite lo stesso componente.

In Outlook classico il problema non si presenta, perché l’elaborazione S/MIME avviene nello stack MAPI per ogni messaggio, indipendentemente dallo store da cui proviene il messaggio.

Microsoft sta aggiungendo il collegamento mancante: la voce della roadmap 565861 estende S/MIME nel nuovo Outlook alle cassette postali condivise e delegate collegate all’account principale. La disponibilità generale è annunciata per luglio 2026, con un rollout graduale. Se il messaggio continua a comparire, la modifica non è ancora arrivata nel tenant o nella versione client in uso. La voce non copre gli account secondari aggiunti separatamente con un proprio accesso.

Soluzioni

La soluzione adatta dipende da come è integrata la cassetta postale e dalla necessità di verificare la firma o solo di accedere agli allegati.

Estrarre manualmente il contenitore

Per un caso singolo, è sufficiente aprire il contenitore al di fuori di Outlook. La firma viene verificata matematicamente, ma non la catena di attendibilità del certificato. Salvare il messaggio come .eml oppure conservare l’allegato smime.p7m in una cartella.

In Windows è sufficiente PowerShell. Il .NET Framework include la classe SignedCms, che legge il contenitore 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)

Su Linux, macOS o con Git per Windows è disponibile OpenSSL. Se l’intera e-mail è disponibile come .eml, OpenSSL esegue anche la decodifica Base64:

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

Il file inhalt.eml contiene il testo originale del messaggio e tutti gli allegati come normali parti MIME. Un doppio clic lo apre in Outlook, dove è possibile salvare gli allegati come di consueto.