Configuring TLS on IronPort ESA

[paultribe]

Hi

Can anyone suggest the best way to configure TLS based on my requirements outlined below. It seems

there are various ways to do this and I admit I am a little confused. Also its been a while since I

have been tasked with working on ESA's.

My environment:-

2 x IronPort ESA in cluster with Inbound Public listener and OutBound Private listener.

1 IP address per listener.

1 MX / A record per Public listener.

SMTP routes to several internal mail servers.

No load balancers, DNS preference used in MX.

MY requirement:-

I am required to configure TLS support Inbound and outbound to 1 of the internal domains. As I understand it from my "research", I would need to generate a CSR on each machine and submit this to a CA such as Verisign at which point they would return the certificate signed and their trusted  root. I would then import the certificates on each machine. At this point I can then enable TLS as follows:-

Outbound in [Mail Policies > Destination Controls].
Inbound in [Mail policies > HAT Overview > mail flow policies].

Assuming the above is correct, (please feel free to remark), my questions are as follows:-

1) When I do the CSR what information is key for the trust relationship to work. For example is the DNS name used for the MX important.
2) When I send the CSR to the CA they have lots of certificate options. The IronPort admin guide states I need a X.509 certificate do I simply ask for this.
3) As I am receiving / sending email from several domains how do I lock this down so that only one particular domain uses TLS.
- For Inbound do I just enable TLS on all policies and set it to preferred.
- For Outbound do I just set default destinations controls to TLS preferred.

As I said I have not worked on IronPort for a while so have been thrown a hot potato here. Unfortunately the system is processing email for several domains and there is zero tolerance on downtime so any help on this would be much appreciated. I worry about the impact such changes may have.

[Enrico Werner · Accepted solution]

You must enable TLS for any listeners where you require encryption for inbound connections. You may want to enable TLS on listeners facing the Internet (public listeners), but not for listeners for internal systems (private listeners). Or, you may want to enable encryption for all listeners. By default, neither private nor public listeners allow TLS connections. You must enable TLS in a listener’s HAT to enable TLS for inbound (receiving) email (either public or private listener). The mail flow policy settings for private and public listeners have TLS turned 'off' by default.

## You can specify 3 different settings for TLS on a listener:

1. No - TLS is not allowed for incoming connections. Connections to the listener will not require encrypted SMTP conversations. This is the default setting for all listeners you configure on the appliance.
2. Preferred - TLS is allowed for incoming connections to the listener from MTAs.
3. Required - TLS is allowed for incoming connections to the listener from MTAs, and until a STARTTLS command is received, the IronPort appliance responds with an error message to every command other than NOOP, EHLO, or QUIT. “Requiring” TLS means that email which the sender is not willing to encrypt with TLS will be refused by the IronPort appliance before it is sent, thereby preventing it from be transmitted in the clear.

## To enable TLS on a HAT mail flow policy for a listener via the GUI, follow these steps:

1. From the Mail Flow Policies page, choose a listener whose policies you want to modify, and then click the link for the name of policy to edit. (You can also edit the Default Policy  Parameters.) The Edit Mail Flow Policies page is displayed.
2. In the “Encryption and Authentication” section, for the “Use TLS:” field, choose the level of TLS you want for the listener.
3. Click Submit.
4. Click the Commit Changes button, add a optional comment if necessary, and then click Commit Changes to save the changes.

The mail flow policy for the listener is updated with the TLS setting you chose.

## To enable TLS on a listener via the CLI, follow these steps:

1. Use the listenerconfig -> edit command to choose a listener you want to configure.
2. Use the hostaccess -> default command to edit the listener’s default HAT settings.
3. Change the TLS setting by entering one of the following choices when you are prompted with the following questions:

    Do you want to allow encrypted TLS connections?

    1. No

    2. Preferred

    3. Required

    [1]>3

4. Issue the commit command to enable the change.

Once you have configured TLS, the setting will be reflected in the summary of the listener in the CLI. For example:

    Name: Inboundmail

    Type: Public

    Interface: PublicNet (192.168.2.1/24) TCP Port 25

    Protocol: SMTP

    Default Domain:

    Max Concurrency: 1000 (TCP Queue: 50)

    Domain map: disabled

    TLS: Required

## To enable TLS for outbound mail delivery

1. Navigate to Mail Policies > Destination Controls
2. If you do not want to enable TLS as default for all remote domains please click on "Add Destination"
3. In "Destination" add the remote domain you need to enable TLS for
4. Select the TLS Support

*** Preferred
TLS is negotiated from the Cisco 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.

*** Required
TLS is negotiated from the Cisco appliance interface to MTA(s) for the domain. No attempt is made to verify the domain’s certificate. If the negotiation fails, no email is sent through the connection. If the negotiation succeeds, the mail is delivered via an encrypted session.

*** Preferred (Verify)
 TLS is negotiated from the Cisco appliance to the MTA(s) for the domain. The appliance attempts to verify the domain’s certificate.

Three outcomes are possible:

- TLS is negotiated and the certificate is verified. The mail is delivered via an encrypted session.
- TLS is negotiated, but the certificate is not verified. The mail is delivered via an encrypted session.
- No TLS connection is made and, subsequently the certificate is not verified. The email message is delivered in plain text.

*** Required (Verify)
 TLS is negotiated from the Cisco appliance to the MTA(s) for the domain. Verification of the domain’s certificate is required.

Three outcomes are possible:

- A TLS connection is negotiated and the certificate is verified. The email message is delivered via an encrypted session.
- A TLS connection is negotiated but the certificate is not verified by a trusted CA. The mail is not delivered.
- A TLS connection is not negotiated. The mail is not delivered.

5. Commit your changes

For more information check these articles:

How can I enable alerts for failed TLS connections?
http://tools.cisco.com/squish/36c40

Transport Layer Security (TLS) Comprehensive Setup Guide
http://tools.cisco.com/squish/4643C

Please note that it is recommend to install signed SSL certificates with TLS enabled.

1) When I do the CSR what information is key for the trust relationship to work. For example is the DNS name used for the MX important.

>> Add the hostname of the appliance into the CN of the certificate. You can also add domain names into the SAN part of the certificate.

2) When I send the CSR to the CA they have lots of certificate options. The IronPort admin guide states I need a X.509 certificate do I simply ask for this.

>> The format should be either PEM which can be loaded using the CLI command certconfig or PKCS#12 that can be loaded via the GUI.

3) As I am receiving / sending email from several domains how do I lock this down so that only one particular domain uses TLS.
- For Inbound do I just enable TLS on all policies and set it to preferred.

>> If there is only one sender then create a new sendergroup and add the senders IP address in that new sendergroup. Apply a mail flow policy with TLS enabled, either preferred or required.
- For Outbound do I just set default destinations controls to TLS preferred.

>> Using the default dest. control will affect all outbound emails. So here you can create a new entry for the destination domain you want to use TLS for.

Installing Certificates on an Email Security Appliance
http://tools.cisco.com/squish/3Db6d

I hope this helps.

Regards,

Enrico

If you have received the answer to your original question, and found this helpful/correct - please mark the question as answered.

[paultribe]

Thank you very much for your response I will be speaking to customer very soon and now feel very confident I understand what is required.

If you don't mind can I ask a couple of final questions:-

1) I typically work with PKI on routers (DMVPN/IPSec phase 1 auth), so it is always clear where we need to distribute certificates and who requires encrypted tunnels. With email it seems a little more distorted though. Would you say it is normal for a customer who owns a domain (my customer), to know which domains they can exchange TLS mail with, i.e.Creating a new destination control for the domain you can send TLS mail to.

2) To enable TLS inbound you say "If there is only one sender then create a new sender group and add the senders IP address in that new sender group. Apply a mail flow policy with TLS enabled, either preferred or required.". This is where I get confused with IronPort. As i understand it no senders have to be specified here as email is received from any MTA. I do not have any senders specified here so do I simply add the the new sender group to the HAT policy and reference a new mail policy with TLS enabled and NO senders ?

Thanks.

[Enrico Werner]

Hi,

1.) There are customers knowing for sure they want to encrypt connections to their business partners. Lets say there is bank-A.com who communicates with bank-B.com. In this case they will configure an entry in the Dest Control table for bank-B.com with "TLS required verify".

Any other customer would (if at all) simply configure TLS to preferred in the default dest. control table in order to encrypt connection whenever possible and still allow message transfer in clear text when TLS is not offered by the destination system. This would be a typically standard configuration scenario and is probably what you are looking for.

2) There is indeed no need to specify senders if you want to enable TLS in general for any sender. Simply enable TLS preferred in the default mail flow policy and make sure that all other mail flow policies are configured to "use default".

Only if you want to enable TLS for particular senders then it is best to create a new sendergroup, let's name it "TLS_Senders" and add all IP addresses into that group. Place this group below the Blacklist and before the Suspectlist in order to skip any matches on SBRS.

WHITELIST
BLACKLIST
TLS_Senders
SUSPECTLIST
UNKNOWNLIST
ALL

Then you will need to create a new mail flow policy with TLS enabled (preferred or required) and apply this new mail flow policy to the new TLS_Senders group. Again, this is only useful if you know the senders where you want to make sure that inbound connections from those senders are TLS encrypted.

I hope this helps.

If you have received the answer to your original question, and found this helpful/correct - please mark the question as answered.