Skip to content
Avanet

Sophos Email: set up and operate S/MIME encryption

S/MIME in Sophos Email combines three interdependent layers: the global S/MIME service, correctly matched certificates, and a Secure Message policy. Only an end-to-end test across all three proves that a message is signed, verified, encrypted, or decrypted. This workflow covers S/MIME processing by Sophos Email in Sophos Fusion (formerly Sophos Central). SMTP TLS protects the transport connection instead, Sophos Secure Message Portal is a different encryption method, and the S/MIME Certificate API belongs to a separate automation workflow.

Warning: Reset isn’t routine troubleshooting. It deletes the local CA record and all local and external certificates, removes private keys, and turns off S/MIME. S/MIME settings in policies remain. A downloaded PEM root cannot restore the CA or any private key. Use Reset only with an approved change and a complete rebuild plan that identifies which authorized PKCS#12 files can actually be reimported and which Sophos-generated keys will be lost permanently.

Confirm prerequisites and ownership

Before configuration, obtain:

  • a license or entitlement that includes S/MIME; the global setting can’t be configured in EMS mode;
  • a Sophos Fusion administrator with access to Global Settings > Products and Services > Email > S/MIME and My Products > Email Security > Policies;
  • the exact email address already present in Sophos Fusion for each internal identity;
  • for existing certificates, a password-protected .p12 PKCS#12 file containing the certificate and private key;
  • external recipients’ S/MIME certificates, or a controlled way to learn them from verified signed messages;
  • named owners for the CA, certificates, passwords, renewal, and disaster recovery.

Before the change, record the current S/MIME state, policy scope and order, and every existing certificate’s email address, issuer, fingerprint, and expiry, plus test partners and acceptance criteria. Keep private keys and PKCS#12 passwords in an approved secret or certificate store, not in the ticket. Sophos doesn’t support S/MIME certificate revocation. If a key is compromised, replace the affected certificate and exchange the replacement with communication partners.

Understand certificate roles and matching

Initial setup always requires a local CA in Sophos Email, even if the organization already uses certificates from an internal or public CA. You don’t have to use the new local CA to issue user certificates afterwards. Record its organization details and fingerprint. Its self-signed root can be downloaded in PEM format and given to external partners as public trust material. The PEM contains no private key and is not a restorable backup of the local CA.

User Certificates belong to internal Sophos Fusion users. Sophos uses them to sign outbound messages for the user and decrypt encrypted inbound messages. Each participating user needs a separate certificate matching their email address. During upload, the address must uniquely match an existing user; otherwise Full name remains empty and upload fails. An upload replaces that user’s current certificate.

S/MIME CAs add trusted issuers for inbound signature verification. Check whether Sophos already recognizes a CA globally before uploading it. External S/MIME Certificates belong to external communication partners and, in particular, allow encrypted replies to those recipients. Keep these three inventories distinct.

Enable S/MIME and create the local CA

  1. Open Global Settings > Products and Services > Email > S/MIME.
  2. On Secure MIME Settings, turn on S/MIME.
  3. Decide separately whether to turn on Enable automatic S/MIME certificate extraction. It stores a certificate only from an inbound signed message whose signature verification succeeds.
  4. Create the mandatory local CA using the approved organization and CA details.
  5. Record its fingerprint and creation time, download the public PEM root certificate for controlled trust distribution, and verify it against the recorded fingerprint. Do not treat the PEM as a CA or private-key backup.

Automatic extraction also requires Verify inbound message in the matching Secure Message policy. If verification is off, no certificate is extracted even when extraction is enabled. This prevents unverified certificates from entering the trust store. If the organization only needs encryption and doesn’t verify signatures, upload external certificates manually; manually uploaded certificates are implicitly trusted.

Provision internal user certificates

To generate a certificate with Sophos:

  1. Open User Certificates > Add user.
  2. Enter the existing Sophos Fusion address in Email address and check the automatically populated Full name.
  3. Click Add. Sophos automatically creates the individual certificate.

For multiple users, use Import users with a CSV or TXT file containing exactly one valid existing Sophos Fusion email address per line. Reconcile successful entries and errors against the intended list.

To use an existing certificate:

  1. Check its Subject/SAN email address, issuer, validity, intended usage, key strength, and presence of the private key.
  2. If necessary, use an approved tool to convert PFX to a password-protected .p12 PKCS#12 container.
  3. Select User Certificates > Upload certificate, enter the existing user address and PKCS#12 password, choose the file, and click Upload.
  4. Confirm the address, issuer, fingerprint, and expiry afterwards. Because upload replaces an existing certificate, define its recovery path beforehand.

A downloaded user certificate contains only public trust material, never the private key, and is provided as an encrypted PKCS#12 file. It therefore cannot restore the user’s signing or decryption key. Distribute it to partners whose system can’t extract certificates from signed messages or doesn’t trust the organization’s CA. On outbound messages, Sophos attaches the user certificate, not the CA certificate that signed it.

Add trust and recipient certificates

Under S/MIME CAs, compare the certificate’s issuer and chain with the CAs Sophos already shows as globally recognized. Use Upload only when the required CA is absent. First verify the file, fingerprint, and origin through an independent approved channel. For an individual external recipient, upload their certificate under External S/MIME Certificates > Upload, or learn it from an inbound signed message that passes verification. Then check identity, email address, issuer, fingerprint, and validity.

Never match a certificate by filename or display name alone. If the email address or trust chain doesn’t match, don’t make it fit through a broad CA allowance. Have the certificate owner correct the certificate or mapping.

Assign the Secure Message policy

After certificates are in place, open My Products > Email Security > Policies and create or edit a Secure Message family policy. Record:

  • its internal user, group, or domain scope and any external partner scope;
  • direction and intended signing, verification, encryption, and decryption behavior;
  • policy order and enforcement state;
  • pilot users and a control user outside the scope.

Start with a small pilot scope. Enabling S/MIME globally doesn’t by itself enforce the intended message handling. Conversely, a policy retained after Reset can’t operate until S/MIME and the local CA are configured again and the required certificates are reimported or generated anew.

Accept inbound and outbound behavior

For each message, record time, direction, envelope sender, envelope recipient, and Message-ID. At minimum, test:

  1. a normal unsigned inbound and outbound control message;
  2. an outbound signed message from a pilot user that the external partner successfully verifies;
  3. an inbound signed message from a trusted external identity that Sophos successfully verifies;
  4. an outbound encrypted message to a recipient with the matching external certificate, decryptable only by that recipient;
  5. an inbound encrypted message to an internal user with the matching certificate and private key;
  6. if extraction is enabled, a verified signed message from a test partner followed by an encrypted reply.

Also have the external partner check the sender certificate and trust chain, and inspect the observed message result in Sophos Fusion. A mail client’s S/MIME icon or successful delivery alone proves neither the right policy nor the right certificate identity. Use a deliberately mismatched recipient, expired test certificate, or untrusted test issuer only in an isolated pilot relationship for negative tests; don’t damage production keys deliberately.

Account for technical limits

  • Certificates must conform to S/MIME Version 3 Message Specification or later.
  • Sophos rejects RSA/DSA keys below 1024 bits and EC curves below P-224. Apply the organization’s stricter PKI requirements to new certificates.
  • Sophos-generated certificates use SHA-256, 2048-bit RSA, and AES-256 CBC content encryption. Uploaded certificates retain their supported RSA, DSA, or EC algorithm; content encryption is AES-256 CBC.
  • An outbound message that doesn’t conform to MIME might not be processed by S/MIME.
  • Signed messages between Sophos Email Security and Sophos UTM can’t be verified when SMTP envelope From differs from RFC822 From.
  • If a stored sender certificate is renewed externally, the first message using the new certificate can be rejected. Sophos extracts and stores the new certificate, so the next and subsequent messages are accepted.

Renew, remove, and roll back safely

At least 60, 30, and 14 days before expiry, the certificate owner reviews the inventory and communication partners. Check a new internal certificate’s email address, private key, and trust chain first. Perform the replacing upload in a maintenance window and repeat signing and encryption tests in both directions. Historical content can be decrypted only with the corresponding old private key. Retain it only as an authorized, password-protected PKCS#12 archive under the applicable retention policy. Sophos-generated certificates have no supported private-key export, so don’t promise historical decryption after their replacement or after Reset.

For an external certificate change, plan for the documented possible rejection of the first signed message or upload the replacement in advance through a verified channel. After acceptance, remove obsolete external certificates and unused CA entries individually. User offboarding covers policy scope, User Certificate, external trust relationships, backup retention, and a closing test; it isn’t a reason for tenant-wide Reset.

If a pilot fails, restore the Secure Message policy’s previous enforcement state and order, and remove only certificates or CA entries added by the change. Confirm the former mail flow with control messages. Reset is only the final approved rebuild path.

Troubleshoot methodically

  1. Menu or switch is absent: check entitlement, administrator role, and EMS mode.
  2. Upload fails: check .p12, password, private key presence, S/MIME version, algorithm, and minimum key strength. Confirm that Sophos recognizes the email address as an existing user and populates Full name.
  3. Signature isn’t trusted: check validity, fingerprint, full chain, and matching S/MIME CA. Before adding a CA, confirm Sophos doesn’t already recognize its issuer globally.
  4. Automatic extraction remains empty: confirm the message was inbound and signed, signature verification succeeded, Enable automatic S/MIME certificate extraction is on, and the matching policy hasn’t disabled Verify inbound message.
  5. Outbound encryption is missing: check policy scope and order and a valid External S/MIME Certificate matching the recipient address.
  6. Inbound message can’t be decrypted: check the internal user certificate, private key, recipient address, expiry, and whether a later upload replaced the expected certificate.
  7. Only the first message after renewal fails: account for the documented new-sender-certificate extraction behavior, inspect the stored fingerprint, and send a second controlled message.
  8. Processing remains unexpected: check MIME conformance and, with Sophos UTM, equality of SMTP envelope From and RFC822 From.

For escalation, collect Message-IDs, UTC time, direction, envelope addresses, policy scope and order, certificate Subject, issuer, fingerprint, expiry, and exact error text. Never attach private keys, PKCS#12 files, or passwords to an ordinary support ticket.