Bugzilla – Bug 3019
Key appearing first in proxy certificate file causes GSI to die
Last modified: 2008-10-29 15:31:22
You need to
before you can comment on or make changes to this bug.
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
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
Curious as to what you would like to see here?
Seems like the order of key/certs in the proxy file shouldn't matter.
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.
No argument on the low priority, mainly wanted to put it on the record as it
took me a little to figure out.
*** Bug 3394 has been marked as a duplicate of this bug. ***
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?
I'm certainly not going to have time to fix this in the foreseeable future.
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.
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
And then the holy grail would be flexibility in the routines so they they
handle different variants better.
Fixed in 4.2 branch and trunk.