Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
[GLASSFISH-6935] [UB] No optional client authentication available in HTTPS connector Created: 15/Dec/08 Updated: 31/Oct/12 Resolved: 31/Oct/12 Status: Project: Component/s: Affects Version/s: Fix Version/s: Closed glassfish docs 9.0pe Type: Reporter: Resolution: Labels: Remaining Estimate: Time Spent: Original Estimate: Environment: Improvement asyd Fixed None Not Specified Issuezilla Id: 6,935 3.1.2 Priority: Assignee: Votes: Critical Mike Fitch 4 Not Specified Not Specified Operating System: All Platform: All Description Actually it's only possible to create a HTTPS connector with client authentication disable or required. Usually, the client authentication of a HTTPS connector can be configured in 3 ways, none, optional, or required. The optional mode is very useful with SSO softwares, like OpenSSO and it's very annoying it's not possible to do that with Glassfish. Comments Comment by jfarcand [ 16/Dec/08 ] Grizzly already support optional, but this is not exposed via domain.xml. We are working on a grizzly-config file configuration and for sure we will be able to support what you are asking. Comment by Alexis MP [ 19/Feb/09 ] "optional" seems to be more useful than "required" for such an SSO use-case. Tomcat exposes this using the clientAuth parameter in the <connector> config. With a "want" value, it enables the server to request a client Certificate, but not fail if one isn't presented. See http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html User has gone back to using Tomcat for the time being. Bumping up the priority a bit. Comment by jfarcand [ 19/Feb/09 ] This will be available once grizzly-config gets integrated Justin is working on that Comment by superpat7 [ 19/Feb/09 ] This will be very useful for OpenSSO. At present, some deployments are forced to use an alternative web container due to GF's 'all or nothing' approach to client auth HTTPS. Comment by jfarcand [ 19/Feb/09 ] grizzly-config is not yet ready, but to make you all happy I will add a property to enabled it...should be added next time Grizzly integrate, which is next Monday if all goes well (I will break the build I'm sure ) Comment by asyd [ 19/Feb/09 ] very good news Comment by bblfish [ 20/Feb/09 ] This may also be what is needed to get foaf+ssl [1] to work on glassfish (without hacks). At least this is the way the apache implementors are doing things [2] Foaf+ssl makes it possible for web services to accept any certificates from any clients, even (and especially) if they are self signed. So an extra requirment (not sure as I am not a security expert) would be to have a mode where all client certificates are accepted. We have hacked jetty to get this done using the jsslutils library, and the code to do that is available in sommer.dev.java.net [4]. In this mode the connection should be rejected only if the basic cryptography is not satisfied (signatures don't match etc.) I am writing a SAM to then take over the authentication step. So is this an extra requirement I am adding to this issue, or is it solved by this? I'll leave it to the owners of the code to decide. [1] http://esw.w3.org/topic/foaf+ssl [2] as explained here: http://foaf.me/Enabling_SSL_Client_Certificates_on_Apache.php and as one can test out here: http://foaf.me/entry.php [3] http://code.google.com/p/jsslutils/ [4] as explained in the blog http://blogs.sun.com/bblfish/entry/foaf_ssl_a_first_implementation the code is browsable online in this directory https://sommer.dev.java.net/svn/sommer/trunk/misc/FoafServer/jetty/src/net/java/dev/sommer/foafserver/jetty/ Comment by bblfish [ 20/Feb/09 ] well I wanted to be updated on changes – perhaps I pressed the wrong button? Comment by harbulot [ 24/Feb/09 ] Although I don't know Glassfish very well, here is an additional suggestion. On top of supporting "true", "want" and "false" in its "clientAuth" attribute, Apache Tomcat also has an "SSLImplementation" attribute (case sensitive), which makes it possible to specify an alternative SSLImplementation, with additional properties. This option seems only documented up to Tomcat 3.3 [1], but it still works in version 6. For example, here is an implementation that uses jSSLutils: http://code.google.com/p/jsslutils/source/browse/#svn/trunk/extra/apachetomcat6/src/main/java/org/jsslutils/extr Provided its jar file is in Tomcat's lib directory, it's able to read a couple of extra attributes from the <Connector /> element in the Tomcat configuration. <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" keystoreFile="..." keystoreType="JKS" keystorePass="..." truststoreType="JKS" truststoreFile="..." truststorePass="..." SSLImplementation="org.jsslutils.extra.apachetomcat6.JSSLutilsImplementation" acceptAnyCert="true" clientAuth="want" sslProtocol="TLS" /> In this example, "acceptAnyCert" is an attribute that the default SSLImplementation doesn't support, but which is supported by JSSLutilsImplementation. Perhaps there could be something similar Glassfish, where one could specific the equivalent of an SSLImplementation and which would read additional properties (perhaps nested within <http-listener /> or within <ssl />). The benefits of this approach is that it makes it possible to have more unusual configurations of an SSLContext. I've used it with jSSLutils and added a couple of parameters: one to trust any certificate (that's the one useful for what Henry/bblfish is looking for), one to trust proxy certificates. I've also seen this SSLImplementation attribute used (without jSSLutils) in the Grid community. [1] http://tomcat.apache.org/tomcat-3.3-doc/tomcat-ssl-howto.html Comment by jfarcand [ 24/Feb/09 ] Since GlassFish is based on Tomcat 5.x, we also use SSLImplementation but we never exposed the way Tomcat 3 (was before I work on Tomcat ) does. It will requires a little bit of work to support such features, but I'm not saying no. I will investigate... Comment by monzillo [ 24/Feb/09 ] My recollection of the TLS/SSL protocol is a bit shaky, but... assuming that the server cannot identify all the possible self-signers in the certificate_authorities field of its certificate_request msg, how could the certificate_request msg sent by the server cause the client to select a suitable self-signed certificate. Do you need a specialized client (e.g. browser) that will respond with a certificate even though it does not match any of the authorities specified in the request? or does this approach require that the server, identify all the possible self-certifiers in the certificate request messages that it sends to its clients? Comment by monzillo [ 24/Feb/09 ] In case it's not clear, my previous comment pertains to the use of self-signed certs by clients (not servers); which is one aspect of this defect report, the other being support for optional client auth when the mechanims is SSL CLIENT-AUTH. fwiw, It should be possible to inject support for optional SSL mutual auth (in Glassfish) via a JSR 196 SAM; which I have been prototying with Henry. Comment by harbulot [ 24/Feb/09 ] If the X509TrustManager accepts any client certificate, using an empty method like this: public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException { } the CA list that the certificate request presents is empty. The browser can then present any certificate (for which it has the corresponding private key). There is a new paragraph an such empty lists in TLS 1.1. In practice, this seems to work at least with Firefox and Opera (and apparently IE). Comment by harbulot [ 24/Feb/09 ] Sorry, I missed that detail in the X509TrustManager, which is more pertinent: public X509Certificate[] getAcceptedIssuers() { return new X509Certificate[0]; } Comment by bblfish [ 25/Feb/09 ] Two additional points: 1. On the issue of why it is possible to get the browser to respond with any certificate it wants to is detailed in this mail http://lists.foaf-project.org/pipermail/foaf-protocols/2009-February/000264.html (It turns out this is a difference between the TLS1.0 and TLS1.1 spec) 2. Failing a connector element in the web.xml, which is not present in GlassFish 2.1 anyway, is there a way to hack GF so that it can accept a different SSLImplementation? This would at least allow me to experiment with GF here as well, and not just with Jetty or Tomcat. Comment by bblfish [ 26/Feb/09 ] So what I am looking for his how to replace the TrustManager I think. This is how we did it with Jetty [username: guest password: guest (or blank)] https://sommer.dev.java.net/svn/sommer/trunk/misc/FoafServer/jetty/src/net/java/dev/sommer/foafserver/jetty/S Having done that we were then able to do foaf+ssl identify verification in a servlet like https://sommer.dev.java.net/svn/sommer/trunk/misc/FoafServer/jetty/src/net/java/dev/sommer/foafserver/jetty/C I described the behavior of the resulting program in the following blog btw. http://blogs.sun.com/bblfish/entry/foaf_ssl_a_first_implementation Comment by monzillo [ 26/Feb/09 ] this comment refers to the original statement of the enhancement request; that being "No optional client authentication available in HTTPS connector". Can someone clarify why we need that feature? I can certainly deploy a web app, such that client authentication only occurs when it is required, and I can also configure a new SAM or Valve that will not reject the request when the client does not provide a certificate when one is requested. Perhaps this RFE applies more generally including to other parts of Glassfish. Comment by bblfish [ 27/Feb/09 ] Ok, just discovered that issue 189 "Allow custom X509TrustManager" is probably the right place to continue the discussion on custom TrustManagers. https://grizzly.dev.java.net/issues/show_bug.cgi?id=189 Though I am not sure how much that issue overlaps with Bruno Harbulot point that Tomcat allows for specific SSLImplementations in the <Connector> part of its xml, and that this may be a good thing to be able to specify in GF too. Comment by jfarcand [ 06/Mar/09 ] FYI, I'm testing the patch right now (I haven't forget). I will add support for optional client auth and also switching SSLImplementation. Should have something today for testing. Comment by jfarcand [ 13/Mar/09 ] Umbrealla issue in Grizzly: https://grizzly.dev.java.net/issues/show_bug.cgi?id=486 The fix will be with 1.9.9 which will be integrated in GlassFish 03/15 Comment by jfarcand [ 13/Mar/09 ] Umbrealla issue in Grizzly: https://grizzly.dev.java.net/issues/show_bug.cgi?id=486 The fix will be with 1.9.9 which will be integrated in GlassFish 03/15 Comment by jfarcand [ 13/Mar/09 ] The fix is temporary until grizzly-config gets integrated. But for now, you can configure: -Dcom.sun.grizzly.ssl.auth=want|need -Dcom.sun.grizzly.ssl.sslImplementation=class_name Comment by bblfish [ 26/Mar/09 ] The fix is in fact in Grizzly 1.9.10. We are trying to test this in GlassFish v3 b41, but we are not exactly quite sure how to do this. See the comment to https://grizzly.dev.java.net/issues/show_bug.cgi?id=486 and the thread https://glassfish.dev.java.net/servlets/ReadMsg?list=dev&msgNo=11373 Comment by jfarcand [ 30/Mar/09 ] Fixed by adding support directly in v3. Sending kernel/src/main/java/com/sun/enterprise/v3/services/impl/GrizzlyListenerConfigurator.java Transmitting file data . Committed revision 25747. Comment by Justin Lee [ 29/Jun/09 ] i'm not sure if you meant to add me to the CC list, but this is the first time i've seen this bug. (It came up in IRC...) I'm pretty sure this fix isn't in the code anymore. And I'm reasonably sure that grizzly-config doesn't support this option so we'll need to talk about exactly what's going on here and what I need to add to support it. Comment by Justin Lee [ 02/Jul/09 ] adding myself to the CC list Comment by Justin Lee [ 02/Jul/09 ] adding new attributes to ssl: client-auth: want/need/<blank> ssl-implementation: <class name> will migrate these properties to the new attributes. Comment by Justin Lee [ 02/Jul/09 ] starting Comment by Justin Lee [ 07/Jul/09 ] fixed in grizzly-config-1.0.12 Comment by roger_rong [ 31/Mar/10 ] Where is the documented usage for this optional client cert feature? Comment by Justin Lee [ 08/Dec/10 ] needs the documentation location... Comment by Mike Fitch [ 03/Jan/11 ] Adding [UB] to summary as this will be documented in Unbundled Documentation. Comment by schmidt75 [ 18/Jan/11 ] Does this fix work in GlassFish v3.1 b37? Ssl accepts client-auth="want", but has no effect for me in GlassFish v3.1 b37 (packaged with Netbeans 7.0 beta The certificate doesn't get requested in the browser. Alternatively, adding <property name="com.sun.grizzly.ssl.auth" value="want"/> to http-listener seems to have (as described here: http://blogs.sun.com/kalpana/entry/client_auth_requested_in_glassfish) Comment by Mike Fitch [ 26/Apr/11 ] Pushing to 3.2. The ssl element does have the client-auth attribute, but there doesn't seem to be an ssl-implement Comment by Mike Fitch [ 31/Oct/12 ] This issue was fixed in 3.1.2. See "To Configure Optional Client Authentication for SSL" at (http://docs.oracle.com/cd/E26576_01/doc.312/e24928/http_https.htm#CHDEDCEA). Comment by Mike Fitch [ 31/Oct/12 ] Closing resolved issue. Generated at Fri May 12 04:20:57 UTC 2017 using JIRA 6.2.3#6260sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.