locating the attribute clientAuth as Connector attribute in server.xml
without any means of edit in admin seems problematic
or is this not true?
My 2 cents/Tak
Martin--
This email message and any files transmitted with it contain confidential
information intended only for the person(s) to whom this email message is
addressed. If you have received this email message in error, please notify
the sender immediately by telephone or email and destroy the original
message without making a copy. Thank you.
----- Original Message -----
From: "Subscriber" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <users@tomcat.apache.org>
Sent: Tuesday, May 15, 2007 9:11 AM
Subject: Re: Handling javax.net.ssl.SSLHandshakeException: null cert chain
One additional comment:
The exception is not thrown when the user clicks "Cancel" - it's thrown
when IE accesses the page and presents the "Choose certificate" dialog
box. So the exception is thrown before any user interaction (besides from
typing the URL) :-)
regards,
kews
Subscriber wrote:
Thanks Bill - that was the solution to my problem, but unfortuantely a
new one saw the day :-)
The patch works fine with Mozilla Firefox, but it is like Internet
Explorer closes the SSL socket instantly, which results in this
Stacktrace:
2007-05-15 13:03:10 org.apache.coyote.http11.Http11Processor action
WARNING: Exception getting SSL attributes
java.net.SocketException: Socket Closed
at java.net.PlainSocketImpl.setOption(PlainSocketImpl.java:201)
at java.net.Socket.setSoTimeout(Socket.java:991)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.setSoTimeout(SSLSocketImpl.java:1971)
at
org.apache.tomcat.util.net.jsse.JSSE14Support.synchronousHandshake(JSSE14Support.java:99)
at
org.apache.tomcat.util.net.jsse.JSSE14Support.handShake(JSSE14Support.java:67)
at
org.apache.tomcat.util.net.jsse.JSSESupport.getPeerCertificateChain(JSSESupport.java:121)
at
org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:1127)
at org.apache.coyote.Request.action(Request.java:349)
at
org.apache.catalina.authenticator.SSLAuthenticator.authenticate(SSLAuthenticator.java:138)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:491)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)
at java.lang.Thread.run(Thread.java:595)
Is this Internet Explorer behaviour - and can this be fixed?
regards,
kews
Bill Barker wrote:
"Subscriber" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Hi,
Thanks for your answer Mark! I would like to add custom code to Tomcat
to make this work, but I can't figure out where to start...I can't see
any alternative solution to my problem. Besides that, I'm hard hung up
on Tomcat anyway. I've tried to download the Tomcat source code, but I
can see the exception occurs within the JSSE - this is where the
confusio starts :-)
...solutions are very welcome!
http://issues.apache.org/bugzilla/show_bug.cgi?id=41337
regards,
kews
Mark Thomas wrote:
Subscriber wrote:
Hi,
How do I handle this exception, when the user clicks "Cancel" upon
SSL
Client authentication when prompted for a certificate.
Basically you can't without some custom Tomcat code. Since the
handshake occurs before any HTTP traffic is sent, Tomcat doesn't know
which web app the user was eventually going to try and connect to.
Therefore, this has to be handled entirely within Tomcat rather than
by any particular web app.
This is going to be the same for every container - each will require a
custom solution. If you want your app to be portable, I wouldn't
bother going down this road.
Mark
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__________ NOD32 2264 (20070514) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__________ NOD32 2266 (20070514) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__________ NOD32 2267 (20070515) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
