Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Trusting all client certificates still causes certificates not in trust store to fail (9.0.0.M3)

Even if Jetty does not directly handle this part of the negotiation, it should be able to forward the parameters I give it to the code that does. Hence if there is a "trust all" setting in Jetty, it probably passes this setting on to somewhere else (possibly sets the corresponding flag in the SSLEngine instance that it creates?).

The curious thing here is that M3 version at least works when the client certificate is in the trust store, but with RC0 the browser gets the information that one of the certificates I have should fit, but when it actually sends the certificate, it throws the same error when client has no matching certificates or has sent a non-matching certificate.

And I thought the trust store was for actual client certificates, not the CA certificates the client certificates should be signed with. Or does this work both ways? With M3 it works just fine when the client certificate itself is in trust store. If I can keep CA certificates in there, what I want to do could work in offline mode (without doing OCSP check manually),
but then I'd also have to be able to specify a revocation list.

But with both versions the trust all thing doesn't seem to have any effect.


On 19.02.2013 12:36, Chris Haynes wrote:
I'm no expert in this, but I did explore this area about 5 years ago and try similar experiments.

If my memory serves me right I think you will find that:

1) The level you are working at is the SSL protocol negotiation between the Java SSL/TLS socket and the browser. It is below the level at which Jetty is involved,

2) The sever 'advertises' to the client a list of certificate nodes which it will accept,

3) The client finds a client certificate which 'matches' one of those  nodes offered by the server and sends that certificate to the server,

4) The server checks the client certificate and, only then, if all is well, establishes the SSH session.

By 'matches' I mean this:

All certificates have a chain of authorities which have authenticated that certificate.

The Java server has a list of trusted root certificates.

To be accepted, a client certificate has to have been authenticated by one of the authorities listed in the Java security set-up, and that authority must have been specifically named in the SSL hand-shake.

It is possible to use your own private set of client certificates by:

1) Creating your own 'root' certificate,

2) Putting that root certificate into the Java security system's list of trusted roots,

3) Identifying that root in the SSL set-up (using the API provided by j

4) Having that root certificate sign a batch of client certificates,

5) Giving each browser client one of this family of certificates.

To the best of my knowledge it is not possible to just use any 'random' client certificate and have it passed through to your Applet under Jetty for you to do your own authentication.


Chris Haynes

On Monday, February 18, 2013 at 4:25:23 PM, Ago Allikmaa wrote:
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.
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 <joakim@xxxxxxxxxxx <mailto:joakim@xxxxxxxxxxx>> <>
Developer advice, services and support
from the Jetty & CometD experts <> -

On Sun, Feb 17, 2013 at 3:47 PM, Ago Allikmaa <maxorator@xxxxxxxxx
<mailto:maxorator@xxxxxxxxx>> wrote:
     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();
     (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
     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 (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 ( ),
     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,
     jetty-users mailing list
     jetty-users@xxxxxxxxxxx <mailto:jetty-users@xxxxxxxxxxx>

jetty-users mailing list
jetty-users mailing list

Back to the top