I want to doublecheck if we are on the same page regarding how client certificate authentication should work, so we know what are the requirements for Elytron to support it. This will allow us to improve things before the Elytron code freeze (end of August AFAIK) if needed. Right now, I am covering just Service accounts and authenticating of clients with the certificate. But I believe that for authenticate of users, the requirements will be similar. My view is: - Admin will upload certificate of some client via Keycloak admin console. (I guess many companies want to use their own certificate issued by their trusted CA. IMO later Keycloak should provide the ability to easily generate trusted certificates and act as CA - not sure if it's something Giriraj is looking at. But for now, I assume that trusted certificate is always provided by admin and uploaded to Keycloak admin console) - There is REST endpoint, which allows to authenticate with client certificate. For example "https://localhost:8443/auth/realms/demo/clients/certificate" . Client will be able to start SSL handshake with it's certificate when sending request to this endpoint. Server will then verify the underlying SSLSession from the SSL socket and check that valid client certificate was provided during handshake. It will authenticate client based on that. To cover this usecase, the Wildfly/Elytron should be able to: 1) Support "variable" 2-way SSL . In other words, there is possibility to set flag "setWantClientAuth(true)" in underlying SSLServerSocket. This means that I will be able to access admin console "https://localhost:8443/auth/admin" with my browser without client certificate, but I will be able to provide client certificate on the endpoint "https://localhost:8443/auth/realms/demo/clients/certificate" , which is deployed under same context 2) Dynamically upload it's truststore at runtime or provide SPI to add/remove/update certificates in truststore. This is needed, so that when admin uploads the certificate of client in KC admin console, I want my client to be able to authenticate with the certificate immediatelly without need to restart server and edit any JKS files . 3) Possibility to access underlying SSL Socket and SSL Session from the REST endpoint, so I am able to verify the certificate in REST endpoint (but maybe this one could be handled with our server subsystem if it's not available for normal apps?) WDYT? Am I missing something? Marek