[jetty-users] Trusting all client certificates still causes certificates not in trust store to fail (9.0.0.M3)

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[jetty-users] Trusting all client certificates still causes certificates not in trust store to fail (9.0.0.M3)

Ago Allikmaa
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
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-users] Trusting all client certificates still causes certificates not in trust store to fail (9.0.0.M3)

Joakim Erdfelt-9
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 <[hidden email]>
Developer advice, services and support
from the Jetty & CometD experts


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


_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-users] Trusting all client certificates still causes certificates not in trust store to fail (9.0.0.M3)

Ago Allikmaa
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 <[hidden email]>
Developer advice, services and support
from the Jetty & CometD experts


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



_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-users] Trusting all client certificates still causes certificates not in trust store to fail (9.0.0.M3)

Chris Haynes
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
Jetty),

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.

HTH

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.

> 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 <[hidden email] <mailto:[hidden email]>>
>> 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 <[hidden email]
>> <mailto:[hidden email]>> 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
>>     [hidden email] <mailto:[hidden email]>
>>     https://dev.eclipse.org/mailman/listinfo/jetty-users




>> _______________________________________________
>> jetty-users mailing list
>> [hidden email]
>> https://dev.eclipse.org/mailman/listinfo/jetty-users

_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-users] Trusting all client certificates still causes certificates not in trust store to fail (9.0.0.M3)

Ago Allikmaa
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.

Ago

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
> Jetty),
>
> 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.
>
> HTH
>
> 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.
>> 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 <[hidden email] <mailto:[hidden email]>>
>>> 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 <[hidden email]
>>> <mailto:[hidden email]>> 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
>>>      [hidden email] <mailto:[hidden email]>
>>>      https://dev.eclipse.org/mailman/listinfo/jetty-users
>
>
>
>>> _______________________________________________
>>> jetty-users mailing list
>>> [hidden email]
>>> https://dev.eclipse.org/mailman/listinfo/jetty-users
> _______________________________________________
> jetty-users mailing list
> [hidden email]
> https://dev.eclipse.org/mailman/listinfo/jetty-users

_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-users] Trusting all client certificates still causes certificates not in trust store to fail (9.0.0.M3)

Marvin Addison
In reply to this post by Ago Allikmaa
> 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?)

The server sends all CA names listed in the _server_ truststore in the
"CertificateRequest" message sent to the client. The user agent
(browser) will only allow you to choose from certificates it knows
about that are issued by the list of CAs mentioned by the server. The
diagram in the "SSL Protocol" section of the JSSE documentation may be
a helpful reference:

http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html

> 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?

Assuming Jetty implements the relevant part of the servlet specification:

If there is an SSL certificate associated with the request, it must be
exposed by
the servlet container to the servlet programmer as an array of objects of type
java.security.cert.X509Certificate and accessible via a ServletRequest
attribute of javax.servlet.request.X509Certificate.

> 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

I would recommend caution here. OCSP deals exclusively with
revocation. While the certificate may not be revoked, it may not meet
PKIX validation requirements. User agent behavior with regard to CA
matching in the CertificateRequest part of the SSL handshake is made
in some cases by string comparison. Without a proper PKIX check, you
could be trusting by naming alone, which would totally subvert the
signature-based checks at the heart of PKI.

M
_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-users] Trusting all client certificates still causes certificates not in trust store to fail (9.0.0.M3)

Ago Allikmaa
Thanks for the info.

Basically I have the CA certificates. I was under the impression that if
I do OCSP, it also checks if the certificate is signed, but if that's
not the case,
I guess I could let the SSL layer handle that at least. The perfect way
for me would be that the client certificate is checked against the CA
certificates,
but even if it's detected to be invalid, my servlet will run, but I
could simply find out whether the check was a success or not. I find
these automatic
errors that actually just confuse the end-user really annoying, I'd like
to respond to failure in a way I choose, especially because the errors that
Jetty servers throw are quite ambiguous, resulting in Opera and Firefox
to say "Unable to connect" and "Connection was interrupted" respectively,
only Chrome manages to deduce it has something to do with SSL at all.
Most sites I've encountered throw an error that the browser interprets as
an "SSL handshake failure".

Now, I added the CA certificates to the trust store. With M3, it works
nicely, but with RC0 I get the usual errors after selecting the certificate
and entering the PIN (it's a certificate from a smart card). Is this a
possible regression?

Even with M3 and CA certificates, I'm not sure how to do OCSP properly.
SslContextFactory has methods setEnableOCSP and setOcspResponderURL,
but the reference implementation provided by the OCSP/smart card
operator also uses a OCSP responder certificate (there's a corresponding
one for
each of the CA certificates) that is passed to openssl via the "-VAfile"
file argument. How would I use these in Jetty?

Ago

On 19.02.2013 17:17, Marvin Addison wrote:

>> 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?)
> The server sends all CA names listed in the _server_ truststore in the
> "CertificateRequest" message sent to the client. The user agent
> (browser) will only allow you to choose from certificates it knows
> about that are issued by the list of CAs mentioned by the server. The
> diagram in the "SSL Protocol" section of the JSSE documentation may be
> a helpful reference:
>
> http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html
>
>> 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?
> Assuming Jetty implements the relevant part of the servlet specification:
>
> If there is an SSL certificate associated with the request, it must be
> exposed by
> the servlet container to the servlet programmer as an array of objects of type
> java.security.cert.X509Certificate and accessible via a ServletRequest
> attribute of javax.servlet.request.X509Certificate.
>
>> 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
> I would recommend caution here. OCSP deals exclusively with
> revocation. While the certificate may not be revoked, it may not meet
> PKIX validation requirements. User agent behavior with regard to CA
> matching in the CertificateRequest part of the SSL handshake is made
> in some cases by string comparison. Without a proper PKIX check, you
> could be trusting by naming alone, which would totally subvert the
> signature-based checks at the heart of PKI.
>
> M
> _______________________________________________
> jetty-users mailing list
> [hidden email]
> https://dev.eclipse.org/mailman/listinfo/jetty-users

_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-users] Trusting all client certificates still causes certificates not in trust store to fail (9.0.0.M3)

Ago Allikmaa
A little update. Enabling the OCSP with SslContextFactory didn't seem to
break anything. Any way to verify that it is actually doing a successful
OCSP check?

I couldn't get client certificates to work with M5, RC0, but it worked
in M3. The commit that breaks my code is at:
http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/commit/jetty-util/src/main/java/org/eclipse/jetty/util/ssl/SslContextFactory.java?id=9ebea3938d473cc897fc71db5e1f266ed17adbff

Why would hostname verification cause my client certificate verification
to fail? And what is the point of it anyway - I'm writing a server, the
client
certificate isn't supposed to contain a hostname that resolves to his IP
address.

Currently I simply wrote a wrapper that "rolls back" this commit. Any
suggestions about whether it is a bug or after that commit I just have
to use it differently?

Also I googled a bit about not dropping the connection when the client
certificate is invalid - found that using a custom TrustManager should
do the trick,
but I have no idea how I could make Jetty use it. Any ideas?

Ago

On 19.02.2013 17:58, Ago Allikmaa wrote:

> Thanks for the info.
>
> Basically I have the CA certificates. I was under the impression that
> if I do OCSP, it also checks if the certificate is signed, but if
> that's not the case,
> I guess I could let the SSL layer handle that at least. The perfect
> way for me would be that the client certificate is checked against the
> CA certificates,
> but even if it's detected to be invalid, my servlet will run, but I
> could simply find out whether the check was a success or not. I find
> these automatic
> errors that actually just confuse the end-user really annoying, I'd
> like to respond to failure in a way I choose, especially because the
> errors that
> Jetty servers throw are quite ambiguous, resulting in Opera and
> Firefox to say "Unable to connect" and "Connection was interrupted"
> respectively,
> only Chrome manages to deduce it has something to do with SSL at all.
> Most sites I've encountered throw an error that the browser interprets as
> an "SSL handshake failure".
>
> Now, I added the CA certificates to the trust store. With M3, it works
> nicely, but with RC0 I get the usual errors after selecting the
> certificate
> and entering the PIN (it's a certificate from a smart card). Is this a
> possible regression?
>
> Even with M3 and CA certificates, I'm not sure how to do OCSP
> properly. SslContextFactory has methods setEnableOCSP and
> setOcspResponderURL,
> but the reference implementation provided by the OCSP/smart card
> operator also uses a OCSP responder certificate (there's a
> corresponding one for
> each of the CA certificates) that is passed to openssl via the
> "-VAfile" file argument. How would I use these in Jetty?
>
> Ago
>
> On 19.02.2013 17:17, Marvin Addison wrote:
>>> 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?)
>> The server sends all CA names listed in the _server_ truststore in the
>> "CertificateRequest" message sent to the client. The user agent
>> (browser) will only allow you to choose from certificates it knows
>> about that are issued by the list of CAs mentioned by the server. The
>> diagram in the "SSL Protocol" section of the JSSE documentation may be
>> a helpful reference:
>>
>> http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html 
>>
>>
>>> 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?
>> Assuming Jetty implements the relevant part of the servlet
>> specification:
>>
>> If there is an SSL certificate associated with the request, it must be
>> exposed by
>> the servlet container to the servlet programmer as an array of
>> objects of type
>> java.security.cert.X509Certificate and accessible via a ServletRequest
>> attribute of javax.servlet.request.X509Certificate.
>>
>>> 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
>> I would recommend caution here. OCSP deals exclusively with
>> revocation. While the certificate may not be revoked, it may not meet
>> PKIX validation requirements. User agent behavior with regard to CA
>> matching in the CertificateRequest part of the SSL handshake is made
>> in some cases by string comparison. Without a proper PKIX check, you
>> could be trusting by naming alone, which would totally subvert the
>> signature-based checks at the heart of PKI.
>>
>> M
>> _______________________________________________
>> jetty-users mailing list
>> [hidden email]
>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>

_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-users] Trusting all client certificates still causes certificates not in trust store to fail (9.0.0.M3)

Joakim Erdfelt-9
Does this commit (post RC0) help you?


--
Joakim Erdfelt <[hidden email]>
Developer advice, services and support
from the Jetty & CometD experts


On Tue, Feb 19, 2013 at 3:08 PM, Ago Allikmaa <[hidden email]> wrote:
A little update. Enabling the OCSP with SslContextFactory didn't seem to break anything. Any way to verify that it is actually doing a successful OCSP check?

I couldn't get client certificates to work with M5, RC0, but it worked in M3. The commit that breaks my code is at:
http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/commit/jetty-util/src/main/java/org/eclipse/jetty/util/ssl/SslContextFactory.java?id=9ebea3938d473cc897fc71db5e1f266ed17adbff

Why would hostname verification cause my client certificate verification to fail? And what is the point of it anyway - I'm writing a server, the client
certificate isn't supposed to contain a hostname that resolves to his IP address.

Currently I simply wrote a wrapper that "rolls back" this commit. Any suggestions about whether it is a bug or after that commit I just have to use it differently?

Also I googled a bit about not dropping the connection when the client certificate is invalid - found that using a custom TrustManager should do the trick,
but I have no idea how I could make Jetty use it. Any ideas?

Ago


On 19.02.2013 17:58, Ago Allikmaa wrote:
Thanks for the info.

Basically I have the CA certificates. I was under the impression that if I do OCSP, it also checks if the certificate is signed, but if that's not the case,
I guess I could let the SSL layer handle that at least. The perfect way for me would be that the client certificate is checked against the CA certificates,
but even if it's detected to be invalid, my servlet will run, but I could simply find out whether the check was a success or not. I find these automatic
errors that actually just confuse the end-user really annoying, I'd like to respond to failure in a way I choose, especially because the errors that
Jetty servers throw are quite ambiguous, resulting in Opera and Firefox to say "Unable to connect" and "Connection was interrupted" respectively,
only Chrome manages to deduce it has something to do with SSL at all. Most sites I've encountered throw an error that the browser interprets as
an "SSL handshake failure".

Now, I added the CA certificates to the trust store. With M3, it works nicely, but with RC0 I get the usual errors after selecting the certificate
and entering the PIN (it's a certificate from a smart card). Is this a possible regression?

Even with M3 and CA certificates, I'm not sure how to do OCSP properly. SslContextFactory has methods setEnableOCSP and setOcspResponderURL,
but the reference implementation provided by the OCSP/smart card operator also uses a OCSP responder certificate (there's a corresponding one for
each of the CA certificates) that is passed to openssl via the "-VAfile" file argument. How would I use these in Jetty?

Ago

On 19.02.2013 17:17, Marvin Addison wrote:
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?)
The server sends all CA names listed in the _server_ truststore in the
"CertificateRequest" message sent to the client. The user agent
(browser) will only allow you to choose from certificates it knows
about that are issued by the list of CAs mentioned by the server. The
diagram in the "SSL Protocol" section of the JSSE documentation may be
a helpful reference:

http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html

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?
Assuming Jetty implements the relevant part of the servlet specification:

If there is an SSL certificate associated with the request, it must be
exposed by
the servlet container to the servlet programmer as an array of objects of type
java.security.cert.X509Certificate and accessible via a ServletRequest
attribute of javax.servlet.request.X509Certificate.

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
I would recommend caution here. OCSP deals exclusively with
revocation. While the certificate may not be revoked, it may not meet
PKIX validation requirements. User agent behavior with regard to CA
matching in the CertificateRequest part of the SSL handshake is made
in some cases by string comparison. Without a proper PKIX check, you
could be trusting by naming alone, which would totally subvert the
signature-based checks at the heart of PKI.

M
_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-users] Trusting all client certificates still causes certificates not in trust store to fail (9.0.0.M3)

Ago Allikmaa
Yes, it does, I'll grab that when a new tag is out, I'll keep the wrapper workaround on RC0 for the moment.

Now I've looked at the code a bit - it seems "trust all" doesn't affect signature checks (only hostname checks) if either keyStore or trustStore
is defined. That seems a bit odd to me - why is keyStore even a factor in this? I think changing that would make it possible to use complete
"trust all" method for client certificates too, because right now I can't do that since I have a keyStore set so the server could identify itself to
the client.

Actually I'm not sure if I'd go through the trouble of trying to do manual certificate validation anymore (I would indeed prefer more useful error
messages, but it's not really critical for my purposes right now), but I definitely think letting any certificate through the SSL layer should at least
be made possible without creating custom trust managers, if the only obstacle is the keyStore check.

Thanks to everyone.

Ago

On 20.02.2013 0:34, Joakim Erdfelt wrote:
Does this commit (post RC0) help you?


--
Joakim Erdfelt <[hidden email]>
Developer advice, services and support
from the Jetty & CometD experts


On Tue, Feb 19, 2013 at 3:08 PM, Ago Allikmaa <[hidden email]> wrote:
A little update. Enabling the OCSP with SslContextFactory didn't seem to break anything. Any way to verify that it is actually doing a successful OCSP check?

I couldn't get client certificates to work with M5, RC0, but it worked in M3. The commit that breaks my code is at:
http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/commit/jetty-util/src/main/java/org/eclipse/jetty/util/ssl/SslContextFactory.java?id=9ebea3938d473cc897fc71db5e1f266ed17adbff

Why would hostname verification cause my client certificate verification to fail? And what is the point of it anyway - I'm writing a server, the client
certificate isn't supposed to contain a hostname that resolves to his IP address.

Currently I simply wrote a wrapper that "rolls back" this commit. Any suggestions about whether it is a bug or after that commit I just have to use it differently?

Also I googled a bit about not dropping the connection when the client certificate is invalid - found that using a custom TrustManager should do the trick,
but I have no idea how I could make Jetty use it. Any ideas?

Ago


On 19.02.2013 17:58, Ago Allikmaa wrote:
Thanks for the info.

Basically I have the CA certificates. I was under the impression that if I do OCSP, it also checks if the certificate is signed, but if that's not the case,
I guess I could let the SSL layer handle that at least. The perfect way for me would be that the client certificate is checked against the CA certificates,
but even if it's detected to be invalid, my servlet will run, but I could simply find out whether the check was a success or not. I find these automatic
errors that actually just confuse the end-user really annoying, I'd like to respond to failure in a way I choose, especially because the errors that
Jetty servers throw are quite ambiguous, resulting in Opera and Firefox to say "Unable to connect" and "Connection was interrupted" respectively,
only Chrome manages to deduce it has something to do with SSL at all. Most sites I've encountered throw an error that the browser interprets as
an "SSL handshake failure".

Now, I added the CA certificates to the trust store. With M3, it works nicely, but with RC0 I get the usual errors after selecting the certificate
and entering the PIN (it's a certificate from a smart card). Is this a possible regression?

Even with M3 and CA certificates, I'm not sure how to do OCSP properly. SslContextFactory has methods setEnableOCSP and setOcspResponderURL,
but the reference implementation provided by the OCSP/smart card operator also uses a OCSP responder certificate (there's a corresponding one for
each of the CA certificates) that is passed to openssl via the "-VAfile" file argument. How would I use these in Jetty?

Ago

On 19.02.2013 17:17, Marvin Addison wrote:
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?)
The server sends all CA names listed in the _server_ truststore in the
"CertificateRequest" message sent to the client. The user agent
(browser) will only allow you to choose from certificates it knows
about that are issued by the list of CAs mentioned by the server. The
diagram in the "SSL Protocol" section of the JSSE documentation may be
a helpful reference:

http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html

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?
Assuming Jetty implements the relevant part of the servlet specification:

If there is an SSL certificate associated with the request, it must be
exposed by
the servlet container to the servlet programmer as an array of objects of type
java.security.cert.X509Certificate and accessible via a ServletRequest
attribute of javax.servlet.request.X509Certificate.

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
I would recommend caution here. OCSP deals exclusively with
revocation. While the certificate may not be revoked, it may not meet
PKIX validation requirements. User agent behavior with regard to CA
matching in the CertificateRequest part of the SSL handshake is made
in some cases by string comparison. Without a proper PKIX check, you
could be trusting by naming alone, which would totally subvert the
signature-based checks at the heart of PKI.

M
_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users



_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users