https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
Mark Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
--- Comment #16 from Mark Thomas ---
Created attachment 33578
--> https://bz.apache.org/bugzilla/attachment.cgi?id=33578=edit
Potential patch if OpenSSL decide this is a WONTFIX
Working around this in Tomcat is quite
https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
--- Comment #15 from Remy Maucherat ---
Ok, that sounds hard. The new OpenSSL code should avoid the problem in most
cases since the certificates are cached in the SSL engine.
--
You are receiving this mail because:
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
--- Comment #14 from Mark Thomas ---
OK. I think I have found the problem.
Tomcat looks for two pieces of information when looking up client certs.
>From AprSSLSupport:
int certLength = SSLSocket.getInfoI(socketRef,
https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
--- Comment #13 from Mark Thomas ---
It appears to be related to session tickets. If you set
disableSessionTickets="true" the problem goes away.
Some quick background reading indicates that the session ticket should include
https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
--- Comment #12 from Christopher Schultz ---
David, you still haven't said whether this is a case of the browser not sending
the certificate or the servlet ignoring it when it's sent. Using Wireshark
should allow
https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
--- Comment #11 from David Balažic ---
Same with tomcat version 8.0.32 which bundles OpenSSL 1.0.2e (see below)
The issue remains (with the change that now IE can not connect at all,
it complains about some TLS
https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
--- Comment #10 from David Balažic ---
With the Apache 8.0.29 released just now it is the same as with 8.0.28
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
--- Comment #9 from David Balažic ---
News update:
with newer software vserions, the behavior changed slightly.
Server side:
- before: Java 1.8.0u51 , apache 8.0.24/26
- now : Java 1.8.0u60 , apache 8.0.28
https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
--- Comment #7 from Rainer Jung ---
Wy is there an expectation, that a client certificate is present when an ssl
session is resumed? Isn't the client cert only needed during the initial
handshake? I wouldn't expect it
https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
--- Comment #8 from Petr Brouzda ---
(In reply to Rainer Jung from comment #7)
Two reasons:
1) It makes client certificate UNUSABLE for authentication if client cert
information are not present on subsequent HTTP
https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
Petr Brouzda changed:
What|Removed |Added
CC|
https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
Petr Brouzda changed:
What|Removed |Added
Status|NEEDINFO|NEW
---
https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
--- Comment #5 from Petr Brouzda ---
Created attachment 33232
--> https://bz.apache.org/bugzilla/attachment.cgi?id=33232=edit
100 % repeatable test case
Better test-case for this bug.
--
You are receiving this mail
https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
--- Comment #4 from Petr Brouzda ---
We have similar (maybe the same) problem.
We run
- Tomcat 8.0.24 with APR.
- HTTPS APR connector with SSLVerifyClient="require".
- on Debian 6
Client is a legacy application with
https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
Christopher Schultz changed:
What|Removed |Added
Status|NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
--- Comment #2 from David Balažic ---
The problem also goes away temporarily if I restart Firefox or just clear the
"Active Logins" in the history deleting dialog. Then after 30 seconds it
happens again.
Maybe
https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
--- Comment #1 from David Balažic david.bala...@comtrade.com ---
Created attachment 33041
-- https://bz.apache.org/bugzilla/attachment.cgi?id=33041action=edit
Test case to reproduce issue
The issue persists with the new
18 matches
Mail list logo