Re: [jetty-users] Trusting all client certificates still causes certific

[Ago Allikmaa <maxorator@xxxxxxxxx>]

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