6

While doing some research with SSL certificates, I found some weird certificates containing nul bytes in their Subject field. One example is www.refah - bank.ir (did the Iranian government fake this CA? It looks very similar to a Spanish CA except for location...).

Another example is mcafee.com which looks more trustworthy to me. They have two different IP addresses for mcafee.com and www.mcafee.com, the certificate also differs. What surprised me was that such a company uses certificates containing nul bytes in their Subject field:

Data:
    Version: 3 (0x2)
    Serial Number:
        c8:e6:3c:67:a8:7f:38:ba:c9:ab:06:ef:4e:68:67:0d
Signature Algorithm: sha1WithRSAEncryption
    Issuer: O=Network Associates, OU=NAI Certificate Services, CN=NAI SSL CA v1
    Validity
        Not Before: Aug 26 20:36:38 2008 GMT
        Not After : Apr 26 09:28:50 2019 GMT
    Subject: C=US, ST=Texas, L=Plano, O=McAfee, Inc, OU=IIS-Plano, CN=\x00*\x00.\x00m\x00c\x00a\x00f\x00e\x00e\x00.\x00c\x00o\x00m

Opening mcafee.com correctly rejected the certificate as the wildcard does not match against this. Out of curiosity, I edited my host file and made foo.mcafee.com (and www.) point to the IP address 161.69.13.40 (mcafee.com). I would expect such a certificate to be rejected, but Firefox and Chromium both accept this certificate.

I found another website that has nul bytes in the CN and is still "trusted": https://www.digiturk.com.tr

What is happening here?

Improve this question

1 Answer 1

Reset to default
7

This is a badly encoded Common Name. The Common Name, like many elements of a Distinguished Name, can be encoded in several ways, including UTF8String (that's UTF-8) and BMPString. The latter is more or less the same as UTF-16, with two bytes per character (except surrogates, which I won't talk about here). Apparently, someone encoded *.mcafee.com in big-endian UTF-16, but it was decoded as if it was UTF-8 (or ASCII), leading to the spurious null bytes. It was probably improperly tagged in the certificate.

Improve this answer
3
  • 1
    Thank you, I also found your other extensive answer describing the allowed characters in a CN. Point 6 in this mailing list message is probably the cause of having a weird CN here.
    – Lekensteyn
    Mar 1, 2013 at 13:08
  • Using lapo.it/asn1js, I was able to determine that the CN is indeed a BMPString and that openssl is broken here in the sense that it cannot decode it properly. Thanks!
    – Lekensteyn
    Mar 1, 2013 at 13:08
  • Actually, openssl is probably dumping the "raw" bytes. When I use openssl x509 -nameopt sep_comma_plus_space, the value gets decoded to a human-readable string.
    – Lekensteyn
    Mar 1, 2013 at 13:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .