1:49 p.m.
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.
--
Endi S. Dewata
4:07 p.m.
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
4:23 p.m.
----- Original Message -----
From: "Nathan Kinder" <nkinder(a)redhat.com>
To: "Endi Sukma Dewata" <edewata(a)redhat.com>
Cc: "Bob Relyea" <rrelyea(a)redhat.com>, "pki-devel"
<pki-devel(a)redhat.com>
Sent: Friday, August 17, 2012 2:07:36 PM
Subject: 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.
Endi:
If we do the tomcatjss-handshake thing, does this still leave us with the Apache proxy ssl
client cert issue? Or was that a consequence of renegotiation? I don't remember.
Perhaps alee knows off the top of his head.
_______________________________________________
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
4:26 p.m.
Adding Elio for real this time...
On 08/17/2012 02:07 PM, Nathan Kinder wrote:
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
4277
days inactive
4278
days old
3 comments
3 participants
participants (3)
-
Endi Sukma Dewata -
John Magne -
Nathan Kinder