Bug 2589 – Behavior of C and java grid-proxy-init differ, should be unified

Bug 2589 - Behavior of C and java grid-proxy-init differ, should be unified

Summary:

Behavior of C and java grid-proxy-init differ, should be unified

Status:	ASSIGNED

Product:	GSI C
Component:	Credentials and Proxies
Version:	1.1.3
Platform:	PC Linux

Importance:	P3 major
Target Milestone:	---
Assigned To:	Rachana Ananthakrishnan

URL:
Keywords:	C/Java

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2005-01-20 10:15 by Charles Bacon
Modified:	2008-08-12 13:30 (History)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description From Charles Bacon 2005-01-20 10:15:30

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

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
Base 64 encoded certificate with CA certificate chain in pkcs7 format
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

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
Attribute(0.9.2342.19200300.100.1.25)=org,Unknown
Attribute(0.9.2342.19200300.100.1.25)=doegrids,OU=Services,CN=host/tg-mayor1.uc
.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.

------- Comment #1 From Charles Bacon 2005-01-20 10:15:48 -------

Adding Jarek because of the java angle to it.

------- Comment #2 From Sam Meder 2005-01-20 10:30:03 -------

does C g-p-i -verify work?

/Sam

------- Comment #3 From Jarek Gawor 2005-01-20 10:35:51 -------

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?

------- Comment #4 From Sam Meder 2005-01-20 10:51:40 -------

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.

/Sam

------- Comment #5 From Charles Bacon 2005-01-20 10:55:23 -------

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
Your identity: 
/DC=org/DC=doegrids/OU=Services/CN=host/tg-mayor1.uc.teragrid.org
Creating proxy ..........++++++++++++
...............++++++++++++
 Done
Proxy Verify OK
Your proxy is valid until: Thu Jan 20 04:14:24 2005

------- Comment #6 From Sam Meder 2005-01-20 11:05:45 -------

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
though)

/Sam

------- Comment #7 From Jarek Gawor 2005-01-25 13:54:35 -------

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.

------- Comment #8 From Jens-S. V�ckler 2005-04-01 12:33:22 -------

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)?