If you were directed to this website by a support ticket please send us an email at support+cac@truststack.us so we can assist in enabling CAC Authentication for our customers.
If you just need to know what to put in the ticket please click here
Note: “CAC Authentication” is known as “Client Certificate Authentication”, "Mutual TLS Authentication" or "mTLS" outside of the DoD.
This is almost always a network issue, and this issue will happen for each network independently of any other network that is used. If you fix it on one network that will not fix it on another network.
On-site using a hardwired connection is a separate network from VPN.
If your VPN lets you choose separate servers, each one is a separate network.
If CAC Authentication is fixed for an on-site network and users on-site can now use CAC Authentication, this has no impact on a VPN, they will still have issues connecting.
If CAC Authentication is fixed for “VPN Server West” and users on “VPN Server West” can now use CAC Authentication it will have no impact on “VPN Server East”.
In terms of the OSI Model CAC Authentication happens at layer 6 and needs direct communication from the browser to the server without being modified.
Web Content Filtering is when DISA (or another entity) inserts itself between a network and an external server.
It does this by breaking the encryption that TLS/SSL starts so that it can be inspected (hence the name "Break and Inspect") and then re-encrypts it when connecting to the external server. When the encryption is broken all information about CAC Authentication is lost.
In terms of the OSI Model, this modifies layer 6, as stated above CAC Authentication needs layer 6 to be unmodified.
Many times a proxy is used to facilitate security compliance and reduce bandwidth.
The DoD primarily uses Menlo's cloud proxy you can read about it here https://www.menlosecurity.com/press-releases/disa-awards-by-light-team-198-9m-cloud-based-internet-isolation-production-ota/.
The problem happens because many proxies by default will stand in between the browser and the external server and it only provides a proxy for the http protocol. This is a problem as we need the TLS protocol to be proxied. The above process for CAC Authentication gets reduced to this:
In terms of the OSI Model, this only proxies layer 7, as stated above CAC Authentication needs to communicate on layer 6.
With any proxy there is a rule list that determines how the proxy works with each website, usually this is controlled network-wide. For DoD networks individual military bases usually do not have control over this (for example the 26 NOS (Network Operation Squadron) controls the lists for USAF/USSF bases).
Some consumer Anti-Virus software will act as one or both of the above. No DoD networks use this type of anti-virus software.
If you are on a personal machine on your home or another public network try disabling your anti-virus and attempting to authenticate.
A ticket needs to be submitted to allow CAC Authentication to proceed for keycloak.truststack.us
. This needs to happen for each network.
Users need to be able to use CAC Authentication when connecting to TrustStack services. CAC Authentication fails when connecting to keycloak.truststack.us.
Technician notes from TrustStack:
The only domain utilizing CAC Authentication is keycloak.truststack.us.
TrustStack currently has CAC Authentication working for several customers across the DoD and TrustStack engineers primarily use CAC Authentication to connect.
CAC Authentication can be verified by connecting a computer with a CAC to any public network and using our connectivity check page at https://connectivity.truststack.us
Under the https://keycloak.truststack.us heading you will find the results.
When CAC authentication is working you will see:
Detected Certificate: CN=WELCH.GEOFFREY.SHAWN TIMOTHY.1547909131,OU=CONTRACTOR,OU=PKI,OU=DoD,O=U.S. Government,C=US
Detected Certificate: not detected