I end up asking both a lead developer and a system administrator for the certificates used. The lead developer obliges with .pfx file, which is a pkcs12 file. The system admin pops over a .cer file in the form of a pkcs7 file.
To make a long story short, the pkcs12 is the one that you will want. You can retrieve a pkcs12 (extension of .pfx in Windows land) by following the documentation here at MSDN - there is a section devoted to exporting.
Using openssl, you can view the full contents of the pkcs12 file with the following:
`openssl pkcs12 -in thefile.pfx` #The full contentsIn order to actually use these commands, you'll be challenged for an "Import Passphrase" that was set on whatever tool generated this file. In in our case, this is IIS).
`openssl pkcs12 -in thefile.pfx -nokeys` #Show only the certificates in the chain
`openssl pkcs12 -in thefile.pfx -nocerts` #Show only the private key.
This is fine and all, but this file can't really be placed in to a pre-existing java keystore, or a new one for that matter, by using the keytool utility - the common and suggested way to manipulate java keystores. The keytool utility basically assumes it is going to either 1) have certificates placed in it to know what to trust as an ssl client or 2) be created with a public/private key pair that will be used to generate a csr and accept certificates from that csr that match the key pair. It does not allow you, intrinsically, to import a pre-existing private key or keypair that match already pre-existing certificates so that your application or application server can act as a server for ssl/tls communication with those pre-existing certificates.
The solution - there's a little library called Not Yet Common SSL that let's you do just that. It was being actively developed on until June of this year. I grabbed the 0.3.9 version (0.3.10 didn't work for me... I'll spare the details) and issued the following commands using the pkcs12 file as input.
`java -cp not-yet-commons-ssl-0.3.9.jar org.apache.commons.ssl.KeyStoreBuilder $challenge_password yourfile.pfx`
Successfuly wrote: [www.yourdomain.com.jks]
The result is a keystore file named www.yourdomain.com.jks where www.yourdomain.com is whatever the CN is the bottom-most certificate in your chain. The lone entry in the keystore will be an alias of the same name. You can now use this particular keystore in your application server for ssl and it will present your full chain of certificates to clients.