Outlook New: no se puede verificar la firma S/MIME en la cuenta secundaria, faltan archivos adjuntos
El nuevo Outlook indica en el buzón compartido que la firma S/MIME no se puede verificar en la cuenta secundaria y no muestra archivos adjuntos. El artículo explica la diferencia entre Clear Signing y Opaque Signing, por qué desaparecen los adjuntos en los correos firmados de forma opaca, por qué el nuevo Outlook solo procesa S/MIME en la cuenta principal y qué alternativas existen, incluido extraer smime.p7m con PowerShell u OpenSSL.
Al abrir un correo firmado digitalmente en un buzón compartido en el nuevo Outlook para Windows, aparece una barra roja: “No se puede verificar la firma S/MIME al visualizarla en la cuenta secundaria.” El correo se muestra, pero no los archivos adjuntos, aunque el remitente los haya enviado. Las compañeras y los compañeros que utilizan el mismo buzón como cuenta principal ven los adjuntos sin problemas.
Detrás de esto hay dos factores que se refuerzan mutuamente: el nuevo Outlook solo procesa S/MIME en la cuenta principal y el remitente ha firmado el correo de forma opaca. Con esta forma de firma, todo el contenido, incluidos los adjuntos, está dentro de un único contenedor criptográfico. Si el cliente no puede abrir el contenedor, los adjuntos permanecen invisibles. Ambos problemas pueden resolverse por separado.
Qué significa el mensaje
“Cuenta secundaria” significa en el nuevo Outlook cualquier buzón que no sea la cuenta con la que ha iniciado sesión. Esto se aplica a los buzones compartidos (Shared Mailboxes) que se muestran mediante acceso completo y automapping, a los buzones que haya agregado mediante “Agregar buzón compartido” y a las delegaciones. El procesamiento de S/MIME en el nuevo Outlook está vinculado de forma fija a la cuenta principal. Si un mensaje firmado llega a otra cuenta, el cliente no verifica la firma y muestra el mensaje en su lugar.
No se trata de una afirmación sobre la validez de la firma ni de un problema con el certificado del remitente. El mismo correo puede verificarse y abrirse en la cuenta principal o en el Outlook clásico.
Clear Signing y Opaque Signing
El estándar S/MIME (RFC 8551) conoce dos formatos para mensajes firmados. Ambos proporcionan la misma firma, pero empaquetan el mensaje de forma diferente.
| Clear Signing | Opaque Signing | |
|---|---|---|
| Tipo MIME | multipart/signed con protocol="application/pkcs7-signature" | application/pkcs7-mime con smime-type=signed-data |
| Estructura | Dos partes: el texto legible del mensaje con los adjuntos y, por separado, la firma | Una parte: texto del mensaje, adjuntos y firma juntos en un contenedor CMS-SignedData, codificado en Base64 |
| Adjunto que ve un cliente sin S/MIME | smime.p7s (solo la firma, unos pocos KB) | smime.p7m (el mensaje completo) |
| Legible sin compatibilidad con S/MIME | Sí, el texto y los adjuntos se muestran normalmente | No, el cliente solo ve el contenedor |
| Sensibilidad durante el transporte | La firma deja de ser válida si un servidor de correo o gateway modifica saltos de línea, codificación o espacios en blanco | El contenedor protege el contenido frente a esos cambios |
| Sección de RFC 8551 | 3.5.3 | 3.5.2 |
En el código fuente del mensaje puede reconocer ambos formatos por la cabecera Content-Type. Un correo firmado de forma clara comienza así:
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha-256; boundary="----=_Part_4711"Un correo firmado de forma opaca, así:
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"La diferencia explica por completo el comportamiento del nuevo Outlook. En un correo firmado de forma clara, el cliente muestra el texto y los adjuntos incluso si no verifica la firma; solo falta el estado de la firma. En un correo firmado de forma opaca, el cliente primero debe extraer el contenedor mediante el procesamiento S/MIME para acceder al texto y a los adjuntos. Si se niega a hacerlo porque el mensaje está en una cuenta secundaria, el contenedor permanece cerrado. Que el texto siga siendo legible se debe a Exchange Online: el servicio representa la parte de texto en el servidor, pero no los adjuntos del contenedor.
Ninguno de los dos formatos cifra nada. Incluso la variante opaca solo está codificada en Base64 y puede ser leída por cualquiera que obtenga el mensaje. Microsoft lo indica expresamente en la documentación de Exchange Online.
Qué formato elige el remitente
En el Outlook clásico, la opción “Enviar mensajes firmados como texto sin formato” (Archivo > Opciones > Centro de confianza > Seguridad de correo electrónico) controla el formato. Está activada de forma predeterminada, por lo que Outlook firma de forma clara. Quien desactive la opción envía de forma opaca. El nuevo Outlook y Outlook en la Web no ofrecen esta configuración.
Los gateways de correo que firman de forma centralizada tienen su propia configuración para el formato de firma. Algunos productos firman de forma opaca de manera predeterminada por motivos de robustez, ya que la firma sigue siendo válida incluso después de una modificación por sistemas posteriores. Si recibe regularmente correos de un remitente concreto con adjuntos ausentes, merece la pena revisar la configuración de su gateway.
Por qué el nuevo Outlook solo procesa S/MIME en la cuenta principal
Microsoft documenta la limitación, pero no indica ningún motivo técnico. La razón se desprende de la arquitectura del cliente.
El nuevo Outlook es, en esencia, el cliente web de Outlook en la Web dentro de una envoltura nativa. En el navegador, JavaScript no puede acceder al almacén de certificados de Windows. Por ello, Outlook en la Web necesitó durante años una extensión de navegador S/MIME independiente. El nuevo Outlook sustituye esta extensión por un puente integrado entre la interfaz web y la criptografía de Windows. Este puente se inicializa al iniciar sesión en la cuenta principal y recibe su sesión de buzón, sus certificados y sus configuraciones S/MIME desde Configuración > Correo > S/MIME.
Los buzones compartidos y las cuentas secundarias utilizan otras rutas de datos. Las cuentas secundarias tienen sus propias sesiones; los buzones compartidos se cargan mediante la delegación de la cuenta principal. Hasta ahora, el puente no estaba conectado a estas rutas. Esto también se aplica a la mera verificación de una firma, aunque para ello no sea necesaria una clave privada: el análisis y la extracción de la estructura PKCS#7 se realizan mediante el mismo componente.
En el Outlook clásico el problema no se produce, porque el procesamiento S/MIME se realiza en la pila MAPI por mensaje, independientemente del almacén del que proceda el mensaje.
Microsoft está añadiendo la conexión que falta: la entrada 565861 de la hoja de ruta amplía S/MIME en el nuevo Outlook a buzones compartidos y delegados vinculados a la cuenta principal. La disponibilidad general está anunciada para julio de 2026 y la implementación será gradual. Si continúa viendo el mensaje, el cambio aún no ha llegado a su tenant o a su versión de cliente. La entrada no cubre las cuentas secundarias agregadas por separado con inicio de sesión propio.
Alternativas
La vía adecuada depende de cómo esté integrado el buzón y de si necesita verificar la firma o solo acceder a los adjuntos.
| Vía | Requisito | Resultado |
|---|---|---|
| Abrir el correo en la cuenta principal | Tiene el buzón como cuenta principal o el correo se le ha reenviado | Verificación de firma y adjuntos |
| Agregar el buzón como cuenta independiente en el nuevo Outlook (Configuración > Cuentas > Agregar cuenta) | El buzón tiene credenciales propias; no es posible con buzones compartidos sin contraseña | Verificación de firma y adjuntos al cambiar a esta cuenta |
| Outlook clásico | Aún instalado o se puede volver mediante el interruptor “Nuevo Outlook”; integrar allí el buzón como cuenta propia (Archivo > Configuración de la cuenta > Nuevo) | Verificación de firma y adjuntos en cada almacén |
| Outlook en la Web | Abrir el buzón directamente (outlook.office.com/mail/<adresse>), con la extensión S/MIME para Edge o Chrome instalada | Verificación de firma y adjuntos |
| Pedir al remitente Clear Signing | El remitente usa Outlook clásico o un gateway con formato seleccionable | Adjuntos visibles; el estado de la firma seguirá sin mostrarse en la cuenta secundaria |
| Extraer el contenedor manualmente | Guardar el correo como .eml o conservar smime.p7m | Adjuntos sin verificación de firma |
Extraer el contenedor manualmente
Para un caso puntual basta con abrir el contenedor fuera de Outlook. La firma se verifica criptográficamente, pero no la cadena de confianza del certificado. Guarde el mensaje como .eml o guarde el adjunto smime.p7m en una carpeta.
En Windows basta con PowerShell. .NET Framework incluye la clase SignedCms, que lee el contenedor 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)En Linux, macOS o con Git para Windows, OpenSSL está disponible. Si tiene el correo completo como .eml, OpenSSL también realiza la decodificación Base64:
openssl cms -verify -noverify \
-in nachricht.eml \
-out inhalt.emlEl archivo inhalt.eml contiene el texto original del mensaje y todos los adjuntos como partes MIME normales. Al hacer doble clic se abre en Outlook, donde puede guardar los adjuntos como de costumbre.
Comentarios
Los comentarios se cargan desde GitHub / Giscus.