Bug 3019 – Key appearing first in proxy certificate file causes GSI to die

Bug 3019 - Key appearing first in proxy certificate file causes GSI to die

Summary:

Key appearing first in proxy certificate file causes GSI to die

Status:	RESOLVED FIXED

Product:	GSI C
Component:	Credentials and Proxies
Version:	3.9.5
Platform:	Macintosh All

Importance:	P3 minor
Target Milestone:	4.2.2
Assigned To:	Joe Bester

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2005-03-27 22:23 by Von Welch
Modified:	2008-10-29 15:31 (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 Von Welch 2005-03-27 22:23:38

If the private key appears first (before all certificates) in the proxy
certificate file in /tmp, the C GSI libraries die trying to read the proxy file
(see below). Moving the key back behind any certificate causes the problem to go
away.

GSS Minor Status Error Chain:
globus_gsi_gssapi: Error with gss context
globus_credential: Error reading proxy credential
globus_credential: Error reading proxy credential: Couldn't read proxy's private
key from bio
OpenSSL Error: pem_lib.c:637: in library: PEM routines, function PEM_read_bio:
no start line Expecting: ANY PRIVATE KEY

------- Comment #1 From Sam Meder 2005-03-28 09:38:59 -------

Curious as to what you would like to see here? 

/Sam

------- Comment #2 From Von Welch 2005-03-28 10:08:21 -------

Seems like the order of key/certs in the proxy file shouldn't matter.

------- Comment #3 From Sam Meder 2005-03-28 10:17:49 -------

I agree that it shouldn't matter too much, but we currently rely on the certs
being in chain order and that the position of the key is fixed allows us to only
open the file once. I'll leave it open, but this seems pretty low priority to me.

/Sam

------- Comment #4 From Von Welch 2005-03-28 10:22:17 -------

No argument on the low priority, mainly wanted to put it on the record as it
took me a little to figure out.

------- Comment #5 From Sam Meder 2005-05-24 08:30:43 -------

*** Bug 3394 has been marked as a duplicate of this bug. ***

------- Comment #6 From Olle Mulmo 2005-05-24 08:53:22 -------

Be lean on what you read... there are several other softwares but
grid-proxy-init that creates proxy files nowadays. "Pretty low priority" sounds
like "will never be fixed" to me?

------- Comment #7 From Sam Meder 2005-05-24 20:51:19 -------

I'm certainly not going to have time to fix this in the foreseeable future.

/Sam

------- Comment #8 From Mike Jones 2007-11-20 05:43:17 -------

Folks, this bug causes issues with VOMS (v<1.7.18)...

The error occurs in the case where voms-proxy-init is used after a proxy is
delegated from a MyProxy server (i.e. CN=blah/CN=proxy/CN=proxy/CN=proxy) and
is used to obtain a VOMS AC proxy.

In this case voms-proxy-init creates a proxy where the chain looks as follows:
1, proxy proxy proxy proxy certificate
2, proxy proxy proxy proxy private key
3, proxy proxy proxy certificate
4, EE certificate
5, proxy certificate
6, proxy proxy certificate

Throwing this at GRAM results in three different failures depending on the
architecture of the server or the client machine and the type of GRAM
(WS/preWS), the user sees either a seg-fault, or the gram-client hanging.

The issue goes away if you get VOMS to play nicely (as in VOMS v>1.7.18), but
the bug is Globus'.

The symptoms were reported to the UK NGS via a user support ticket.  Suggest
you change the severity of this bug as a result.

------- Comment #9 From Von Welch 2008-03-18 08:31:40 -------

Bug 5924 is another example of the fragility of the credential reading code.
Basically it looks like the C GSI code expects the last certificate in the
chain, followed by the private key, then followed by the rest of the chain. Any
other order and you are living dangerously.

My impression is that the Java GSI code is more forgiving, but that's based on
second hand information.

This file format, along with the fact that the certificates and keys are
encoded with PKCS1 (the Java GSI does not accept PKCS8, although the C side
does - see Bug 4827), should all be documented at least.

The next best thing would then be to bring C and Java into line so they are
consistent.

And then the holy grail would be flexibility in the routines so they they
handle different variants better.

------- Comment #10 From Joe Bester 2008-10-29 15:07:39 -------

Fixed in 4.2 branch and trunk.