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
--
Joakim Erdfelt <[email protected] <mailto:[email protected]>>
webtide.com <http://www.webtide.com/>
Developer advice, services and support
from the Jetty & CometD experts
eclipse.org/jetty <http://eclipse.org/jetty/> - cometd.org
<http://cometd.org/>
On Sun, Feb 17, 2013 at 3:47 PM, Ago Allikmaa <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://dev.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/jetty-users
