Bugzilla – Bug 2589
Behavior of C and java grid-proxy-init differ, should be unified
Last modified: 2008-08-12 13:30:11
You need to
before you can comment on or make changes to this bug.
There was a DOE Grids CA certificate that was causing trouble with 3.9.4
container startup. Jarek looked into it, and found that the trouble was that
there were two copies of the certificate stored in the hostcert. The format was
like the following:
The following format can be used to install this certificate into a server.
Base 64 encoded certificate
Base 64 encoded certificate with CA certificate chain in pkcs7 format
The trouble is that the C based grid-proxy-init was able to create proxies from
this certificate with no trouble, but the java grid-proxy-init died with an error:
Subject and issuer names do not match)] [Root exception is
COM.claymoresystems.ptls.SSLThrewAlertException: Bad certificate
(Invalid certificate chain at 'Unknown
.teragrid.org' certificate. Subject and issuer names do not match)]]
The behavior of these two commands should be unified. If it is an error to have
two copies of the cert in the file, then the C g-p-i should complain. If it is
not an error, then the ProxyInit class should be modified to deal with the
situation however the C tool is dealing with it.
Adding Jarek because of the java angle to it.
does C g-p-i -verify work?
Btw, I found out that if I stick any certificate into my usercert.pem (after
the real user cert) and do C grid-proxy-init -verify works. Also globusrun -a -
r wiggum works. But if you look at the proxy file generated by the grid-proxy-
init that extra certificate is copied into the proxy certificate. Does OpenSSL
do some cert ordering?
As far as I know openssl treats certs it receives as part of the ssl handshake
as a pool. When it does path validation on the remote end it index the received
certs by DN and builds the cert path that way. I do not think that SSL puts any
ordering constraints on the certs sent in the cert chain part.
C verify/debug is happy:
globus@tg-mayor1:~> grid-proxy-init -verify -debug -cert
/etc/grid-security/containercert.pem -key /etc/grid-security/containerkey.pem
User Cert File: /etc/grid-security/containercert.pem
User Key File: /etc/grid-security/containerkey.pem
Trusted CA Cert Dir: /etc/grid-security/certificates
Output File: /tmp/x509up_u518
Creating proxy ..........++++++++++++
Proxy Verify OK
Your proxy is valid until: Thu Jan 20 04:14:24 2005
To refine my comments a bit: I think SSL actually require the ordering so I was
wrong on that one (I'm pretty sure I am right about how OpenSSL deals with it
Just an update on issues discovered in the Java code:
1) PureTLS was not displaying the 'DC' component name of the DN
correctly: 'Unknown Attribute(0.9.2342.19200300.100.1.25)'. The code
responsible was fixed, and updated puretls.jar was committed to cog and gt4 cvs.
2) A bug was discovered in BC CertificateFactory with loading certificates from
PKCS7 data. The bug was reported to BC people. A workaround was committed in
CoG code and updated cog library committed to gt4 cvs.
As to the other issue, the Java code seems to understand the pkcs7 cert data
and adds it (at least the first certificate in pkcs7) to the chain to be
verified. So the chain essentially ends up with two exactly the same
certificates next to each other and the chain verification fails. I don't think
the effort of changing the Java code to assemble the certificates into the
right order is worth the time and energy. Therefore, the user has to ensure the
certificate files do no have bad or replicated certificates. From my point of
view the bug can be closed.
I just stumbled over this very bug. I agree that the C and Java tools should
exhibit uniform behavior. The error message from Java didn't give me any clue
except that something was wrong with the certificates. If you don't want to fix
the bug, a more illustrative Java error or warning message would be highly
appreciated. I daresay that such can significantly reduce traffic from
repetitive user questions. Do we want to have 100+ users stumble over it (the M$
approach), or do we want to add a sanity check, warning if two direct neighor
certificates are identical (IMO the friendly approach)?