Start a new topic

Using an SSL cert generated with another program

aj08 @ Sun Sep 14 23:16:47 EEST 2014
I have an email server that I will be using to generate a certificate request. When I do, it will generate a .csr file. My understanding is that I then submit it to the ssl company and tell them to generate a .crt file for use with Apache or X.509 base-64. Since the wiki for crushftp mentions generating a .jks file, will I be able to use the .crt generated from my mail program's .crs file or will I have to create a .jks to use SSL with crush? I've looked at the documentation and I don't see where my mail server will generate a .jks file or password for use in step 3 of the wiki.

spinkb @ Mon Sep 15 15:07:05 EEST 2014
I'll document this here for other people as well as its good for people to understand the whole process.

Every single SSL app uses the same sort of structure for SSL. So every SSL server's certs are interchangeable, they just sometimes package them in different ways that have other benefits.

The process:
Before anything, a private key is created that has the "CN" attribute referencing your domain name. CN=common name. There is a bunch of other "fluff" that describes you as the company too, but the single critical element is the CN. From a private key, you can generate the (C)ertificate (S)ighning (R)equest. This describes your private key in such a way that a certificate authority (CA) can vouch that you are who you say you are, and they sign the CSR and sent you the cert (CRT) file (also known as the CA reply file). This CRT is worthless without the private key. It literally points back at that specific key's unique signature, and is 100% worthless without that private key. So that is the entire process.

Now all cert authorities also do a little more in-between...they don't sign your cert with their own super super super secret CA key, they instead sign with an intermediate certificate. The structure is something like this:

CA key (super super super secret)
CA root (signed by their super super super secret)
CA intermediate (signed by their root)
your key (signed by their intermediate)

Everyone in the world trusts the CA key for say 10 years...and they also trust keys that it has signed. Its the "chain" of trust.

Now servers like Apache, and IIS may ask you for your private key, and the signed key. (The CSR is only useful to get the CRT, then its garbage. Don't save it thinking you have something useful...) They likely have a list of most server's intermediate and root certs, and they build a chain internally for you and use your keys.

CrushFTP and other servers use a "keystore" to hold the chain of keys, and these have a way to link the keys together. CrushFTP will accept either a JavaKeyStore (JKS) or a PFX, P12, (PKCS12) formatted keystore. A keystore is like a folder of keys, but with a password on the folder of keys to secure them.

So a keystore needs a private key in it, plus the root cert, plus the intermediate cert, and finally your signed cert.

So going from apache individual files to a keystore is a documented process of a few steps. You basically are importing the files into a PKCS12 keystore. Then CrushFTP can use that kesytore file directly.

A JKS keystore for practical purposes works the same as a PFX file. (Not 100% the same, but for what you care about, it is.)

Here is a link for converting Apache files into a PKCS12 file.


1 person likes this
I converted my OpenSSL certificate and key to a PKCS12 store. The wiki page mentions importing it with Portecle. But you mention "A JKS keystore for practical purposes works the same as a PFX file".

So, can I not simply put the path to my .p12 store into the xml configuration file and restart CrushFTP?

If it actually needs to be a JKS store, isn't there a Java command to convert between pkcs12 and jks?



I would rename the .p12 to be .pfx just to ensure CrushFTP recognizes it, but yes, that is fine as long as that contains the entire cert chain in it.  A JKS or PFX (pkcs12) file are both almost identical in how they work. with the exception being a JKS can contain multiple private keys potentially, and private keys can have a different pass than the keystore.


Login to post a comment