currently we are using MS Exchange with individual X.509 certificates stored in the users’ outlook clients.
Some of our clients only accept encrypted mails, however their certificate does not match the receipients e-Mail address. For example: john.doe(at)company-com sends a sigend mail with a certificated issued for crypt(at)company-com, their e-mail gateway would decrypt mails sent to john.doe but encrypted with crypt(at)company-com. The problem is, that there is no way for Outlook to encrypt the mail with a certificate that does not match the receipient.
Is ciphermail able to handle such setups through auto-learning?
The gateway can be configured to encrypt all email to some domain using a “domain” certificate. So in your case you can configure the domain company-com to always use the S/MIME certificate crypt(at)company-com when sending email to any recipient of domain company-com.
This however cannot be done automatically because that would not be secure.
thanks this is very helpful. Doing a manual configuration for those domains seems reasonable.
iterating on that, I have a follow up question. E-Mail encryption serves as an end-to-end enryption, encrypting both, the transport of the mail, and the mail stored in the users’ mailboxes. I see how using an encrypting mail gateway makes things easier for “enterprise”-scale deployments, however mails are sent decrypted to the mailbox and there stored in plain-text.
Is it possible to use ciphermail in a way so, incoming mail is passed through the gateway, but it’s not decrypted but forwared directly to the users’ mailboxes so it stays there until viewed with the mail-client?
If you do not put the private key on the gateway, then the email cannot be decrypted and it’s therefore forwarded with encryption intact to the recipient.
Or should the private key be stored on the gateway for signing?
Well the use case would be to enforce encryption to certain receipient-domains. So the keys should be on the gateway as well as on the client. When the user forgets to encrypt an e-mail the gateway could jump in and encrypt the mail. However incoming encrypted mails should be sent directly to the user’s mailbox to not break end-to-end encryption.
Encryption can function without access to the private key so if a recipient (or domain) certificate on the gateway is available and valid, the gateway can encrypt.
But, perhaps I misunderstand your use-case.
the normal operation mode with encryption gateways usually is, that they receive unencrypted mails from the company’s mailserver that get encrypted on the gateway and then sent to receiving party. How the receiver handels encrypted messages is out of my control. This mode of operation has some advantages for administrators, like having a central point for certificate management, users don’t need to think about encrypting mails and the public certificates of incoming mails can be automatically learned by the appliance - among others.
The disadvantage is that mails stay unencrypted in my users’ mailboxes. So as I’ve explained before, my ideal scenario would be that users decrypt/encrypt their mails with outlook (as they are already doing) and the gateway jumps in for encrypting mails where the user has forgotten to press the button or the receiving party uses a domain certificate.
What I get from your answers is, that it should work as long as the gateway does not have the private certificates installed. If configured properly encrypted mails should just pass through the gateway. Since encrypting a mail does not requires only the receiver’s public key the private certificates of my users don’t need to be installed on the gateway. That being said, how does that impact the receiver of the mails? Usually encrypted mails also should be signed by the sending party if the receiver needs to get public key…
However if my users’ outlook clients would default sign every outgoing mail (which is already the case) there shouldn’t be much of problem with not having the private keys on the gateway?
are my assumptions correct? I personally would prefer an option where ciphermail also knows the private certificates, but does not decrypt the mails for final delivery. If the product is expanded with antivirus or antispam capabilites, the contents could still be checked and after it passes the checks it still gets delivered encrypted.