At line 1 changed 3 lines |
Here are the commands I used to do this: |
################################################################## |
openssl req -newkey rsa:512 -nodes -out ca.csr -keyout ca.key |
Here are example commands for generating your own Certificate Authority, and signing your own keys to distribute to end users. This tool may help as its graphical instead of command line: http://xca.sourceforge.net/ |
At line 3 added 17 lines |
{{{ |
openssl req -newkey rsa:512 -nodes -out ca.csr -keyout ca.key |
}}} |
Fill in the questions. Use relevant data, but this information is only for you. |
{{{ |
Country Name (2 letter code) [AU]:US |
State or Province Name (full name) [Some-State]:Texas |
Locality Name (eg, city) []:Dallas |
Organization Name (eg, company) [Internet Widgits Pty Ltd]:CrushFTP |
Organizational Unit Name (eg, section) []:Development |
Common Name (eg, YOUR name) []:www.domain.com |
Email Address []:ben@crushftp.com |
A challenge password []: |
An optional company name []: |
}}} |
Now we get our private key for signing. |
{{{ |
At line 7 changed 8 lines |
keytool -genkey -alias crushftp -keyalg RSA -keysize 512 -keystore crush.keystore -storepass password |
|
keytool -certreq -keyalg RSA -alias crushftp -file crushftp.csr -keystore crush.keystore -storepass password |
openssl x509 -CA ca.pem -CAkey ca.key -CAserial ca.srl -req -in crushftp.csr -out crushftp.crt -days 365 |
keytool -import -alias crushftp_ca -keystore crush.keystore -trustcacerts -file ca.pem -storepass password |
|
keytool -import -alias crushftp -keystore crush.keystore -file crushftp.crt -storepass password |
|
}}} |
And finally, we import the public key for our signing into our trust store so we can validate all signed keys user's submit. This files name "crush.keystore_trust" is specific. It must be in the same folder as the real keystore file for the server port, and must have the exact same name and password, except its name ends with "_trust". So in this case we expect to have a keystore named "crush.keystore". |
{{{ |
At line 16 changed one line |
|
}}} |
---- |
Now from here on, we just generate new signed certs for your clients. The key part is to set their username to be "NOLOGIN_myuser" if you want to force them to still enter a user/pass. Otherwise if you set their common name to a valid username, they will be able to login without a user/pass. |
{{{ |
At line 18 changed one line |
|
}}} |
Fill in the information on this client's key you are building. Note that the Common Name must be the username of the client, or "NOLOGIN_" and anything else. |
{{{ |
Country Name (2 letter code) [AU]:US |
State or Province Name (full name) [Some-State]:Texas |
Locality Name (eg, city) []:Ft. Worth |
Organization Name (eg, company) [Internet Widgits Pty Ltd]:CrushFTP |
Organizational Unit Name (eg, section) []:Development |
Common Name (eg, YOUR name) []:myuser |
Email Address []:ben@crushftp.com |
A challenge password []: |
An optional company name []: |
}}} |
Now we build the "myuser.p12" file that we need. This is what we will distribute to the end user for them to add to their browser to allow them access. |
{{{ |
At line 21 changed 10 lines |
################################################################## |
|
Now from here on, I just generate new signed certs for my clients: (making sure I give them valid common names that match usernames in CrushFTP.) |
|
openssl req -newkey rsa:512 -nodes -out myuser.req -keyout myuser.key |
|
openssl x509 -CA ca.pem -CAkey ca.key -CAserial ca.srl -req -in myuser.req -out myuser.pem -days 365 |
openssl pkcs12 -export -clcerts -in myuser.pem -inkey myuser.key -out myuser.p12 -name "myuser_certificate" |
|
I will probably implement this for FTP too......but there is only one client that current can do it. |
}}} |