Invalid/Malformed SSL Certificates on OSX
OSX users, welcome back.
Recently, I enabled SSL by default for this site. If you try and browse to a non-HTTPS version of this site, you’ll be instantly redirected to the HTTPS version without loading any content. There’s no real security reason behind this, it’s just another thing I wanted to play around with and worry not, i’ll be doing another how-to blog entry soon.
A few weeks after I enabled it though, a friend mentioned that they couldn’t connect. Indeed, while attempting to browse using Chrome they received an alarming message stating that Chrome couldn’t connect to the real blog.kingj.net. Normally, this sort of error would be reserved for a man-in-the-middle attempt where someone presented an invalid certificate and pretended to be this site. This was most definitely not the case, but the “technical details” didn’t help much either – claiming that the certificate was invalid and malformed. However, when using Chrome, and other browsers, on my system and mobile devices, I received no such error. Online SSL validators also didn’t find any errors. The only difference was that my friend was using OSX.
Another OSX-using friend identified the issue however – I was using a 8192-bit key on my certificate, and since 2006 OSX has not supported key lengths greater than 4096 bits. The reasoning behind this is that it stops cryptographic Denial of Service attacks, but even so, modern systems have no problem handling 8192-bit keys.
It is possible to change the maximum key size that OSX will accept, however this process needs to be performed on every OSX client that’s connecting, not really a ‘fix’ for a website operator. Indeed, the only real fix that would allow OSX users to seamlessly connect to this site would be to downgrade the key size. From a security perspective, this isn’t too much of an issue. 2048-bit keys are currently considered appropriately strong and 4096-bit keys are only used in paranoid or high-security situations. Thus, I decided to get a new certificate using a 4096-bit key and OSX users can now connect again without issue.
My thanks go to Harvey for first alerting me to this issue and supplying the screenshot above, and to InnerLambada for letting me know the cause.