"Are you confident OpenSSL ..." >From what you have presented so far I'd say the answer is "yes". Regardless of which library you are using, the TLS/SSL handshake protocol is completed before Tomcat code has been called into so it is either an OpenSSL or a JSSE lib issue and not, at least technically, a Tomcat issue. That OpenSSL differs from either JSSE implementation isn't surprising as OpenSSL isn't Java code at all, it is C code accessed as a native library. Sorry but I don't know if there is a way to coax OpenSSL into ignoring client certificate validity dates. You may want to pose this question to an OpenSSL forum. My guess is that even if there is a way to configure OpenSSL to ignore the client dates it will probably be accessible only through an API call and that won't be available in the JNI code that calls OpenSSL, in other words accessible from Tomcat. If this is something you really need and if there an API method to ignore client dates in OpenSSL then adding the call-through from Tomcat to OpenSSL isn't terribly difficult but you'd need to change Tomcat and Apache Portable Runtime code, recompile and deploy. Probably not an option if you are on a commercial host.
On Thu, Apr 28, 2011 at 3:04 PM, Thomas Hill <thomas.k.h...@t-online.de>wrote: > The Tomcat hoster tells me OpenSSL is used on the server side (in a reply > email from support - I will double-check in a phone call during business > hours as this was not my current understanding). > Are you confident OpenSSL is refusing the connection to be established when > a client certficate that has expired is presented? (so behave the same as > IBM's JSSE implementation and then different from Sun's) > > Am 27.04.2011 18:39, schrieb Chris Beckey: > >> Are you using JSSE or OpenSSL for your SSL implementation? >> >> On Tue, Apr 26, 2011 at 4:40 PM, Thomas Hill<thomas.k.h...@t-online.de >> >wrote: >> >> Hi Felix, >>> >>> thanks for your reply. So does this mean no way on Tomcat 5.5? (as I >>> won't >>> switch to a newer version, especially 7.x any time soon) >>> >>> To your question: >>> Primary reason is I want my fat client java application and my java web >>> application to react the same way when a user supplies an expired >>> certificate. >>> (btw: interesting that Derby and Tomcat both being Apache products behave >>> differently here to start with). >>> I would still check the expiration date as part of the application logic >>> in >>> both scenarios and for expired client certs allow read-only access to the >>> data base only >>> (so misuse the expiry date on the certificate to trigger read-only >>> restrictions). >>> >>> Tx& Rgds >>> >>> Am 26.04.2011 21:52, schrieb Felix Schumacher: >>> >>> On Tue, 26 Apr 2011 20:44:38 +0200, Thomas Hill wrote: >>> >>>> Hi, >>>>> I am using clientAuth on Tomcat 5.5.30, JVM version 1.6.0_21-b06 from >>>>> Sun on Linux. The client certificates are self-generated and signed as >>>>> I am acting as CA for the client certificates. Authentication is >>>>> working as expected until the certificate expiry date is reached which >>>>> is when I am getting "ssl_error_certificate_unknown_alert" errors >>>>> returned and the connection is refused. I would like Tomcat to be more >>>>> tolerant and continue accepting the certificate even after its >>>>> expiration. Is there a way to change the configuration such that this >>>>> can be achieved? >>>>> Note: Sun's JSSE implementation by default (in contrast to IBM's) >>>>> accepts expired self-signed certificates - I also found this to be the >>>>> case when my Java application is communicating direct with an Apache >>>>> Derby Data Base Server running SSL. I would like the same tolerance >>>>> and behaviour be evidenced when connecting via Tomcat in a web/browser >>>>> based application environment. >>>>> >>>>> I haven't tried it, but it looks like the attribute >>>> 'trustManagerClassName' should >>>> help you with tomcat 7.11 and newer. >>>> >>>> I do wonder, why you want expired certificates to be still valid, if you >>>> are the ca >>>> anyway and could certainly sign new for free. >>>> >>>> Bye >>>> Felix >>>> >>>> Thanks >>>>> Thomas >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>> >>>> >>>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
