This article is about an issue that raised its head whilst installing a 2048bit key certificate into our ColdFusion servers.
I have already written an article about getting the certificates installed into the Java Engine lying under ColdFusion.
Now we were having issues with a certificate and an connection to a partner site. The connection used to work until they upgraded their certificate to a 2048bit key length certificate.
We had successfully added the certificate to the java keystore, which we have done numerous times in the past, but with this certificate, whilst it was in the keystore we still could not connect.
In the end what we found was that the certificate was a multi domain certificate, this means that the certificate is valid for a number of different domains. In certificates this is supported by the use of an extension field called
Subject Alternative Name (SAN)
Now according to the RFCs, the way the domain should be checked is that the application should check the SAN field and then check the Subject field (specifically the Common Name (CN) entry. The CN entry will house just one domain.
So what we found was that when we connected to the server that was running on the domain listed in the CN, the connection would be ok. Now if we tried to connect to one of the domains listed in the SAN field (other than the domain in the CN) the connection would fail.
We have then traced this problem to an issue with ColdFusion prior to version 9. It appears that CF7, CF8 do not check the SAN field and only the CN entry. This means you can use multi domain certificates in CF7, CF8.
To use/trust multi-domain certificates in ColdFusion you have to use CF9+.
The images below are to help visualise the above fields in the certifcates.
Image 1 is from an article on digicert that explains Subject Alternative Names ( I include here to show where you can see the SAN field, in addition the 2nd image is showing the CN entry in the Subject field (green outlined rectangle), from the University of California Davis )