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]>
webtide.com <http://www.webtide.com/>
Developer advice, services and support
from the Jetty & CometD experts
eclipse.org/jetty - cometd.org


On Sun, Feb 17, 2013 at 3:47 PM, Ago Allikmaa <[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 <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<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]
> https://dev.eclipse.org/**mailman/listinfo/jetty-users<https://dev.eclipse.org/mailman/listinfo/jetty-users>
>
_______________________________________________
jetty-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/jetty-users

Reply via email to