cancel
Showing results for 
Search instead for 
Did you mean: 

TLS basics

Jump to solution

We are preparing to implement TLS per request from one of our external business partners.

1 - When requesting certificates, I am planning to request one for mailhost1.mydomain.com and one for mailhost2.mydomain.com (the host-names of the defined MX servers).

Does that sound correct?

2 - The Ironmail system processes email for several domain-names (subsidiaries of our company).   There is only one host (no virtual hosts wihtin Ironmail).

Does the one certificate (for mailhost1.mydomain.com) take care of any traffic on that host, or do I need a separate certificate for each of the domain-names?

3 - Any suggestions on how to test TLS inbound and outbound?  I do not want to have a situation where we are refusing email or our partners refuse our email while we "debug" our TLS process.

Thanks...

1 Solution

Accepted Solutions

Re: TLS basics

Jump to solution
  1. Yes, use the host names as given in the MX records.
  2. Use the names listed in the MX records.  Assuming that the other domains list your MX records, and not some separate name in the other domain, this will work fine.  For example, the MX records for nai.com are relaydal6.nai.com and sncwsrelay1.nai.com.  The NAI servers handle mail for McAfee, but McAfee's MX records do not say mcafee.com.  They are relaydal6.nai.com, sncwsrelay1.nai.com, sncwsrelay2.nai.com, and relaydal4.nai.com. (Note that the McAfee MX records are not a good example if you actually go look at the presented certificates, they are self-signed and don't even have a CN)
  3. As mentioned by DBO, checktls.com is a good site to test mail servers.  If the host is not on the internet, openssl is a good tool to use.  It is on OSX and every Linux system I have seen, and is available for Windows.  The syntax for testing SMTP TLS is:  `openssl s_client -connect host:25 -starttls smtp`.  Optionally, if you have a file with root CA certificates, you can add `-CAfile path/to/file`, or if they are individual files in a directory, you can add `-CApath path/to/certs`.  Specifying the CApath or CAfile will make sure that the certificates are fully checked, with the exception of host name matching certificate CN.

Hopefully that all made sense.

View solution in original post

5 Replies
Highlighted
DBO
Level 9
Report Inappropriate Content
Message 2 of 6

Re: TLS basics

Jump to solution

You can use Openssl for a local test or the CheckTLS.com site for a remote test

http://www.checktls.com/perl/TestReceiver.pl?ASSURETLS

Re: TLS basics

Jump to solution

Thanks for the information.  I had found the 'checktls.com' site but wasn't sure if it was legitimate -- so it is good to have the reassurance.

Re: TLS basics

Jump to solution
  1. Yes, use the host names as given in the MX records.
  2. Use the names listed in the MX records.  Assuming that the other domains list your MX records, and not some separate name in the other domain, this will work fine.  For example, the MX records for nai.com are relaydal6.nai.com and sncwsrelay1.nai.com.  The NAI servers handle mail for McAfee, but McAfee's MX records do not say mcafee.com.  They are relaydal6.nai.com, sncwsrelay1.nai.com, sncwsrelay2.nai.com, and relaydal4.nai.com. (Note that the McAfee MX records are not a good example if you actually go look at the presented certificates, they are self-signed and don't even have a CN)
  3. As mentioned by DBO, checktls.com is a good site to test mail servers.  If the host is not on the internet, openssl is a good tool to use.  It is on OSX and every Linux system I have seen, and is available for Windows.  The syntax for testing SMTP TLS is:  `openssl s_client -connect host:25 -starttls smtp`.  Optionally, if you have a file with root CA certificates, you can add `-CAfile path/to/file`, or if they are individual files in a directory, you can add `-CApath path/to/certs`.  Specifying the CApath or CAfile will make sure that the certificates are fully checked, with the exception of host name matching certificate CN.

Hopefully that all made sense.

View solution in original post

Re: TLS basics

Jump to solution

Our business partner sent us some instructions.

This setup seems to be very unusual -- does it seem that way to you?   I have no experience with setting up TLS so perhaps this is a common way to configure.  Basically they are saying we have to redefine the MX records for their company so that we send to specific servers.  

Could I accomplish this in Ironmail I can do this with mail-routing instead of messing with the MX records?

Company B says: "we do not support opportunistic TLS."

Company B says "our servers are Linux based and does not hold a certificate needed for TLS communications with specific Email domains.   Typically, our business partners employing this encryption have edited their DNS record for CompanyB domains to use the IP addresses/MX record: 65.123.456.78) (tls2.tls.companyb.com), 12.123.456.78 (tls1.tls.companyb.com).  These are redundant legs of our TLS system on different pipes and CO’s.  You cannot use the Internet-based DNS record for CompanyB.com because they point to the Linux servers that do not hold certificates.

Re: TLS basics

Jump to solution

Yes, this is an unusual setup.  Only once or twice have I seen this required in the past.  To do this with IronMail, go to IntrusionDefender --> Mail Routing --> Domain  Based.  Click on Add New.  The Protocol is SMTP, the Domain Name will be the recipient's domain (ex. domainb.com), Routing Type is Static Outbound, and Machine Name/DNS/Domain Name will be the IP addresses that they want you to send to, in a comma separated list.

Note that if they ever change these hosts that communication will break, as opposed to just moving to the new host as it would if they were using DNS.

More McAfee Tools to Help You
  • Subscription Service Notification (SNS)
  • How-to: Endpoint Removal Tool
  • Support: Endpoint Security
  • eSupport: Policy Orchestrator
  • Community Help Hub

      New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

    • Find Forum FAQs
    • Learn How to Earn Badges
    • Ask for Help
    Go to Community Help

    Join the Community

      Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

    • Get helpful solutions from McAfee experts.
    • Stay connected to product conversations that matter to you.
    • Participate in product groups led by McAfee employees.
    Join the Community
    Join the Community