glassfish
  1. glassfish
  2. GLASSFISH-6935

[UB] No optional client authentication available in HTTPS connector

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 9.0pe
    • Fix Version/s: 3.1.2
    • Component/s: docs
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      6,935

      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.

        Activity

        asyd created issue -
        Hide
        jfarcand added a comment -

        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.

        Show
        jfarcand added a comment - 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.
        Hide
        Alexis MP added a comment -

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

        Show
        Alexis MP added a comment - "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.
        Hide
        jfarcand added a comment -

        This will be available once grizzly-config gets integrated Justin is working
        on that

        Show
        jfarcand added a comment - This will be available once grizzly-config gets integrated Justin is working on that
        Hide
        superpat7 added a comment -

        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.

        Show
        superpat7 added a comment - 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.
        Hide
        jfarcand added a comment -

        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 )

        Show
        jfarcand added a comment - 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 )
        Hide
        asyd added a comment -

        very good news

        Show
        asyd added a comment - very good news
        Hide
        bblfish added a comment -

        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/

        Show
        bblfish added a comment - 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/
        Hide
        bblfish added a comment -

        well I wanted to be updated on changes – perhaps I pressed the wrong button?

        Show
        bblfish added a comment - well I wanted to be updated on changes – perhaps I pressed the wrong button?
        Hide
        harbulot added a comment -

        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/extra/apachetomcat6%3Fstate%3Dclosed

        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

        Show
        harbulot added a comment - 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/extra/apachetomcat6%3Fstate%3Dclosed 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
        Hide
        jfarcand added a comment -

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

        Show
        jfarcand added a comment - 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...
        Hide
        monzillo added a comment -

        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?

        Show
        monzillo added a comment - 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?
        Hide
        monzillo added a comment -

        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.

        Show
        monzillo added a comment - 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.
        Hide
        harbulot added a comment -

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

        Show
        harbulot added a comment - 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).
        Hide
        harbulot added a comment -

        Sorry, I missed that detail in the X509TrustManager, which is more pertinent:

        public X509Certificate[] getAcceptedIssuers()

        { return new X509Certificate[0]; }
        Show
        harbulot added a comment - Sorry, I missed that detail in the X509TrustManager, which is more pertinent: public X509Certificate[] getAcceptedIssuers() { return new X509Certificate[0]; }
        Hide
        bblfish added a comment -

        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.

        Show
        bblfish added a comment - 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.
        Hide
        bblfish added a comment -

        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/SimpleServer.java

        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/CheckClient.java

        I described the behavior of the resulting program in the following blog btw.
        http://blogs.sun.com/bblfish/entry/foaf_ssl_a_first_implementation

        Show
        bblfish added a comment - 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/SimpleServer.java 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/CheckClient.java I described the behavior of the resulting program in the following blog btw. http://blogs.sun.com/bblfish/entry/foaf_ssl_a_first_implementation
        Hide
        monzillo added a comment -

        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.

        Show
        monzillo added a comment - 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.
        Hide
        bblfish added a comment -

        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.

        Show
        bblfish added a comment - 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.
        Hide
        jfarcand added a comment -

        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.

        Show
        jfarcand added a comment - 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.
        Hide
        jfarcand added a comment -

        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

        Show
        jfarcand added a comment - 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
        Hide
        jfarcand added a comment -

        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

        Show
        jfarcand added a comment - 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
        Hide
        jfarcand added a comment -

        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

        Show
        jfarcand added a comment - 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
        Hide
        bblfish added a comment -

        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

        Show
        bblfish added a comment - 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
        Hide
        jfarcand added a comment -

        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.

        Show
        jfarcand added a comment - 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.
        Hide
        Justin Lee added a comment -

        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.

        Show
        Justin Lee added a comment - 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.
        Hide
        Justin Lee added a comment -

        adding myself to the CC list

        Show
        Justin Lee added a comment - adding myself to the CC list
        Hide
        Justin Lee added a comment -

        adding new attributes to ssl:

        • client-auth: want/need/<blank>
        • ssl-implementation: <class name>

        will migrate these properties to the new attributes.

        Show
        Justin Lee added a comment - adding new attributes to ssl: client-auth: want/need/<blank> ssl-implementation: <class name> will migrate these properties to the new attributes.
        Hide
        Justin Lee added a comment -

        starting

        Show
        Justin Lee added a comment - starting
        Hide
        Justin Lee added a comment -

        fixed in grizzly-config-1.0.12

        Show
        Justin Lee added a comment - fixed in grizzly-config-1.0.12
        Hide
        roger_rong added a comment -

        Where is the documented usage for this optional client cert feature?

        Show
        roger_rong added a comment - Where is the documented usage for this optional client cert feature?
        kenaiadmin made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 6935 38539
        kumara made changes -
        Fix Version/s V3 [ 10981 ]
        Fix Version/s v3_b43 [ 11186 ]
        Hide
        Justin Lee added a comment -

        needs the documentation location...

        Show
        Justin Lee added a comment - needs the documentation location...
        Justin Lee made changes -
        Assignee cheeser [ cheeser ] Paul Davies [ pauldavies ]
        Component/s docs [ 10597 ]
        Component/s grizzly-kernel [ 10632 ]
        Paul Davies made changes -
        Assignee Paul Davies [ pauldavies ] oncered [ oncered ]
        Fix Version/s 3.1_ms08 [ 11017 ]
        Fix Version/s V3 [ 10981 ]
        Hide
        Mike Fitch added a comment -

        Adding [UB] to summary as this will be documented in Unbundled Documentation.

        Show
        Mike Fitch added a comment - Adding [UB] to summary as this will be documented in Unbundled Documentation.
        Mike Fitch made changes -
        Summary No optional client authentication available in HTTPS connector [UB] No optional client authentication available in HTTPS connector
        Hide
        schmidt75 added a comment -

        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 nightly build).
        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 no effect either
        (as described here: http://blogs.sun.com/kalpana/entry/client_auth_requested_in_glassfish)

        Show
        schmidt75 added a comment - 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 nightly build). 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 no effect either (as described here: http://blogs.sun.com/kalpana/entry/client_auth_requested_in_glassfish )
        Hide
        Mike Fitch added a comment -

        Pushing to 3.2. The ssl element does have the client-auth attribute, but there doesn't seem to be an ssl-implementation attribute.

        Show
        Mike Fitch added a comment - Pushing to 3.2. The ssl element does have the client-auth attribute, but there doesn't seem to be an ssl-implementation attribute.
        Mike Fitch made changes -
        Fix Version/s 3.2 [ 10969 ]
        Fix Version/s 3.1_ms08 [ 11017 ]
        Paul Davies made changes -
        Fix Version/s 3.1.1 [ 14740 ]
        Fix Version/s 3.2 [ 10969 ]
        Paul Davies made changes -
        Fix Version/s 3.1.2 [ 15100 ]
        Fix Version/s 3.1.1 [ 14740 ]
        Alexis MP made changes -
        Tags 3_1_2-review
        Joe Di Pol made changes -
        Tags 3_1_2-review 3_1_2-approved
        Joe Di Pol made changes -
        Tags 3_1_2-approved
        Hide
        Mike Fitch added a comment -

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

        Show
        Mike Fitch added a comment - 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 ).
        Mike Fitch made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Mike Fitch added a comment -

        Closing resolved issue.

        Show
        Mike Fitch added a comment - Closing resolved issue.
        Mike Fitch made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Mike Fitch
            Reporter:
            asyd
          • Votes:
            4 Vote for this issue
            Watchers:
            10 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: