DRM connector protection
by Andrew Wnuk
This patch prevents DRM connector to be overwritten by subsequent DRM
installations.
Bug 804179.
11 years, 8 months
[PATCH] PKI Deployment Framework PKI TRAC issues (08/14/2012)
by Matthew Harmsen
This patch documents continued implementation of the PKI Deployment
Framework based upon the revised filesystem layout documented here:
* http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#CA_.2F_KRA_.2F_...
This patch addresses the following issues:
* TRAC Ticket #266 - for non-master CA subsystems, pkidestroy needs to
contact the security domain to update the domain
* Made Fedora 17 rely upon tomcatjss 7.0.0 or later
It has been tested and proven to work successfully to
spawn/destroy/spawn a KRA as a separate instance on a 64-bit Fedora 17
machine (using the appropriate 'tomcatjss.jar').
P. S. - While fixing the parameters passed via "outputError()" in
'base/common/src/com/netscape/cms/servlet/csadmin/UpdateDomainXML.java',
I noticed that several of the other servlets in this directory also
utilized the "AUTH_FAILURE" error value for the second argument of
"outputError()" which gets passed as the string "2" --- while this
string is technically acceptable, I believe that this may be old usage
of some legacy parent method since "outputError()" is currently defined
in "base/common/src/com/netscape/cms/servlet/base/CMSServlet.java" as:
* protected void outputError(HttpServletResponse httpResp, String
errorString)
* protected void outputError(HttpServletResponse httpResp, String
errorString, String requestId)
* protected void outputError(HttpServletResponse httpResp, String
status, String errorString, String requestId)
so for all of my changes to "outputError()" in "UpdateDomainXML.java", I
merely changed these incorrect three parameter call versions to the two
parameter call version by removing the second parameter
("AUTH_FAILURE"). If I am correct about this seemingly legacy usage,
please let me know if I need to file a TRAC ticket for this issue.
Thanks,
-- Matt
11 years, 8 months
SSL handshake problem
by Endi Sukma Dewata
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
11 years, 8 months
[PATCH] 47 - Changes to get TPS ad RA working on dogtag 10
by Ade Lee
Changes to get TPS and RA running on dogtag 10
Added systemd scripts for RA and TPS. Modified init scripts
and configuration files to use correct directives for httpd 2.4.
TPS and RA subsystems are now installable using pkicreate
Please review,
Ade
11 years, 8 months
[PATCH] 99 Added pki-client.jar.
by Endi Sukma Dewata
A new pki-client.jar has been created to package the REST client
and CLI classes.
Ticket #215
--
Endi S. Dewata
11 years, 8 months
