These steps walk you through configuring TLS encryption on email communication with specific partner domains or configuring TLS for all Outbound and Inbound email.
TLS for Incoming Mail
Receiving mail is controlled by the HAT Overview/Mail Flow Policies. In other words, when hosts attempting to send mail to your organization connect to your Ironport appliance.
setup TLS encryption for all inbound email
I chose to set TLS Preferred across the board by enabling TLS on my ‘Accepted’ and ‘Trusted’ mail flow policies (“TLS Preferred”)
To enable TLS for all incoming mail flow policies that take their settings from the Default Policy: Mail Policies > Mail Flow Policies. Select “Default Policy Parameters” . You will want to review the TLS setting of each policy to check if they are taking their settings from the Default Policy.
Alternatively you may want to only enable TLS on incoming email from specific domains.
TLS for outbound Mail
IronPort Destination Controls effect how your Ironport appliance delivers mail to hosts on the Internet (Mail Policies > Destination Controls). Create entries for the domains that need secure TLS communications. If you’re a financial or medical institution and it’s vital that all transactions between you and the Internet be made securely, then you may need to enable it on the Default domain, which will enable TLS for all outbound email.
Prerequisite: The first step is to assign your certificate to Destination Controls
Setup outbound TLS for specific partner domains
In this procedure we will require TLS on communication with selected partner domains.
1) Click the “Add Destination” button:
2) Input the partners domain name in the Destination field
3) Select your TLS requirements in the ‘TLS Support’ drop down. In the example IronPort TLS configuration, I selected “Required – Verify” under ‘TLS Support’ because all communications with this partner are required to be secured with TLS. If TLS cannot be established the mail will not be delivered. In addition, if the partners SSL certificate cannot be verified the mail will not be sent.
4) In order to test, send some emails to the TLS partner domain that you setup in step 3 (partnercompany.com), and then review the Monitor menu page to verify IronPort TLS is working.
Attempt TLS for all outbound communications
In this example, we set it so that all outbound email connections will at least attempt TLS, if TLS is not achieved the mail will be sent as clear text.
1) Enable TLS on the Default Domain destination control: Mail Policies > Destination Controls > Default Destination Controls
I chose preferred since this is the global default I don’t want it overly strict. It will attempt TLS and will not attempt to verify the other parties certificate validity.
The Performance Impact of TLS Encryption
A single TLS connection requires the same amount of server resources as approximately ten clear text conversations. To mitigate the performance impact, there is a limit to the number of simultaneous TLS connections. Currently the limit is 100 inbound and 100 outbound TLS connections.
If the connection limit is reached for outbound connections, AsyncOS will negotiate a clear text conversation with partners whose MTA (message transfer agent) allows it. Where the partner has TLS required, the IronPort appliance will simply wait and try the connection again later.
Hello,
We have 2 Ironport appliances we want to enble TLS on. My question is do we need one SSL certificate per device or per listener, or some other parameter?
Typically you can purchase one SSL certificate and install it on both devices, that cert could be used for all SSL related services on each device. There is a process to create cert request, install cert, export the cert, install the exported cert on the second IronPort. I have all of that on my blog, let me know if you need help and I’ll find the specific blog posts for you.
Hello, thanks for the fast answer :) that blog post would be really helpful, if its not too much trouble to find it :))
Thanks in advance
In the guide on Cisco website it says:
2) Click the Create Self-Signed Certificate drop-down menu.
– When you create the certificate, ensure that the Common Name matches the hostname of the listening interface, or that it matches the hostname of the delivery interface.
– The listening interface is the interface that is linked to the listener that is configured under Network > Listeners.
– The delivery interface is automatically selected, unless explicitly configured from the CLI with the deliveryconfig command.
3) For a verifiable inbound connection, validate that these three items match:
MX record (Domain Name System (DNS) hostname)
Common Name
Interface hostname
See how it says that when generating a self signed certificate it needs to match a listener. How can i obtain a single SSL certificate to use for TLS on all mail?
Here is where I would start:
How to setup SSL Cert on Cisco IronPort ESA
Assign SSL Certificate to Cisco ESA IronPort Services
How to setup TSL on Cisco IronPort ESA
Really a good article about TLS
Hi Chris,
thanks for your great post. I followed your steps and its working.
You could mention that the OutgoingMail (RELAYED) can also be configured with TLS for “incoming” mails, that is, mails from the internal exchange (or whatever) to the ESA. Of course, if two listeners are used, the certificate must be set on both.
[And optional: You could also mention, that the certificate can be set in the “IP Interfaces” settings for the management accesses.]
Thanks again!
Johannes
Hi,
thanks for your input – i also got a reply from cisco: The current software release ( 8.0.1-023) violates the official TLS-specification (if you take a strict approach) which causes cipher mismatches between IronPort and systems using a (newer) OpenSSL-implementation. This also breaks the certificate exchange during the initial connect and is reported as a certificate validation error (so i thought the custom CA-file was ignored for TLS-Mail). The problem should be fixed in the next release, but no ETA yet…
Nice guide, is there any way to manage the IronPort’s CA list? As far as i can tell IronPort uses an internel list of (more or less) trushtworthy CAs but does not provide a way to import your own/your partners CAs or disable CAs that you do not trust so the verification looks pretty useless to me…
Hi Ewe, thanks for your comment. See page 1-26 in the IronPort Advanced Email Configuration Guide.
Here are the relevant sections:
“If you want to use only a subset of the trusted certificate authorities in the system or edit an existing custom list, you can export the list to a .txt file and edit it to add or remove certificate authorities….”
“You can create a custom of list trusted certificate authorities and import it onto the appliance. The file must be in the PEM format and include certificates for the certificate authorities that you want the appliance to trust…”