After a client certificate authentication, the certificate is in org.apache.catalina.Globals.CERTIFICATES_ATTR As per the object oriented coding and design principles, I'd expect that a cert would also entail methods to e.g. check the its CRL status, etc. java.security.cert.X509Certificate unfortunately doesn't. In order to enable programmers to use smarter extensions of the certificate object, I suggest 1) Tomcat to use an extension of the X509Certificate object that has a constructor with the X509Certificate as an argument 2) add an attribute in the server.xml's Connector element such that another implementation can be specified - e.g. "X509CertClass" (http://tomcat.apache.org/tomcat-5.5-doc/config/http.html#SSL%20Support) This allows to use such a smarter certificate implementation in org.apache.catalina.authenticator.SSLAuthenticator as well as later on in the business logic, e.g. accessed via the httpServletRequest of an MVC framework such as struts, by simply putting that implementation into CATALINA_HOME/common/[lib/classes]
The abstract class all extended X509Certificate implementations would have to extend could be as simple as public abstract class X509CertificateExtensible extends X509Certificate { private static final long serialVersionUID = 1L; protected X509Certificate javaCert = null; static Log log = LogFactory.getLog(X509CertificateExtensible.class); public X509CertificateExtensible(X509Certificate javaCert) { this.javaCert = javaCert; } I am happy to provide a baseline wrapper that basically just maintains backward compatibility.
see also Bug 34643
So... it's only been 6.5 years since this enhancement request was filed, but I found it looking for something related. I think it's unlikely that this will be fixed, because the servlet spec says that the object found under "javax.servlet.request.X509Certificate" should be an array of java.security.cert.X509Certificate objects. While the spec (and API) doesn't bar any container from providing /subclasses/ of that class, any code expecting to use such a subclass would no longer be container-neutral. The kind of thing requested in this enhancement is best implemented in the webapp and not in the container. I'm marking this request as INVALID due to the semantic violation of the servlet spec. Re-open if there is disagreement. (Note that the container can already check the CRL status of the client certificate for you and so the webapp does not have to ... unless you have a nuanced setup where the container is not the appropriate place for those checks).