Mon, 30 Apr 2018 Frequently Asked Questions
CheckTLS Source IP Addresses and Domain Names
What is the difference between Professional and Corporate Level Subscriptions?
Why Do You "Score" TLS Instead of Giving a Yes or No Answer?
May We Use the CheckTLS Name and/or Logo?
How Do I Fix My Email?
Do You Have a Non-Working TLS Host I Can Test With?
Why Two Different Credentials: CustomerCode and UserCode?
CheckTLS Shows Hostname Verify Error But OpenSSL Does Not?
Why Is My Email Slow?
Mon, 30 Apr 2018 CheckTLS Source IP Addresses
Add the following IP addresses and domain names to any network filters and/or domain Whitelists at your site.
IP Addresses: 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 2604:a880:800:a1::2b2:f001, 2604:a880:800:10::273:a001 Domain Names: CheckTLS.com and *.CheckTLS.com
Adding our IP address range to any network filters makes sure our tests are able to do the testing you request from our site.Our tests are non-invasive, non-intrusive, and non-obtrusive. They require no changes to your or any other system. They cause no extra processing and should not trip any security alarms.
Adding our domain to any Whitelists also makes sure our tests can do the testing you request, and it also makes sure any results we email to you get through to you and don't end up in a junk folder or thrown away.
Corporate is everything in Professional plus the ability to store batches (lists) of addresses and test them automatically on a schedule.
Professional is access to the raw tools, Corporate makes them easy to use over and over.
Professional tests things one time, Corporate is "set it and forget it" continuous monitoring of one or more email systems.
You can achieve HIPAA Compliance with Corporate. See email compliance
Corporate also has Internet Packet Sniffer and Protocol Analyzer -- very powerful tools that take some time to learn and setup.
Mon, 30 Apr 2018 Why Do You "Score" TLS Instead of Giving a Yes or No Answer?
TLS is not Yes or No. Take for example a domain that has a primary and a secondary (backup) MX host. If the primary has TLS but the secondary does not, is email to that domain encrypted or not?
Our Confidence Factor℠ takes this into account. It accounts for two or more MX hosts, how they are prioritized, how good each of their TLS configurations are, such as what versions and cyphers they are using, etc.
Even for single MX hosts, the Confidence Factor℠ considers versions, cypher strengths, key sizes, certificates, DNS setup and name matching, etc.
Note that two or more MX hosts are common in medium sized organizations. They have their own email system, but subscribe to a cloud email provider as a backup. Their own email system has a higher MX priority than the backup, so the primary is always tried and used first. It is only when their own email system is down for maintenance or has a problem that the cloud provider receives their email. The backup typically stores the email and sends it to the primary when the primary comes back online. That connection may or may not be secure also, depending if the backup can send using encryption.
That's why we created the Confidence Factor℠. It shows the shades of gray. We suggest that a CF of 90 and above is good. But we don't unequivocally say "yes" unless it's 100%. And even then your own policy may demand a higher degree of encryption, etc. We provide the tools for you to explore your, and your customers', levels of email security.
Mon, 30 Apr 2018 May We Use the CheckTLS Name and/or Logo?
Yes, Corporate Subscribers may publish their affiliation with CheckTLS on-line and on printed or other media.
We currently have no requirments for this use, but we ask that you include "CheckTLS
As part of this published affiliation you may use any of our service marks such as CheckTLS℠, ForceTLS℠, MonitorTLS℠, "Verified TLS"℠, and "Confidence Factor"℠.
Mon, 30 Apr 2018 How Do I Fix My Email?
My email fails one or more of your tests.
XYZ company will not do business with us unless we pass your test(s).
You must secure your email system. Usually this means TLS encrypting email you send to others and accepting TLS encrypted email from others.
Securing your email system is outside the scope of our site. Try searching the Internet for "howto TLS" and the name of your email software, e.g. "Office 365".
You can also search the Internet for local consultants that can help you with your email system.
Mon, 30 Apr 2018 Do You Have a Non-Working TLS Host I Can Test With?
Yes. You can use test@NoTLS.CheckTLS.com
Obviously, test@CheckTLS.com is a working TLS host you can test with.
Tue, 01 May 2018 Why Two Different Credentials: CustomerCode and UserCode?
Individuals have their own UserCode and Password.
Corporate Subscriptions have a separate CustomerCode and Password.
UserCodes allow Individuals to login to CheckTLS and interact with it. CustomerCodes allow unattended use of Web Services.
Having separate credential types allows Individuals to keep their credentials secret and not listed in the source code for Web Service calls.
Corporate Subscribers can see their CustomerCode and CustomerPass HERE.
Mon, 30 Apr 2018 CheckTLS Shows Hostname Verify Error But OpenSSL Does Not?
Before configuring enforced SMTP/TLS for specific recipient domains I usually check the configuration of that recipient domain's mail server with checktls.com.
Now I have a case which I do not understand: xxxOur.com [ed note: all domain names changed for privacy]
MX records are pointing to servers with domain name ending with .xxxMX.com The certificates CN = *.xxxCN.com
checktls.com states: [001.084] Cert VALIDATED: [001.084] Cert Hostname DOES NOT VERIFY (mx5.xxxMX.com != *.xxxCN.com | DNS:*.xxxCN.com | DNS:xxxCN.com) [001.084] (see RFC-2818 section 3.1 paragraph 4 for info on wildcard ("*") matching) [001.084] So email is encrypted but the host is not verified
But when I test with openssl I receive: Verify return code: 0 (ok)
And when I enforce SMTP/TLS (it's a sendmail MTA) for domain xxxOurDomain.com, mails are being delivered and the log says: tls_verify=OK
I can see the following SMTP banner and response from the SMTP server in the greeting section after the EHLO submitted by the SMTP client: 250-mx1.xxxCN.com
Does this mean that it's sufficient if a certificate CN matches the SMTP banner for openssl to regard an SMTP/TLS connection as verified?
This looks somewhat confusing to me.
Can you provide me some more information about this specific topic? I'm especially interested in what names are involved in certificate verification during an SMTP/TLS handshake.
You are asking how various programs use three different hostnames:
- MX Host
- The host (mx1.xxxMX.com) identified to receive email for a domain (xxxOur.com). It comes from looking up the recipient's domain in the Internet Domain Name System.
- CN Entry
- The host or host-wildcard (xxxCN.com) given in the SSL Certificate of the MX Host.
- HELO/EHLO Host
- The hostname returned in response to an SMTP HELO/EHLO command
A site can return any hostname in their HELO/EHLO response, so it is not a reliable security constraint. However many mailers will log a security warning when they find a mis-match between what they are expecting in the HELO/EHLO response and what they receive.
The more detailed Output Format levels of the CheckTLS test show the HELO/EHLO response but CheckTLS does not try to match it against anything and it does not affect the Confidence Factor. (TestReceiver)
The CN Entry is a field included in a site's SSL Certificate. Because the certificate is encrypted and should be signed by a trusted Certificate Authority, the CN Entry is a reliable security constraint.
The MX Host comes from a DNS lookup. A DNS lookup is not completely secure, and there are projects working on making it more secure, but MX Hosts from DNS lookups are considered a reliable security constraint.
But Why Does CheckTLS Complain When OpenSSL and My Mailer Do Not?
Current versions of openssl do not check for any hostname matches. It reports the name but does not use it. You can see this for yourself using:
openssl s_client -connect mail4.checktls.com:25 -starttls smtp -servername baddomain.com
This tells openssl to connect to one of our MX Hosts and to expect it to be named "baddomain.com". openssl happily and without reporting anything out of the ordinary connects to our host, even though it clearly the host it connected to (mail4.checktls.com) has nothing to do with baddomain.com.
Most mailers do check that the MX Host match the CN Entry, but they just log a warning (which no one ever sees) and continue to send the email. This is consistent with the traditional Internet mantra of "the data must get through".
Some mailers can be configured, or may even be configured out of the box, to fail if the MX Host does not match the CN Entry. Security is becoming more prevalent in today's world.
Thank you CheckTLS!
CheckTLS does compare the two reliable security constraint names.
Since a mis-match typically does not prevent email from going through, CheckTLS only warns about mis-matches (in yellow) and includes a note that email will be encrypted (i.e. safe from prying eyes) but there is a small chance it is being sent to the wrong place. And since it is their certificate that is encrypting the email, they will be able to read it.
CheckTLS also helps diagnose if your mailer is configured to fail mail when the MX does not match the CN. This can happen without a mail administrator's knowledge, say with a software upgrade, or a new trading partner. Suddenly email stops working, and it is not clear why. CheckTLS shows you the problem.
Mon, 30 Apr 2018 Why Is My Email Slow?
There are uncountable reasons why email may be slow, so CheckTLS cannot tell you exactly what is wrong with yours. But CheckTLS can show you exactly how much time each step of an email transfer is taking, so you know where to focus your efforts.
For example the below real-world test (the names have been changed to protect the guilty) shows an email server that is taking just over 20 seconds to issue the very first sign-on message (see hilite below).
"slow.com" is an email provider for multiple domains (including somewhere.com), and we suspect that slow.com takes a long time to figure out what it is supposed to do with email for somewhere.com.
CheckTLS does have all of the forward and backward DNS records properly configured for CheckTLS.com, so this server's issue is not in standard email verification DNS timeouts.
somewhere.com should show this to slow.com and demand they fix it. Or get a better email provider.
looking up MX hosts on domain "somewhere.com"
- mx.slow.com (preference:10)
|seconds||test stage and result|
|[000.113]||Connected to server|
|[020.271]||<--||220-mx.slow.com ESMTP Exim 4.89 #1 Sun, 03 Dec 2017 17:16:33 +0000
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.
|[020.272]||We are allowed to connect|
|[020.375]||<--||250-mx.slow.com Hello www4.checktls.com [18.104.22.168]
250-AUTH PLAIN LOGIN
|[020.375]||We can use this server|
|[020.376]||TLS is an option on this server|
|[020.483]||<--||220 TLS go ahead|
|[020.483]||STARTTLS command works on this server|
|[020.722]||SSLVersion in use: TLSv1.2|
|[020.722]||Cipher in use: ECDHE-RSA-AES128-SHA256|
|[020.722]||Connection converted to SSL|
|...rest of output deleted...|