During these first days since our launch we’ve gotten a lot of feedback. The Internet Society has blogged about us, We have gotten bug reports on github. And we have a lot of new ideas. Some you can see if you peek in at our Github project.

Certificates and TLS is a complex area. We do need your feedback on the tests. For the new tests I had to google quite a while and I am still not sure they’re correct.

Test 16: International characters and emoji in certificate names

DNS now supports a wide range of characters. Domain names with Swedish characters is not uncommon and we’ve seen Coca Cola even use emojis in domain names. So how does this work in certificates? A domain like räksmörgås.se may need a certificate. (If you wonder what it means, click the link). A user

Safari shows the encoded names, not the actual names. Maybe a good browser should display both variants.

Safari shows the encoded names, not the actual names. Maybe a good browser should display both variants.

should expect to see the name with all the characters in the right place in the certificate.

In the protocol, the domain name is translated using puny code to become xn--rksmrgs-exaf1o.se which is the name that is expected to be found in the Subject Alt Name of the certificate.

For this test I did set up test domains using both räksmörgås (a word that includes three Swedish characters) and an emoji. So far, I haven’t found a single browser that shows these in the proper form when displaying the certificate contents. I think this is bad. Why don’t you test for yourself?
If you find a bug in the test, please let me know.

Test 17: Subject Alt Names and CN

RFC 6125, published in 2011, clarifies how clients should perform verification of a certificate given a specific string. Many protocols define their own rules, and a few has – like the SIP Session Initiation Protocol in RFC 5922. If you look carefully into the certificates used in these tests, you will find a SIP URI here and there.

RFC 6125 specifies that a CN, Common Name, in the Subject field of a certificate should not be used. Instead, Subject Alt Names should be used for verification. The crux is that there’s a lot of old certificates out there. To support these, the RFC states that only if there are NO subject alt names in the certificate the CN can be used for verification. If there are any Subject Alt Name extension fields in the certificate, the CN should be ignored and not used for verification.

In test 17 we test this. The CN has a correct name, but there are a lot of Subject Alt Names – but not one with the server name. This means that even if the host name can be found in the CN, this certificate is invalid for the service.

If you write a new client, like a mobile application, using TLS you want to test this.

Quick links: