<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Adding Elio for real this time...<br>
      <br>
      On 08/17/2012 02:07 PM, Nathan Kinder wrote:<br>
    </div>
    <blockquote cite="mid:502EB298.6040505@redhat.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">Adding Elio to the thread in case he
        has any thoughts on this...<br>
        <br>
        On 08/16/2012 11:49 AM, Endi Sukma Dewata wrote:<br>
      </div>
      <blockquote cite="mid:502D40CE.8080107@redhat.com" type="cite">Hi,
        <br>
        <br>
        I'm having a problem running a CLI operation on Dogtag 10 which
        seems to be caused by SSL handshake issue. Here are the steps to
        reproduce: <br>
        <br>
        1. Get the latest Dogtag 10 source code. <br>
        2. Apply the attached pki-certrequest.patch. <br>
        3. Get the pki-dev tools (see <a moz-do-not-send="true"
          class="moz-txt-link-freetext"
          href="http://pki.fedoraproject.org/wiki/Testing">http://pki.fedoraproject.org/wiki/Testing</a>).

        <br>
        4. Execute these commands in pki-dev/scripts to build and
        install CA: <br>
        <br>
         % ./theme-build.sh <br>
         % ./theme-install.sh <br>
         % ./core-build.sh <br>
         % ./core-install.sh <br>
         % ./ds-create.sh <br>
         % ./ca-create.sh <br>
        <br>
        5. Then execute these test commands in pki-dev/scripts: <br>
        <br>
         % ./cert-request-submit.sh cert-request.xml (note the Request
        ID) <br>
         % ./cert-request-review.sh <Request ID> review.xml <br>
         % ./cert-request-approve.sh review.xml <br>
        <br>
        Both review and approve operations are done via SSL and they
        require client certificate authentication. However, the review
        works, but the approve operation fails with HTTP code 401
        (Unauthorized). This is because the review is a GET operation
        which doesn't send any data, but the approve is a POST operation
        which sends a relatively large data. <br>
        <br>
        These commands use Apache HTTP Client library which has a
        parameter called MIN_CHUNK_LIMIT (see <a moz-do-not-send="true"
          class="moz-txt-link-freetext"
href="http://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/org/apache/http/params/CoreConnectionPNames.html">http://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/org/apache/http/params/CoreConnectionPNames.html</a>).

        The parameter is set to 512 bytes by default, so any request
        longer than that (such as the approve request) may be sent in
        multiple chunks. <br>
        <br>
        It seems that the current Tomcat JSS doesn't properly handle a
        request sent in multiple chunks. Currently the
        JSSSocketFactory.handshake() is not doing the handshake. The
        initial handshake is actually done when the server starts
        reading the data stream, without asking for the client
        certificate. Then when the server needs to get the client
        certificate it will do an SSL renegotiation in
        JSSSupport.getPeerCertificateChain(). For some reason the
        renegotiation fails if the request is sent in multiple chunks. <br>
        <br>
        One possible solution is to fix either Tomcat JSS, JSS, or NSS
        to handle multiple request chunks properly. We'll need an expert
        in this area to investigate and fix it. <br>
        <br>
        Another solution is to raise the MIN_CHUNK_LIMIT on the client,
        but there's a hard limit of 8 KB and there might be 3rd party
        clients which we can't control. <br>
        <br>
        Another possibility is we might be able to remove the
        requirement for renegotiation (still to be confirmed).
        Originally the renegotiation is needed to access some pages in
        Dogtag Web UI so it will prompt for client certificate. In
        Dogtag 10 we're doing some reorganization so renegotiation might
        not be needed anymore. In general unprotected UI pages would be
        accessed via unsecured port, but when the user tries to access a
        protected page he will be redirected to a secured port. Here the
        client certificate will be asked during the initial negotiation.
        Since there is no unauthenticated SSL connection, there is no
        need for renegotiation. <br>
        <br>
        Assuming we don't need renegotiation anymore, I attached a patch
        for Tomcat JSS (tomcatjss-handshake.patch) to do the initial
        negotiation in JSSSocketFactory.handshake() that will also ask
        for the client certificate. With this patch the approve
        operation will work properly. Is this the right solution? Are
        there other solutions? <br>
        <br>
        Thanks. <br>
        <br>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
Pki-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Pki-devel@redhat.com">Pki-devel@redhat.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pki-devel">https://www.redhat.com/mailman/listinfo/pki-devel</a></pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Pki-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pki-devel@redhat.com">Pki-devel@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pki-devel">https://www.redhat.com/mailman/listinfo/pki-devel</a></pre>
    </blockquote>
    <br>
  </body>
</html>