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?
--
Developer advice, services and support
from the Jetty & CometD experts
On Tue, Feb 19, 2013 at 3:08 PM, Ago
Allikmaa <maxorator@xxxxxxxxx>
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
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
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-users
|