|
With 9.0.0.RC0, the certificate list
popups were the same (Firefox and Chrome listed the ones in trust
store, Opera listed all), but once I select a trusted certificate,
I get the same error I got with M3 when there were no compatible
certificates in my local certificate list or I chose one in Opera
that wasn't in the trust store (Firefox: "The connection was
interrupted", Chrome: "Error 107 (net::ERR_SSL_PROTOCOL_ERROR)",
Opera: "Could not connect to remote server"). So now even the
certificates in trust store don't work. I double-checked this,
switched between RC0 and M3 several times with no other changes.
"setTrustAll(true)" had no effect at all, the results were exactly
the same as without it.
Ago
On 18.02.2013 3:57, Joakim Erdfelt wrote:
Update to 9.0.0.RC0 and try again.
There have been many updates to that area of the code since
9.0.0.M3
--
Developer advice, services and support
from the Jetty & CometD experts
On Sun, Feb 17, 2013 at 3:47 PM, Ago
Allikmaa <maxorator@xxxxxxxxx>
wrote:
Hello,
I am trying to implement a simple SSL server which
requires a client certificate, but all certificates are
"trusted", as I plan to implement the validity check
separately later. My problem is that it doesn't seem to be
possible to bypass the trust store, not even by setting
"trustAll" to true. I am using Jetty version 9.0.0.M3.
I have two test certificates. One of them is in the trust
store, the other one isn't. I added both certificates to
Firefox (18.02), Opera (12.12) and Chrome (25.0.1364.84).
Firefox and Chrome only show the trusted certificate in
the popup where it asks me to choose the certificate (how
does the browser even know which ones server "trusts",
does it send all of its certificates to the server and
asks if they're trusted?), Opera actually lists both, but
using the one that is not in the server's trusted lists
results with "Could not connect to remote server".
Not having any certificates in browser's certificate list
also produces odd results - instead of some kind of
informative error Firefox informs me that the "connection
was reset", Chrome says "Error 107
(net::ERR_SSL_PROTOCOL_ERROR)" and Opera says "Could not
connect to remote server". On most websites I have
encountered, the error is a bit more informative (such as
ssl_error_handshake_failure_alert). Is this intentional or
just too insignificant to fix?
Here is the code for the SSL context (I'm using embedded
mode):
SslContextFactory contextFactory = new
SslContextFactory();
contextFactory.setTrustAll(true);
contextFactory.setKeyStorePath("./jettystore.jks");
contextFactory.setKeyStorePassword("testpass");
contextFactory.setTrustStorePath("./truststore.jks");
contextFactory.setTrustStorePassword("testpass");
contextFactory.setNeedClientAuth(true);
(The application is really simple at the moment, without
imports it's barely 40 lines.)
Also, while I'm already asking, are there any examples out
there for accessing certificate information (will specify
later) using HttpServletRequest and HttpServletResponse
objects passed to a servlet? I'd like to do the actual
verification in a servlet, so I could invent my own output
in both failed and succeeded certificate check. The actual
verification is basically an OCSP query, but I figured
since I have an example for the exact verification I need
to do in the form of a call to openssl, I might invoke
that until I find a way to do it more elegantly. The
information I need to access are the equivalents of
Apache's SSL_CLIENT_CERT and SSL_CLIENT_I_DN_CN. The OCSP
server certificate file and CA certificate file for the
OCSP query depend the value of SSL_CLIENT_I_DN_CN.
The verification itself verifies a smart card certificate.
One reference implementation of it using PHP and openssl
can be found at http://id.ee/index.php?id=30338
(not in English, the link named "Näidisrakenduses" near
the end of the article points to the .zip file). There's
also a description for verifying them offline by using
revocation lists ( http://www.id.ee/index.php?id=35753
), but I'd prefer a real-time check. If some good person
really wants to help or cannot bear the thought of
invoking a separate application for verifying the
certificate (portability! IT'S GONE!), maybe you can
suggest a good way to implement the same thing
properly/elegantly in Java.
Thanks for taking the time to read this,
Ago
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-users
|
