Bug 41883

Summary: use abstract wrapper instead of plain X509Certificate during client authentication
Product: Tomcat 6 Reporter: Ralf Hauser <hauser>
Component: CatalinaAssignee: Tomcat Developers Mailing List <dev>
Severity: enhancement    
Priority: P2    
Version: unspecified   
Target Milestone: default   
Hardware: Other   
OS: other   

Description Ralf Hauser 2007-03-18 13:12:12 UTC
After a client certificate authentication, the certificate is in

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"
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
Comment 1 Ralf Hauser 2007-03-18 13:14:31 UTC
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
Comment 2 Ralf Hauser 2007-03-19 01:30:33 UTC
see also Bug 34643
Comment 3 Christopher Schultz 2013-11-12 18:11:41 UTC
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).