cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
897
Views
0
Helpful
5
Replies
Highlighted
Beginner

Enabling TLS on ESAs

I recently took administration of the ESAs at my company. They do not use TLS on either inbound or outbound email. I am curious about the repercussions if I were to change the inbound and outbound settings from "Off" to "Preferred"?

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Engager

That your users would see? Basically none.  It's transparent to them, but you see a ton of you mail come and go in TLS tunnels instead of in the clear.

You may want to investigate the cipher suite configuration and you want to use a cert that matches the A record that your mx record points to.  Wildcard certs are supported.

View solution in original post

5 REPLIES 5
Highlighted
Engager

That your users would see? Basically none.  It's transparent to them, but you see a ton of you mail come and go in TLS tunnels instead of in the clear.

You may want to investigate the cipher suite configuration and you want to use a cert that matches the A record that your mx record points to.  Wildcard certs are supported.

View solution in original post

Highlighted

Hi Ken,

TLS inbound (Mail Policies>Mail Flow Policy: Defaults - IncomingMail) works just fine. TLS outbound (Mail Policies>Edit Destination Controls), however, is an issue. I have narrowed it down to the connection from the ESA to the mail server.

I can send a message to another domain and it will be delivered, but when I receive from another domain, I don't receive that message unless I turn TLS outbound off. Looking at the message tracking, the ESA receives the message from the internet and queues it for delivery to my mail server.

When I telnet to the mail server and start TLS, the mail server closes the connection. See the output from the CLI:

(Machine ESA.company.com)> telnet mailserver 25

Trying XXX.XXX.XXX.XXX...
Connected to XXX.XXX.XXX.XXX.
Escape character is '^]'.
220 mailserver ESMTP Service (mail server version info) ready at timestamp
ehlo mailserver
250-mailserver Hello mailserver ([YYY.YYY.YYY.YYY]), pleased to meet you
250-TLS
250-HELP
250-AUTH LOGIN
250-STARTTLS
250-SIZE 20971520
250 PIPELINING
starttls
220 Ready to start TLS
Connection closed by foreign host.

I have already tested the firewall just in case that might be it. Could this be something that can be corrected on the ESA side? Or would it be on the mail server side?

Highlighted

If you mean your INTERNAL mail server, you have to have TLS enabled and a cert set up, etc.

In Exchange 2010 open the EMC, go to Server Configuration/Hub Tranport, pick a server, in the top window, double click the "Default..." receive connector in the bottom window,  on the Authentication tab make sure TLS is checked.

 

Did you put your domain name in the Destination Controls with TLS  as "Required" or "required-Verify"

Verify will probably fail depending upon the cert you're using on your mail system.

 

 

 

 

Highlighted

I do not have Exchange. I use Domino. I enable it as Preferred, not Required. 

Highlighted
Cisco Employee

Hey Khaim,

 

As Ken has provided, you will not see any issue or any repercussions should you change it from "Off" to "Preferred"

 

Users will not see any differences (unless they look into the headers and see TLS protocol being used) but that's about it.

 

If anyone is running packet tracers or captures then they'll see the traffic data in an encrypted format and cannot intercept the traffic this way.

 

In regards to mail transactions you shouldn't see any issues given your default settings are set to "Off"

For an extra explanation on the differences between "Off" and "Preferred"

(taken off the online help guide on the ESA)

---

TLS "Off"

TLS is not negotiated for outgoing connections from the interface to the MTA for the domain.

TLS "Preferred"

TLS is negotiated from the Email Security appliance interface to the MTA(s) for the domain. However, if the TLS negotiation fails (prior to receiving a 220 response), the SMTP transaction will continue “in the clear” (not encrypted). No attempt is made to verify if the certificate originates from a trusted certificate authority. If an error occurs after the 220 response is received the SMTP transaction does not fall back to clear text.

Content for Community-Ad