Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

TLS security when cert name is different

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.

Example)

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)

  • Email Security
Everyone's tags (4)
3 REPLIES
New Member

Re: TLS security when cert name is different

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 98.136.216.26

220 mta1027.mail.gq1.yahoo.com ESMTP YSmtpProxy service ready [671 ms]

EHLO MXTB-PWS3.mxtoolbox.com

250-mta1027.mail.gq1.yahoo.com

250-8BITMIME

250-SIZE 41943040

250 PIPELINING [671 ms]

MAIL FROM: <supertool@mxtoolbox.com>

250 sender <supertool@mxtoolbox.com> ok [671 ms]

RCPT TO: <test@example.com>

550 relaying denied for <test@example.com> [671 ms]

MXTB-PWS3v2 3448ms

---

Example why TLS success (one of google.com MTA's) - In SMTP communication there is 250-STARTTLS, so it does support TLS

Connecting to 173.194.64.26

220 mx.google.com ESMTP f7si9420494oel.119 - gsmtp [624 ms]

EHLO MXTB-PWS3.mxtoolbox.com

250-mx.google.com at your service, [64.20.227.133]

250-SIZE 35882577

250-8BITMIME

250-STARTTLS

250-ENHANCEDSTATUSCODES

250 CHUNKING [624 ms]

MAIL FROM: <supertool@mxtoolbox.com>

250 2.1.0 OK f7si9420494oel.119 - gsmtp [624 ms]

RCPT TO: <test@example.com>

550-5.1.1 The email account that you tried to reach does not exist. Please try

550-5.1.1 double-checking the recipient's email address for typos or

550-5.1.1 unnecessary spaces. Learn more at

550 5.1.1 http://support.google.com/mail/bin/answer.py?answer=6596 f7si9420494oel.119 - gsmtp [3635 ms]

MXTB-PWS3v2 6037ms

---------

I hope this help.

New Member

We've had TLS enabled since

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?

 

Appreciate the input!

My guess is that they turned

My guess is that they turned on the "check cert validity" switch on their MTA, and since you were using one that didn't match, it started to fail....

 

1197
Views
0
Helpful
3
Replies
This widget could not be displayed.