If a certificate contains Subject Alt Names, the name in the Subject – the Common Name – should not be used for verification. This is defined in RFC 6125, published in March 2011. Not all old browsers support this rule. It is important that you make sure that new applications and clients support this.

This test is similar to test #3 – but this time we’ve added some strange Subject Alt names to make it harder for your client.

The certificate for this server has a correct name in the CN field, but not in the Subject Alt Name values. A modern client should not accept this certificate. Note the strange URI’s in the list of subject alt names.

The subject is correct, but the subject alt names are not valid for this server – so the certificate is not valid.

As noted, a client MUST NOT seek a match for a reference identifier of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client.

Therefore, if and only if the presented identifiers do not include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client, then the client MAY as a last resort check for a string whose form matches that of a fully qualified DNS domain name in a Common Name field of the subject field (i.e., a CN-ID).

Fork us on Github

All the tests, including keys and certificates, are available on Github.
https://github.com/edvinanet/tls-o-matic
That's also where you will find all the current tests while waiting for us to write documentation here.

What is TLS?

"The TLS protocol provides communications security
over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery."
From RFC 5446 that defines the current TLS - version 1.2. Wikipedia is also a good help in explaining TLS.