E-Mail Verrschlüsselung

community.sophos.com/.../131727

Leider nicht sehr hilfreich. Es ist kein Drittanbieterzertifikat, sondern ein von der UTM generiertes. 

Auch das Zurücksetzen der Encryption war nicht erfolgreich.

Wie gesagt, das Ganze muss Praktikabel für jedermann/Frau sein....

Tja, dann musst Du Zertifikate von einer öffentlichen Zertifizierungsstelle beziehen.

Auch diese Antwort hilft mir leider nicht weiter.

Ich habe für unsere Domain ein Wildcard-Zertifikat, auch wenn ich das in der UTM einbinde kommt in Outlook wir Warnung. Ich kann die Warnung nur unterbinden wenn die Gegenseite eine Sophos UTM hat und die Zertifikate installiere die Sophos erstellt.

Seit dem letzten UTM Update werden meines Wissens nach alle Signaturen mit RSASSA-PSS signiert. Das kann nur kaum ein E-Mail Client. Outlook fällt mit in diese Kategorie.

Hier wäre ein Gateway ratsam, welches E-Mail-Verschlüsselung zu 100% umgesetzt hat und flexibel mit Algorithmen umgehen kann.

Gruß SC

You may be mixing different technologies.

Signatures are different than encryption.   They only prove the message has not been modified.  This can be important with or without encryption.

It sounds like you have enabled DKIM signing.   DKIM does not use CA certificates.   Instead, you generate a keypair using Openssl.  The private key is loaded into UTM.  The public key is published using DNS.  A web search will help you with additional details.   An RFC from ietf.org is the official reference.

There are multiple options for encryption.  I do not understand which one you were trying to use.

More on encryption and digital signatures.

In a message from Sender "A" to Recipient "B",

• The Sender's digital signature is used to prove that the message came from him, and to prove that it was not altered in transmission.
• The Recipient's private key is used to encrypt the message so that it can only be read by the Recipient.

In a perfect world, you want both features.

For email encryption, none of the options are entirely satisfactory.   The best option is to not use email for sensitive communication.   Here is a recap of your options:  

• PKI (Certificate security) can be used for both signatures and encryption.  As a signing method, it is an alternative to DKIM.  PKI requires both sender and recipient to have USER certificates issued by a certificate authority (or other arrangements to ensure that the other person's user certificate is trusted.)  Server certificates do not work and wildcard certificates are out of the question.   This approach provides user-to-user encryption including encryption for data-at-rest.   It protects both the message body and any attachments.  It requires an email client with the appropriate features (e.g. Microsoft Outlook), and is incompatible with web-based user interfaces.
  
  
• S/MIME, and PGP protect attachments.  I don't think either can protect message body.   If you use the UTM feature to encrypt at transmission and decrypt at reception, you have server-to-server encryption, but not user-to-user security, and you lose protection for data-at-rest on the mail servers.   A sophisticated user should be able to encrypt the attachment off-line, then attach it to an email.  This would allow him to use web-based user interfaces, and it would keep the file encrypted at rest on the mail servers.
  
  
• PKI, S/MIME, and PGP all require prior setup and a sophisticated communication partner.
  
  
• SPX protects the message body and the attachments, by rolling them all into a PDF file that becomes an attachment to a replacement message.  SPX and other file-level password solutions have problems also. If the password is lost, then the data is lost, because there is no password recovery method.  Additionally, the file is defenseless against a sustained attack on the password encryption approach, so privacy cannot be assured.   When many files are transmitted, over time, to multiple recipients, password management quickly becomes extremely difficult for both sender and receiver.  Works without prior setup.  In limited volume, it may work well for unsophisticated recipients.
  
  
• Web-based relay relies on a secure channel from source to relay site, and a web-based https session for message retrieval.  Zixmail seems to be the best-known example.   UTM does not offer this option.   Web-based relay uses an encrypted channel from the source to the relay server, and an encrypted web session for the recipient to retrieve the mail.   It does not ensure any protection for data-at-rest on the relay site.   It uses an email to send the user a link for establishing a relay site login, and this undermines the integrity of the design.   If the relay is being used to prevent interception of the original message, what is to prevent an attacker from intercepting the notification message and using the embedded link to retrieve the protected message?   Despite these strong objections, web-based relay is the most popular technique for ad-hoc recipients and unsophisticated recipients.

More on DKIM signatures:  In theory, DKIM can be used for user-level signatures, but maintaining a DNS entry for each user seems daunting, and I have never seen it done.  Usually it is used at the domain level.   The signature is applied by the mail server or the mail gateway, to prove that the message from the stated organization, but does not tie the message to a specific person.