Re: [Pki-devel] SSL handshake problem

Adding Elio to the thread in case he has any thoughts on this... On 08/16/2012 11:49 AM, Endi Sukma Dewata wrote: > Hi, > > 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: > > 1. Get the latest Dogtag 10 source code. > 2. Apply the attached pki-certrequest.patch. > 3. Get the pki-dev tools (see > http://pki.fedoraproject.org/wiki/Testing). > 4. Execute these commands in pki-dev/scripts to build and install CA: > > % ./theme-build.sh > % ./theme-install.sh > % ./core-build.sh > % ./core-install.sh > % ./ds-create.sh > % ./ca-create.sh > > 5. Then execute these test commands in pki-dev/scripts: > > % ./cert-request-submit.sh cert-request.xml (note the Request ID) > % ./cert-request-review.sh <Request ID> review.xml > % ./cert-request-approve.sh review.xml > > 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. > > These commands use Apache HTTP Client library which has a parameter > called MIN_CHUNK_LIMIT (see > http://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/org/apache/h...). > 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. > > 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. > > 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. > > 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. > > 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. > > 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? > > Thanks. > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel(a)redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel