I've written a topic on enabling SSL and another topic which talks about debugging SSL, but what if you don't want to use the default cacerts or keystore (trustStore) files? Or, what if you have to install a new jvm for DST compliance, but don't want to share certificate stores among Java apps? What if you have a centralized file you want all of your Java apps to use to enable SSL. In these cases you can use the Java system properties to configure these files at runtime.
Several months ago I had a customer trying to implement JCIFS (Java Common Internet File System) servlet filters for NTLM authentication in CFMX. JCIFS allows Java application servers (e.g. JRun) to authenticate browsers against Windows domain controlers using NTLM HTTP authentication. Microsoft Internet Explorer (IE) clients authenticate transparently; non-IE clients that support NTLM authentication (e.g. Mozilla) will prompt for user authentication. Visit the JCIFS NTLM HTTP Authentication page for more information and configuration options. My technote for configuring CFMX to use JCIFS Filters was published earlier this month at http://www.macromedia.com/go/5134e564. If you are running CFMX 6.1 pay attention to the note about changing the DOCTYPE directive in the web.xml.
About a month ago I posted my Enabling SSL entry for instructions on importing SSL certificates into Adobe (formerly Macromedia) server software. Last week a colleague had an issue where the customer swore they imported the correct certificate into CFMX, but <cfldap> was not working over SSL. I pointed my colleague to my blog entry and she was able to debug the JVM stack trace and verify the serial numbers and certificate subjects did not match. Not only that, the customer had several certificates from which to choose and the cert subjects all had varying case syntax.
I also had a military customer who had certificates for multiple servers which needed importing into CFMX in order for the servers to properly integrate with each other on their secured network. I had the customer identify two computers to test with and then use the debugging technique to validate the handshake in the JVM stack trace. It turned out there was a descrepancy in the host names used in the certificate and the web site.
My recommendation for both scenarios is to import the signing certificate authority's (CA) certificate into the JVM trust store. When you import the CA cert ensure you specify the -trustcacerts option so that any certificates signed by this CA are trusted. Your certificates should also use a consistent naming scheme -- i.e. same case syntax (usually lower case), alphanumerics, etc.
This entry really applies to all/any Macromedia software (CFMX, DW, etc.) that leverages a JRE. To enable SSL (or even update existing certificates) you need to use the Java keytool to import the remote server's certificate into the JVM's certificate store. The JVM's default store is jre_root\lib\security\cacerts -- e.g. C:\j2sdk1.4.2_09\jre\lib\security\cacerts or C:\Program Files\Java\jre1.5.0_05\lib\security\cacerts or even cf_root\runtime\jre\lib\security\cacerts.
The keytool is only available with the Java Software Development Kit (SDK). Macromedia has 3 technotes which discusses this information (there's also info in several LiveDoc pages as well):
- ColdFusion MX: Configuring Secure SSL Connection with LDAP Directory Server
- Flex: Using SSL causes java.security.cert.CertificateException
- CPS: Configuring Contribute Publishing Services to use LDAPS
However, I decided to write a coverall for using the keytool to import the certificates and enabling JVM debugging to ensure the certificate handshake.