Download [#GLASSFISH-6935] [UB] No optional client authentication available

[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.