SMTP with TLS question
I'm trying to enable encrypted email on our corporate server, and I can see the options to enable this in the SMTP-proxy rules. Reading the Watchguard documentation seems to indicate that the firewall will perform TLS negotiation with outside servers, but the docs fall short on what I should do at my internal mail server. Does the firewall handle all the TLS encryption and then pass it down to my mail server like a normal un-encrypted SMTP exchange, or do I also need to configure my mail server to also handle encryption? If so, do I need to use the same certs in both the firewall and the mail server? Any help in setting this up would be most appreciated.
Best Answer
-
Review these setting options, especially the Recipient Encryption options.
Since Recipient Encryption can be None or Preferred, clearly the internal SMTP server need not do TLS, but it could.Sender Encryption
Required — The sender SMTP server must negotiate encryption with the Firebox.
None — The Firebox does not negotiate encryption with the sender SMTP servers.
Optional — The sender SMTP server can negotiate encryption with the receiver SMTP server. TLS encryption depends on the encryption capabilities and settings of the receiver SMTP server.Recipient Encryption
Required — The Firebox must negotiate encryption with the recipient SMTP server.
None — The Firebox does not negotiate encryption with the recipient SMTP server.
Preferred — The Firebox tries to negotiate encryption with the recipient SMTP server.
Allowed — The Firebox uses the behavior of the sender SMTP server to negotiate encryption with the recipient SMTP server.For Q2 - from the docs:
About Certificates for TLS Encryption
When content inspection is enabled for inbound SMTP over TLS traffic, the proxy uses a certificate to re-encrypt incoming traffic after it is decrypted for inspection. You can use the default Proxy Server certificate for this purpose.
So - no, the firewall & the server do not need to use the same cert.
5
Answers
OK - that gives me options, then. We did have somthing resembling encryption functioning for a while last month, but then it broke, particularly google/gmail. I've been pulling my hair out and trying to build things back up from the start, so I needed to know how the firewall should be configured so I can rule it out as a problem.
Google (and aparently others) started being more picky about TLS implementation:
https://support.google.com/mail/thread/10350042?hl=en
Now I can focus on setting up the email server properly.
Thanks, and wish me luck!
Feel free to open a support incident to get WG help with this
OK - so, I've tried using the configuration option "None" for both Sender and Receiver encryption, however this behavior only disables all encryption. What I expected was that the TLS exchange would simply pass on to my SMTP sever behind the firewall and allow it to handle the exchange, but this is not the case.
When the options are set to allow encryption (optional, allowed), I get mixed results. Some sites seem to be OK and can use TLS, however GMail (Google) is still throwing a fit and won't deliver email. Also, the testing site I'm using (checktls.com) fails TLS, saying "handshake failure".
Any ideas?
You should open a support incident on the TLS failure issue and the Gmail issue.
If you want None, None as your option, and you want XTM to do direct pass through to your internal mail server, then you need to unselect TLS.
With TLS selected, the SMTP session is external mail server to XTM, XTM session to internal mail server.
You cannot pass-through TLS via SMTP proxy atm. We do have an enhancement logged to support it.
To troubleshoot, I'd isolate checktls traffic (IP/IP network) in a packet filter policy and make sure you have TLS working with the internal mail server before introducing TLS to your SMTP proxy.
"...do I also need to configure my mail server to also handle encryption?..." Yes, your internal mail server must support STARTTLS.
"....do I need to use the same certs in both the firewall and the mail server?..." Recommended. No need to advertise to the outside world that your server is protected by a Firebox. Move the internal mail server certificate with it's private key and any intermediate/CA certificates (if certificate is non-3rd party) to the Firebox.