View Attach (4) Info

Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
png
 generate.png 56.9 kB 1 09-Oct-2016 18:14 Ben Spink
png
 generate_button.png 38.0 kB 1 09-Oct-2016 18:14 Ben Spink
png
 import.png 71.1 kB 1 09-Oct-2016 18:14 Ben Spink
png
 sign.png 75.6 kB 1 09-Oct-2016 18:14 Ben Spink

This page (revision-4) was last changed on 09-Oct-2016 18:14 by Ben Spink

This page was created on 09-Oct-2016 18:14 by Ben Spink

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 49 added 30 lines
----
!!More reading to help understand the whole convoluted process of SSL.
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. [Openssl_key_convert]
Version Date Modified Size Author Changes ... Change note
4 09-Oct-2016 18:14 6.256 kB Ben Spink to previous
3 09-Oct-2016 18:14 6.041 kB Ben Spink to previous | to last
2 09-Oct-2016 18:14 3.304 kB Ben Spink to previous | to last
1 09-Oct-2016 18:14 3.239 kB Ben Spink to last
« This page (revision-4) was last changed on 09-Oct-2016 18:14 by Ben Spink
G’day (anonymous guest)

OLD WIKI!!!#

New: CrushFTPv9#

OLD WIKI!!!#


CrushFTP8 | What's New

Referenced by
Certifications and compliancy
FAQ
LeftMenu

JSPWiki