Nye Outlook: S/MIME-signatur i sekundær konto kan ikke verifiseres, vedlegg mangler

Når du åpner en digitalt signert e-post i en delt postboks i nye Outlook for Windows, vises en rød linje: «S/MIME-signaturen kan ikke verifiseres ved visning i den sekundære kontoen.» Selve e-posten vises, men ikke vedleggene, selv om avsenderen har sendt dem med. Kollegene som bruker den samme postboksen som hovedkonto, ser vedleggene uten problemer.

Det skyldes to forhold som forsterker hverandre: Nye Outlook behandler S/MIME bare i primærkontoen, og avsenderen har signert e-posten ugjennomsiktig. Med denne signaturformen ligger hele innholdet, inkludert vedlegg, i én enkelt kryptografisk beholder. Hvis klienten ikke kan åpne beholderen, forblir vedleggene usynlige. Begge deler kan løses hver for seg.

Hva meldingen betyr

«Sekundær konto» betyr i nye Outlook enhver postboks som ikke er kontoen du er logget på med. Dette gjelder delte postbokser (Shared Mailboxes) som vises via Full Access og Automapping, samt postbokser du har lagt til via «Legg til delt postboks», og delegeringer. S/MIME-behandlingen i nye Outlook er fast knyttet til primærkontoen. Hvis en signert melding kommer til en annen konto, verifiserer ikke klienten signaturen og viser meldingen i stedet.

Dette sier ikke noe om signaturens gyldighet og er ikke et sertifikatproblem hos avsenderen. Den samme e-posten kan verifiseres og åpnes i primærkontoen eller i klassisk Outlook.

Clear Signing og Opaque Signing

S/MIME-standarden (RFC 8551) har to formater for signerte meldinger. Begge leverer den samme signaturen, men pakker meldingen forskjellig.

I meldingskilden kan du kjenne igjen de to formatene på overskriften Content-Type. En clear-signed e-post begynner slik:

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

En opaque-signed e-post slik:

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

Forskjellen forklarer oppførselen i nye Outlook fullt ut. For en clear-signed e-post viser klienten tekst og vedlegg selv når den ikke verifiserer signaturen; bare signaturstatusen mangler. For en opaque-signed e-post må klienten først pakke ut beholderen gjennom S/MIME-behandlingen for å få tilgang til tekst og vedlegg. Hvis den nekter dette fordi meldingen ligger i en sekundær konto, forblir beholderen lukket. At teksten likevel er lesbar, skyldes Exchange Online: Tjenesten gjengir tekstdelen på serversiden, men ikke vedleggene fra beholderen.

Begge formatene krypterer ingenting. Også den ugjennomsiktige varianten er bare Base64-kodet og lesbar for alle som får tak i meldingen. Microsoft påpeker dette uttrykkelig i dokumentasjonen for Exchange Online.

Hvilket format avsenderen velger

I klassisk Outlook styrer alternativet «Send signerte meldinger som klartekst» (Fil > Alternativer > Klareringssenter > E-postsikkerhet) formatet. Det er aktivert som standard, så Outlook signerer clear-signed. Den som slår av alternativet, sender ugjennomsiktig. Nye Outlook og Outlook på nettet tilbyr ikke denne innstillingen.

E-postgatewayer som signerer sentralt, har sin egen innstilling for signaturformatet. Enkelte produkter signerer ugjennomsiktig som standard av robusthetshensyn, fordi signaturen da også forblir gyldig etter endringer utført av etterfølgende systemer. Hvis du regelmessig mottar e-poster med manglende vedlegg fra en bestemt avsender, kan det være verdt å se på gateway-konfigurasjonen deres.

Hvorfor nye Outlook bare behandler S/MIME i primærkontoen

Microsoft dokumenterer begrensningen, men oppgir ingen teknisk årsak. Årsaken følger av klientens arkitektur.

Nye Outlook er i hovedsak nettklienten til Outlook på nettet i et innebygd native-skall. I nettleseren kan JavaScript ikke få tilgang til Windows-sertifikatlageret. Derfor trengte Outlook på nettet i mange år en separat S/MIME-nettleserutvidelse. Nye Outlook erstatter denne utvidelsen med en innebygd bro mellom nettgrensesnittet og Windows-kryptografien. Denne broen initialiseres når du logger på primærkontoen, og mottar postboksøkten, sertifikatene og S/MIME-innstillingene fra Innstillinger > E-post > S/MIME.

Delte postbokser og sekundærkontoer bruker andre databaner. Sekundærkontoer har egne økter, mens delte postbokser lastes via delegeringen til primærkontoen. Broen har hittil ikke vært koblet til disse banene. Dette gjelder også selve verifiseringen av en signatur, selv om det ikke ville vært nødvendig med en privat nøkkel: Parsing og utpakking av PKCS#7-strukturen går via den samme komponenten.

I klassisk Outlook oppstår ikke problemet, fordi S/MIME-behandlingen der skjer i MAPI-stakken per melding, uavhengig av hvilket lager meldingen kommer fra.

Microsoft legger til den manglende tilkoblingen: Roadmap-oppføring 565861 utvider S/MIME i nye Outlook til delte og delegerte postbokser som er knyttet til primærkontoen. Generell tilgjengelighet er varslet for juli 2026, og utrullingen skjer trinnvis. Hvis du fortsatt ser meldingen, har endringen ennå ikke nådd tenant-en din eller klientversjonen din. Oppføringen dekker ikke separat tilføyde sekundærkontoer med egen pålogging.

Alternativer

Hvilken vei som passer, avhenger av hvordan postboksen er koblet til og om du må verifisere signaturen eller bare vil ha tilgang til vedleggene.

Pakk ut beholderen manuelt

For enkelttilfeller er det nok å åpne beholderen utenfor Outlook. Signaturen verifiseres da matematisk, men sertifikatets tillitskjede kontrolleres ikke. Lagre meldingen som .eml eller lagre vedlegget smime.p7m i en mappe.

På Windows er PowerShell tilstrekkelig. .NET Framework inkluderer klassen SignedCms, som leser PKCS#7-beholderen:

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)

På Linux, macOS eller med Git for Windows er OpenSSL tilgjengelig. Hvis hele e-posten foreligger som .eml, håndterer OpenSSL også Base64-dekodingen:

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

Filen inhalt.eml inneholder den opprinnelige meldingsteksten og alle vedlegg som vanlige MIME-deler. Et dobbeltklikk åpner den i Outlook, der du kan lagre vedleggene som vanlig.