| At line 1 changed one line |
| Getting a valid certificate is easy with CrushFTP. |
| Getting a valid certificate is easy with CrushFTP. (Old [Portecle] Guide, or [Command Line Guide|SSL_CLI])\\ |
| At line 3 changed 2 lines |
| !!Renewing a Certificate\\ |
| Skip ahead to step 2, and create your CSR from your existing keystore files. Then continue on. |
| *[IIS|IISExport] - If you already have a certificate in IIS, you can export that certificate as a .PFX file and use that certificate directly in CrushFTP. [*Export IIS Certificate*|IISExport]\\ |
| At line 5 added 4 lines |
| ---- |
| !!Renewing a Certificate |
| Skip ahead to step 2, and create your CSR from your existing keystore files. Then continue on.\\ |
| \\ |
| At line 9 changed one line |
| Starting from scratch, go to your Preferences, Encryption, SSL tab. Click 'Generate Now' on the Step 1 section.\\ |
| Starting from scratch, go to your __Preferences->Encryption->SSL__ tab. Click 'Generate Now' on the Step 1 section.\\ |
| At line 12 changed 2 lines |
| Fill in the information about your company.\\ |
| [attachments|generate.png]\\ |
| This will create the java key store for you (the .JKS file). This holds your certificate private key, the critical part you never want to loose or give away. Fill in the information about your company.\\ |
| [{Image src='prefs_ssls1.jpg' width='..' height='..' align='left' style='..' class='..' }] |
| At line 15 changed 2 lines |
| This will create the java key store for you (the .JKS file). This holds your certificate private key, the critical part you never want to loose or give away. |
|
| ;Keystore Algorithm:the SSL key pair algorithm, must be RSA (prefilled) |
| ;Key Size: the private key prime number size in bits. Most CAs require 2048 or above |
| ;Sig Algorithm: the public key signature algorithm. Most CAs require SHA256 or stronger |
| ;Domain Name: the Subject field value of the cert, must match the base domain name the cert is issued to. In case of a single domain cert, must match exactly the domain name. Does not accept wildcard domain name. |
| ;Validity Days: the validity time interval in days of the private key. Must be set a larger value than the max certification days the CA offers, at least 2 years, usually 10. |
| ;SANs: the Subject Alternate Name field value of the cert. Must be set same as the Domain Name (Subject). In case of multi domain ( multi-SAN certs) a comma separated list of domains and/or subdomains. Accepts wildcard domain names, like *.domain.com (wildcard cert). |
| ;Department, Company, City, State and CC: end entity related data,non critical values, the fields however can not be empty. |
| ;Email: end entity's email address, some CAs send a confirmation email to this address, when the cert is issued, or expires, etc. Must be a valid email address. |
| ;Path: a local folder path on the server, where we save the keystore ( .jks) file. |
| ;File name: the keystore (.jks) file name we will use to save the keystore as. |
| ;Password and Confirm password: the keystore protection password. We set same as the private key password. |
| \\ |
| SSL certificates theory, external link (not affiliated) [https://en.wikipedia.org/wiki/X.509#PKIX_Working_Group|https://en.wikipedia.org/wiki/X.509#PKIX_Working_Group] |
| \\ |
| \\ |
| At line 33 changed one line |
| On most Operating Systems Java ships crippled by default due to US export laws. Its extremely annoying, but you must manually copy a couple files into your java install to allow CrushFTP to use strong cryptography keys (almost all keys these days.)\\ |
| The final step is to restart the HTTPS server item, on Preferences->[IP/servers|IP Servers], this step is __mandatory__, in order to actually load the new certificate. Alternatively, can restart the CrushFTP service/daemon itself. |
| ---- |
| !!5.) |
| __OBSOLETE, only for Java 8 and older:__ On most Operating Systems Java ships crippled by default due to US export laws. Its extremely annoying, but you must manually copy a couple files into your java install to allow CrushFTP to use strong cryptography keys (almost all keys these days.)\\ |
| At line 67 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] |
