Does this commit (post RC0) help you? 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=bb3c1433f4e340a947e0d895304399f13a6c4b11
-- 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 Tue, Feb 19, 2013 at 3:08 PM, Ago Allikmaa <[email protected]> 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=** > 9ebea3938d473cc897fc71db5e1f26**6ed17adbff<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<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 >>> [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<https://dev.eclipse.org/mailman/listinfo/jetty-users> >
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
