Browsers require the server certificate to have been signed by the same certificate authority that signed the client certificate or else the browser will not even submit the certificate.

Generic method using openSSL command line tools#

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/

openssl req -newkey rsa:4096 -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.

openssl x509 -req -trustout -signkey ca.key -days 365 -req -in ca.csr -out ca.pem
echo "02" > ca.srl

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".

keytool -import -alias crushftp_ca -keystore crush.keystore_trust -trustcacerts -file ca.pem -storepass password

---

Server side truststore listed with Portecle

---

Config visuals, the port settings for client cert auth

Server side cert store and trust store in same directory

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.

openssl req -newkey rsa:4096 -nodes -out myuser.req -keyout myuser.key

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.

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"

Using Microsoft AD Certification Services#

First create the trust store, by exporting the CA's public cert, in p12/pfx format, or if the server's security settings don't allow that, export as PEM encoded .cer then create a .pfx file with Portecle, import the cert as trusted. Make sure the password is exactly the same as the main SSL keystore's and the file is named identically with the _trust suffix appended.

Before create the client cert, need to make sure to have a generic client cert template that can be enrolled by the admin. For that, duplicate the default User certificate template, set the permissions for the current admin, etc.

Then issue the client cert based on this template, set the Common Name (CN) field in the Subject as the user login name, exact match.

Finally, export the client cert to p12/pfx format, import it into the web browser's certificate store as Personal certificate

When accessing the server with a web browser , the user is prompted to choose the appropriate client cert, then is logged in automatically (or prompted for the password as the second factor, if the CN was set to NOLOGIN_username )