You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Thomas Hill <Th...@t-online.de> on 2011/04/26 20:44:38 UTC
Tolerate expired certificates
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.
Thanks
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tolerate expired certificates
Posted by Thomas Hill <Th...@t-online.de>.
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<Th...@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.Hill@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-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tolerate expired certificates
Posted by Chris Beckey <cb...@gmail.com>.
"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 <Th...@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.Hill@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-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tolerate expired certificates
Posted by Thomas Hill <Th...@t-online.de>.
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<Th...@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tolerate expired certificates
Posted by Chris Beckey <cb...@gmail.com>.
Are you using JSSE or OpenSSL for your SSL implementation?
On Tue, Apr 26, 2011 at 4:40 PM, Thomas Hill <Th...@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tolerate expired certificates
Posted by Thomas Hill <Th...@t-online.de>.
Christhoper,
thanks for your continued support. I am glad that, now with my hosted
server using the Sun JSSE implementation, everything is working as I
wanted and I do not have to try using a different trust manager (which I
am afraid would have been a too technical task for me).
Regards
Am 28.04.2011 16:57, schrieb Christopher Schultz:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thomas,
>
> On 4/26/2011 4:40 PM, Thomas Hill wrote:
>> 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)
> There is another way to install your trust manager: we used this
> TrustManager with a foolish service that never renewed their
> certificates and we kept getting similar errors -- although this was for
> server certs and not client certs. I suppose the same technique works
> for both, since a TrustManager has methods to cover both cases.
>
> Try something like this:
>
> TrustManager[] trustAllCerts = new TrustManager[] {
> new X509TrustManager() {
> public X509Certificate[] getAcceptedIssuers() {
> return null;
> }
> public void checkClientTrusted(X509Certificate[] certs,
> String authType) {
> }
> public void checkServerTrusted(X509Certificate[] certs,
> String authType) {
> }
> }
> };
>
> SSLContext sc = SSLContext.getInstance("SSL");
>
> sc.init(null, trustAllCerts, new java.security.SecureRandom());
>
>
> HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
>
>
> That last line is specific to ignoring problems with /server/ certs when
> contacting them through the HttpsURLConnection class. You'll have to
> poke around to find out how to set the SSLContext and/or SocketFactory
> for Tomcat's<Connector>s.
>
> Hope that helps,
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk25gFEACgkQ9CaO5/Lv0PBi2QCfUfpZcMoBsvSvIYYRU9xL6l6q
> kGUAnA1ZZqzTTGxq0SbHxxCewwOEvQfV
> =tFuG
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tolerate expired certificates
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thomas,
On 4/26/2011 4:40 PM, Thomas Hill wrote:
> 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)
There is another way to install your trust manager: we used this
TrustManager with a foolish service that never renewed their
certificates and we kept getting similar errors -- although this was for
server certs and not client certs. I suppose the same technique works
for both, since a TrustManager has methods to cover both cases.
Try something like this:
TrustManager[] trustAllCerts = new TrustManager[] {
new X509TrustManager() {
public X509Certificate[] getAcceptedIssuers() {
return null;
}
public void checkClientTrusted(X509Certificate[] certs,
String authType) {
}
public void checkServerTrusted(X509Certificate[] certs,
String authType) {
}
}
};
SSLContext sc = SSLContext.getInstance("SSL");
sc.init(null, trustAllCerts, new java.security.SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
That last line is specific to ignoring problems with /server/ certs when
contacting them through the HttpsURLConnection class. You'll have to
poke around to find out how to set the SSLContext and/or SocketFactory
for Tomcat's <Connector>s.
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk25gFEACgkQ9CaO5/Lv0PBi2QCfUfpZcMoBsvSvIYYRU9xL6l6q
kGUAnA1ZZqzTTGxq0SbHxxCewwOEvQfV
=tFuG
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tolerate expired certificates
Posted by Thomas Hill <Th...@t-online.de>.
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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tolerate expired certificates
Posted by Felix Schumacher <fe...@internetallee.de>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org