Cloud-Hosted S/MIME Email Encryption

To encrypt a message to an S/MIME recipient, the sender must obtain an appropriate recipient certificate containing a usable public key. To sign a message, the sender uses a suitable signing key and certificate. Encryption and signing serve different purposes and may be used together or separately.

In a gateway-based model, the encryption engine can carry out these operations according to policy, so individual senders do not have to manage certificates in their own email clients.

Platform documentation describes several ways certificates can enter the system and stay current:

• Manual import of existing certificates and keys by an administrator.
• External LDAP lookups to retrieve recipient certificates.
• Certificate authority integrations through an API CA bridge, for automated certificate creation with supported providers.
• Automated renewal and rollover for supported integrations.

The platform also provides configurable signing modes that set which key signs a message and in what order of precedence. They are described under S/MIME signing precedence.

Availability of each workflow depends on the integrations and policies configured for a deployment. Certificates obtained outside a supported integration, for example, may need to be renewed and imported again manually.

Certificate workflows may connect to supported public certificate authority services or to a customer’s AWS Private CA through an API bridge. The two models differ. A public CA issues certificates that chain to roots most email clients already trust. A customer-managed private CA issues certificates that recipients trust only if their software trusts that private CA’s root.

Reading the architecture diagram

• User A’s mail is routed by the customer’s mail system to the encryption engine over TLS, where key management holds User A’s keys and certificate.
• Certificates can come from the customer’s own X.509 certificate provider, from an administrator uploading private or public certificates, or from an API uploading public or private keys.
• The API CA bridge connects to automated X.509 certificate creation. DigiCert and SwissSign appear in the diagram as examples.
• Public keys can be published to the Echoworx directory, and recipient certificates can be found through an LDAP (X.509) lookup.
• Messages are delivered to the recipient encrypted and signed, and the recipient’s replies return to the engine.

Reading the AWS Private CA workflow

• Manual creation: an administrator or user uploads private keys for X.509 certificates.
• Automatic creation: the API generates certificates and loads them into key management.
• AWS Private CA integration: the API CA bridge connects the encryption engine to an AWS Private CA integration, which works with the customer’s private certificate authority in AWS.
• Lookup and delivery: recipient certificates are found through an LDAP (X.509) lookup, and messages travel encrypted and signed between the engine and the S/MIME user.

With a private CA, the customer operates the certificate authority, and recipients must trust its root certificate for signatures to validate. This model suits exchanges between parties that already share that trust.

S/MIME processing can be integrated through suitable SMTP routing and gateway policies, with directory configuration determined by the customer’s environment. Before deployment, confirm:

• how outbound and inbound mail will be routed to and from the encryption engine;
• which LDAP directories hold recipient certificates, and which of them the platform should query;
• where sender certificates will come from: imports, an existing certificate provider or a supported CA integration;
• which signing mode and key precedence each policy should use;
• how messages to recipients without a usable certificate will be handled.