Title: How HTTPS with X.509 Client Certificates Works
In normal HTTPS, only the browser checks to make sure that it trusts the server, based on the server's certificate.
When client certificates are required, the server also checks that it trusts the browser. The browser must present a certificate trusted by the server in order to be able to establish a connection.
By default, Java trusts browser certificates with a trust chain to a top-level CA.
However, most business and government organizations prefer to sign their own certificates.
In order to get X.509 client certificates working, you need to:
Tell Traction what CA's to trust
Install certificates signed by trusted CA's in the browsers of all users.
Note: It is possible to run Traction on multiple ports, with one port requiring a certificate (e.g. the port visible through the firewall) and other ports (e.g. inside the firewall) not requiring certificates. This requires modifying the Traction.properties file directly. If you need this configuration, first follow the procedure for configuring HTTPS with X.509 certificates, then contact firstname.lastname@example.org for instructions on adding additional ports with different encryption levels.
Note: Unlike the browser, which can install certificates not signed by any CA, Traction only allows you to import CA certificates, not certificates for individuals.
Note: It is possible to prevent Java from trusting the top-level CA's, so that only certificates signed by explicitly imported CA's are trusted. Contact email@example.com for instructions.
In standard X.509 deployments, any trusted browser is allowed to connect to Traction; the authentication is handled independently. This works very well in conjunction with Active Directory and NTLM; as long as users have a signed, trusted certificate, they are automatically logged in.