Enabling Cisco IronPort to use TLS when in cluster

[paultribe]

My Sceanrio

I have two IronPort deviecs and I need to enable TLS for certain external and internal domains. I belive I understand how to confgure this but really do not know what certificate to purchase. Therefore can anyone please help with the following questions:-

1) When in cluster is an SSL certifcate required for all appliances in the cluster.

2) What type of certificate do you request from the provider (E.g. from Verisign or Thawte), they have so many different options.

3) Does the type of certificate depend on what you want to do can anyone give any examples. In my scenario, the customer needs to protect email they send and recive from multiple bu not all domains externally and multiple but not all domains internally.

Can anyone help please ?

Regards

Paul

[Mathew Huynh]

Hello Paul, 

See my in-line comments.

1) When in cluster is an SSL certifcate required for all appliances in the cluster.

> This depends on the requirement of TLS verify being used or not, if TLS verify is not being used, generally a wildcard or SAN certificate setup should be fine/suffice without any issues

If TLS verify is required, i believe each device in the cluster will need it's own unique certificate installed with the common name reflecting the DNS hostname for that device.

2) What type of certificate do you request from the provider (E.g. from Verisign or Thawte), they have so many different options.

> This is entirely up to you on which you feel is best.

Generally i've seen godaddy, thawte, verisign be used without issues.

3) Does the type of certificate depend on what you want to do can anyone give any examples. In my scenario, the customer needs to protect email they send and recive from multiple bu not all domains externally and multiple but not all domains internally.

> Certificate is use to validate the sender/recipient mail servers before deliveries.

Check if it's legitimately owned by that network owner and a valid server or not.

Certificates is NOT required for TLS in most cases. but it is still beneficial to have for instances where you'll use TLS verify.

Enabling TLS for inbound (where you encrypt traffic connections from external senders) is done in the Mail flow policies

Enabling TLS for deliveries to domains is done in Destination Controls.

On your online help it will give you more details to

Preferred TLS

Preferred Verify TLS

Required TLS

Required Verify TLS.

[paultribe]

Thank you for all your comments, much appreciated. Apologies for my delayed reply.

I am still a little confused (Apologies but I normally work with routers, switches and firewalls etc so not had much exposure to email filtering using TLS etc).

To be clear:

1) I get a certificate for each IronPort in the cluster that matchs the DNS A records for the MX record.

2) To enable TLS for domains outbound and outside of my "customer" I could do the following:-

- Match the domain(s) in destination controls.

3) To enable TLS Inbound to my public listener (E.g. InBoundMail) I could do the following:-

- Match the domains I expect to receive TLS encrypted email from in a sender group.

- Create a mail policy that has TLS enabled.

- Associate the new sender group with the new TLS mail policy and place at top of the HAT.

So the above deals with all email exchanged between the Internet and my public listener which raises a big question for me - How to I ensure TLS works between the IronPort and my internal domain ??? Is this also configured under destination controls ??? Again, apologies for my confusion.

And finally what is the best process to ensure one certificate is asigned to the listeners of one of the machines in the cluster and the other is assigned to the other machine in the cluster. I tried using the management override and found that configurations were not syncing properley.

[Mathew Huynh]

To be clear:

1) I get a certificate for each IronPort in the cluster that matchs the DNS A records for the MX record.

>> If each device in the cluster has a unique certificate for TLS required-verify, you need to ensure the certificates common name (CN) matches that of the public DNS MX record, if this is as you've done, then it's correct :)

2) To enable TLS for domains outbound and outside of my "customer" I could do the following:-

- Match the domain(s) in destination controls.

 > This is correct, destination controls handles outgoing connections (DCID) from the ESA to the required domains.

3) To enable TLS Inbound to my public listener (E.g. InBoundMail) I could do the following:-

- Match the domains I expect to receive TLS encrypted email from in a sender group.

- Create a mail policy that has TLS enabled.

- Associate the new sender group with the new TLS mail policy and place at top of the HAT.

> Note Sendergroups (HAT table) does not use domain matching, but it matches against connecting mail hosts.

EG: gmail.com uses mta.google.com (for example) so if you want to allow gmail.com domain through a specific sendergroup, you'll need to either add their server IP, or partial/full hostname of mta.google.com or simply .google.com

---

So the above deals with all email exchanged between the Internet and my public listener which raises a big question for me - How to I ensure TLS works between the IronPort and my internal domain ??? Is this also configured under destination controls ??? Again, apologies for my confusion.

---

> To ensure Exchange to ESA and ESA to change is done under TLS.

Your Exchange to ESA would be for outgoing emails where user > exchange > esa > internet

Then you need to ensure your RELAYLIST (outgoing sendergroup) and RELAY mail flow policy is set to have TLS set to 'preferred' or 'required' depending on what you want to have done.

This will encrypt the connection from Exchange to ESA.

Then destination control will handle from ESA -> Internet based on what you have configured

From ESA to exchange, again the use of destination control will ensure from the DCID from ESA to exchange is encrypted with TLS.

---

And finally what is the best process to ensure one certificate is asigned to the listeners of one of the machines in the cluster and the other is assigned to the other machine in the cluster. I tried using the management override and found that configurations were not syncing properley.

---

> You'll need to make sure that if you've added the certificate in GUI > Network > Certificates, if it's at the cluster level then you'll need to change it to machine (override cluster) on each device and load the individual certificate in.

Have the certificates under the same certificate name for ESA reference purposes.

Then commit changes.

then go to GUI > Network > Listeners

Leave it at cluster level but make it look for the common certificate name.
As the certificate name is the same but the actual certificate is unique, each device will have it's unique certificate there.

Else you can override this one as well to machine.

Once all of them are committed it should work as expected.

[Paul Cardelli]

I Agree with the comments made so far. Some free tools externally you can use to test your TLS implementation, 

MXTOOLBOX.com

checktls.com

Another way to test is to check the headers in your messages, there are a few transport methods that are the equivalent to TLS. I use the header analyzer on mxtoolbox.com. Also don't forget to configure your reverse DNS (usually setup with your ISP), to match your Public DNS.

Personally I have used a wildcard cert, I set TLS in my policies to preferred. For specific domains I have a policy I use to set those to required. I have been seeing 60-70% emails using TLS. You do have to configure your internal email servers to require/prefer TLS to complete the chain.

Also if you use CRES for email encryption, I use Tagged mode, and for those with TLS we skip the envelope layer, but if TLS fails then we send via encrypted envelop. This all depends on your policies and the comfort level with email encryption. Personally if you are not using passwords to open encrypted emails then TLS is pretty close to it equal minus forwarding and replies.

[Ken Stieers]

1.  Any member of the cluster that will exchange mail with outside mail hosts will need a cert if you want them to use TLS.

2.  An standard web server cert will do.  It doesn't have to be a SAN/UC cert.  It just has to match the A record that the MX record(s) point to.

3. We need a bit more info.  How many of the domains have MX records that point do A records that match them :

mx  company1.com   smtp1.company1.com

a    smtp1.company1.com   10.10.10.10

mx  company2.com   smtp1.company2.com

a    smtp1.company2.com   10.10.10.10

vs

mx company1.com  smtp1.company.com

mx company2.com  smtp1.company.com

a smtp1.company.com  10.10.10.10

You only need a cert to match the SMTP boxes, not the companies.

And YES, you have to have a cert for TLS, but you can use the demo cert unless the other end is doing cert validation.  Think of web browsing and hitting a self-signed cert, what happens? you get a cert error... stuff is encrypted, but cert doesn't match the domain name.   With TLS, the error gets ignored unless cert validation is on.

If you're doing TLS internally (between the groupware and Ironport), you need certs on the groupware boxes too (though you probably don't need cert validation turned on...)

[paultribe]

Thank you all for your comments, much appreciated. Apologies for my delayed reply.

I am still a little confused (Apologies but I normally work with routers, switches and firewalls etc so not had much exposure to email filtering using TLS etc).

To be clear:

1) I get a certificate for each IronPort in the cluster that matchs the DNS A records for the MX record.

2) To enable TLS for domains outbound and outside of my "customer" I could do the following:-

- Match the domain(s) in destination controls.

3) To enable TLS Inbound to my public listener (E.g. InBoundMail) I could do the following:-

- Match the domains I expect to receive TLS encrypted email from in a sender group.

- Create a mail policy that has TLS enabled.

- Associate the new sender group with the new TLS mail policy and place at top of the HAT.

So the above deals with all email exchanged between the Internet and my public listener which raises a big question for me - How to I ensure TLS works between the IronPort and my internal domain ??? Is this also configured under destination controls ??? Again, apologies for my confusion.

And finally what is the best process to ensure one certificate is asigned to the listeners of one of the machines in the cluster and the other is assigned to the other machine in the cluster. I tried using the management override and found that configurations were not syncing properley.

[Ken Stieers]

2) only do that for the ones that you require TLS for.  You set TLS to preferred, and it will try to send via TLS, and if it can't, it will fall back.

For the internal side you need to config your email system to send via TLS.

For the ESA, go to Mail Policies/Mail Flow Policies, pick the other listener, which will show 2 policies, "Relayed" and "Blocked".  Edit the Relayed one and set it to use TLS.

For the certificate configs, you want to make sure you're in "machine mode" when you import/configure the certs.