Chris,
many thanks for your explanaitions on OpenSSL. The hoster is now running
Tomcat using Sun's JDK JSSE implementation and everything is working as
I wanted, i.e. client certificates can be used post their expiration date.
I have tested with FireFox and assume other browsers will show the same
results, but will need to double-check this still.
Regards
Thomas
Am 29.04.2011 15:01, schrieb Chris Beckey:
"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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
