I was working with a customer the other day who was having some problems with TLS sessions between their Exchange servers and a partner’s. They asked me to help do some troubleshooting. I was home at the time, but since this is Internet edge servers we’re talking about here, I thought I could take a look at a few things remotely, since I too am “on the Internet.” Since the complaint was that they could not establish a TLS session between systems, which is something that was working previously, the first think I asked was, of course, “what changed?” I bet you know what the answer was! So, the next thing I did was try to establish a TLS session myself. I dropped to the command prompt, and entered
telnet customersmailserver.example.com 25 [enter]
220 customermailserver.example.com ESMTP MAIL Service ready
at Wed, 6 Mar 2013 21:12:21 +0000
help [enter]
214-This server supports the following commands:
214 HELO EHLO RCPT DATA RSET MAIL QUIT HELP AUTH BDAT
Hmm, something seems missing there. STARTTLS! According to that response, the server does not support TLS, so I called my customer back and told him “it looks like someone turned off TLS on your server.” He asked why I thought that, so I described what I had done, feeling quite clever really, to have him say something along the lines of “oh, yeah, that wouldn’t work for you. We only allow TLS from certain IP addresses.” To which I replied <blink…blink…> “uhm, why?” I won’t bore you with the details of his response. Trust me when I say it had something to do with a complete misunderstanding of what SMTP/TLS is about, and a false belief that it is risky to use it with just anyone. BZZZZZZ! Wrong answer. So here are some best practices regarding SMTP/TLS that you should implement with your email systems.
1. Obtain your certificates from a public CA.
Exchange 2010 does not require this, and by default will not perform certificate validation, but not everyone uses Exchange. By using certificates from a public CA, you provide more assurance to your partners that your MTA is really yours.
2. Use stronger keys-2048 is a good choice.
Anyone still using keys less than 1024 bits is doing it wrong.
3. Use UCC certificates with a CN and SAN that matches what DNS resolves to any of your MTAs, and configure your MTAs to respond with that FQDN in their 220.
For those systems that do want to validate the certificate, and also that it matches the hostname they are trying to reach, having the DNS name of your MTA in the CN and SAN, and making sure your MTA uses that name in the 220 response, will help partners validate that your server is yours, and ensure even the most tightly configured server can correctly connect to yours.
4. Enable opportunistic TLS for everyone.
There is no reason at all not to use TLS whenever possible. If your server is really so old that you don’t have the CPU cycles to support it, you’ve got more things to worry about than securing email.
5. Enforce TLS for partners when compliance needs require it.
If you are using TLS to meet any compliance requirements for encrypting email, make sure you require TLS for the partner domain, and that the partner’s MTAs all support TLS. Your server cannot verify end to end encryption…only to the next hop, so if there is more of an SMTP path than you can see, you cannot be sure you have end to end encryption.
6. Monitor your server to ensure that TLS is being used as you expect.
Once you enable TLS, make sure your communications are using it by making regular reviews of your logs.
7. Set reminders for certificate renewals so mail flow doesn’t break when a cert expires.
And here we come to the part that would have fixed my customer’s issue above. Certificates expire. You have to renew them before they do, or they stop being useful for most situations. If nothing else, set a reminder in Outlook, or send an invite to everyone on your team for a week before the certificate expires, so that someone will know ahead of time and can renew the certificate before it expires. By the way, when you need to test TLS on your email server, and you want to do a little more than just what you can with TELNET and you don’t have another email server handy, there is a great website that can test your TLS and more. Here’s the link. http://www.checktls.com/perl/TestReceiver.pl
7 Best Practices for SMTP/TLS
Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators
