Hi all, Client cert authentication is central to how the CS manages access to its servlets. How we use and have used client auth is tricky though - and has implications for the new and current interfaces. In this email, I hope to lay out the current state of client-auth - what works, what doesn't, and some thoughts as to how this affects the currently proposed interface. More thoughts on how to solve some of the problems would be really helpful. We use client auth in the following ways: I. There are servlets which never require client auth (ee pages mostly) and some admin (mostly installation related) pages II. There are servlets which always require client auth (agent pages) III. There are servlets which may require client auth (admin pages from the console) which can be configured to require client auth. IV. Enrollment profiles (executed from the EE pages - which do not require client auth) - which, when executed - require client auth to be processed. Another example of this would be self-renewals. This is a case where we start off in a non-clientauth context and switch to client auth. Here is a brief history of how we have implemented client auth to satisfy the above cases: 1. Shared Port Configuration: In the past, we did not have ports that were specified as client-auth/ non-client auth. Instead, if a servlet required client auth, we would ask tomcat for the javax.x509.certificate attribute and - through tomcatjss and jss - it would renegotiate the connection and get the relevant certificate. This handled cases I-IV. 2. Separated Ports: Recently we changed the configuration to a port separated configuration. EE, admin and agent operations occurred on separate ports, which were configured to either require (agent) or not require (ee.,admin) client auth. For case III, if client auth were required, we configured the admin port to "want" - which would essentially ask for a cert and continue if one was not provided. For case IV, we continued to rely on tomcat-initiated renegotiation. 3. Separated ports with MITM fix: For older clients without the newer renegotiation protocol that fixes MITM, renegotiation is disabled. This means that case IV would fail for certain profiles and renewals. The fix for this was to redirect the profile submission to a new client auth required EE port. 4. CA behind an apache proxy. In this case, the outside world talks to the CS through an httpd instance that talks to the CS though the ajp port. This is the current configuration used in IPA. * The decision as to whether a port is client auth/ non-client auth is made in the proxy by mapping URLs. URLs that begin with /agent for example require client auth. This handles cases I and II. * III is more complicated but can be addressed in the same way. That is we can tweak the URL matching rules to always permit the admin servlets that always do not need client auth (like installation servlets), while requiring client auth for other admin servlets. * Case IV is currently broken. Tomcat still passes on the request for the javax.x509.certificate attribute - but ajp does not understand this request and drops it on the floor - resulting in a 5XX type error being returned. As of now, I have been unable to find a way to configure ajp to pass the request on to apache to have it renegotiate the connection. 5. The new proposed RESTful interface: For Dogtag 9+, we have been envisioning that the CS instances would use default ports and that they would still communicate with the outside world through the http proxy. At this point though, the new RESTful interface does not have any indication as to whether the operation is agent/ee/admin -- no indication of this in the URL -- so it is impossible to filter at the httpd proxy based on URL. Moreover, case IV is still broken. There is also an additional consideration - which for reference, I cam going to call case V. Some operations which currently have different output depending on whether they are executed as an agent or an ee user - are mapped to the same servlet in the new proposed api. An example is : /pki/profiles -which would return a list of profiles This is a different list depending on whether it is executed as an agent or whether it is executed as an EE user. Possible Solutions (so far): 1. Whether we use client auth is closely tied to our conception of who is executing the command. We have defined roles : ee, agent, admin in the CS. Perhaps we should add these to the proposed URI pattern? So we might have /pki/agent/certificates and /pki/ee/certifcates etc. This would allow URL filtering on the proxy along the same lines as now - solving cases I,II,III and V. Case IV is still broken. 2. Another solution might be to - once we have determined that a client cert is required (and has not been provided) - send a temporary redirect to say /pki/getClientCert - with a 307 (temporary redirect) code. This servlet could be configured in the proxy to require client auth. This would presumably be the equivalent of renegotiating the connection - except using apache rather than tomcat to do it. And it would solve all five cases listed above. 3, If we can figure out how to get ajp to pass back a request to renegotiate the connection, then this might be the best solution yet. Then we do not need to change any CS code - when we determine that we need a client cert - it will be passed back to the proxy - and the proxy will get the cert. Ade