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