|Re: [jetty-users] Trusting all client certificates still causes certificates not in trust store to fail (9.0.0.M3)|
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=9ebea3938d473cc897fc71db5e1f266ed17adbffWhy 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 asan "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.htmlAssuming Jetty implements the relevant part of the servlet specification: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?If there is an SSL certificate associated with the request, it must be exposed bythe servlet container to the servlet programmer as an array of objects of typejava.security.cert.X509Certificate and accessible via a ServletRequest attribute of javax.servlet.request.X509Certificate.I'dlike to do the actual verification in a servlet, so I could invent my ownoutput in both failed and succeeded certificate check. The actual verification is basically an OCSP queryI 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
Back to the top