We turned on TLS Preferred between our exchange server and IronPort, and also between IronPort and the outside world. I do see that it is using TLS for a percentage of messages. I did run a check tls from a third party website and everything checks out ok except there was a warning that our certificate name did not match the mx record.
Ironport.domain.com is the certificate (2048-bit) from Starfield CA that connects to the outside world.
The warning said that the cert Ironport.domain.com did not match advertised MX server name mail.domain.com.
It still allows TLS but I want to make sure things will not be broken. We have it set to TLS - Preferred (note were not forcing it) in hopes that if this TLS fails it will just go out unencrypted as we want to make sure no e-mail is lost.
I do notice that yahoo.com has a lot of TLS Pref. Failed, but I see LOTS of TLS Pref. Sucess to gmail.com, aol.com, att.net, sprintpcs.com, vtext.com, etc... so I can tell it IS working.
TLS Pref. FaIed was to:
yahoo.com, ymail.com, rocketmail.com, gmx.com, mail.com, email.com. Hopefully the message still made it to those domains (though understandably in the clear)
If certificate name is different than you need to trust that certificate or do not check if certificate is valid.
It's the same thing when you are online with your browser and there is wrong certificate that does not match FQDN of the site, you need to say that you want to proceeed after you see warning page.
How does it work:
If you set preffered then you do not check if destination MTA certificate is valid and that is Ok.
If you set preffered - verify then you will verify destination certificate and you will establish TLS only if destination MTA have valid certificate.
Well sites that you mentioned for TLS Pref. failed is normal normal beacuse all that MTA's does not support TLS.
Many MTA's does not support TLS (or it's not configured) and usually TLS is used only for company to company communication (configred by Destination Control) not for whole internet beacuse of performance impact.
Example why TLS failed (one of yahoo.com MTA's) - In SMTP communication there is no 250-STARTTLS so it does not support TLS
Connecting to 184.108.40.206
220 mta1027.mail.gq1.yahoo.com ESMTP YSmtpProxy service ready [671 ms]
We've had TLS enabled since this post, 5 months ago.
As of this Tuesday morning one of the companies we do business with can no longer email us. We can email them, but if they reply we never get it. We don't even SEE the message touch the ironport. Their IT department looked and said it was because our TLS cert wasn't trusted or it was self signed.
Ok well the odd thing is prior to this Tuesday morning we were conversing with them over thousands of TLS Pref. Success... not only that but many other domains have successes like 24.5k successes to gmail.com for one example. So we changed our cert to a wildcard cert and also uploaded the intermediate cert. We did a test from checktls.com and all 8 TLS tests come back green and "OK". Cert verifies no problem. I can send mail to them via TLS and they can connect to us via TLS. According to them there is no issue.
So why all of a sudden as of this tuesday, this one very important vendor is having email issues with us and another client? Surely this can't be our issue if we have thousands of successful messages to many other domains, right? Is there another test that checktls.com is not doing that I can try?
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
[toc:faq]Introduction:This document describes details on how NAT-T
works.Background:ESP encrypts all critical information, encapsulating
the entire inner TCP/UDP datagram within an ESP header. ESP is an IP
protocol in the same sense that TCP and UDP are I...