Bugzilla – Bug 4994
Depth limit of 9 for proxy credentials - intentional, or no?
Last modified: 2008-12-10 11:00:24
You need to
before you can comment on or make changes to this bug.
There was a report to the mailing list that the C code won't verify proxies
at/past depth 9:
The same report mentions that WS service will also start failing after about
depth 20. The user mentions where the check is happening (we don't call
SSL_CTX_set_verify_depth, and 9 is the default), and I assume the Java side is
some BouncyCastle default.
Is this intentional? It has started biting people on the TeraGrid who use
Gsi-Openssh a lot. After enough logins across nodes, their delegated
credential is too deep to verify to gridftp or pre-ws GRAM. What can/should we
do about this?
No, it is not intentional. There is a mechanism to limit proxy delegation depth
(defined in RFC 3820), but AFAIK no one has every employed it. I assume this is
some hard-coded limit on either chain length (in terms of number of
certificates) or chain size (in terms of bytes) in some software.
The only solutions I can think of are: (1) fix the code, or (2) use myproxy to
transform a long-chained proxy into a fresh EEC.
Jim Basney mentioned this has also been an issue in EGEE I believe where they
have a number of service layers in place. I think he also said they are using
myproxy as I mention above to work around it.
Hidemoto Nakada (AIST) talked to me (and others) about this problem at OGF19.
They see it when doing interop testing with EGEE, because there are a lot of
proxy hops when translating between EGEE's gLite and NAREGI.
Please do fix the code. There should be no limit on the certificate chain
length by default, in my opinion.
Here is the error message from "gsissh -vvv" for the depth limit user proxy
OpenSSL Error: s3_srvr.c:2010: in library: SSL routines, function
SSL3_GET_CLIENT_CERTIFICATE: no certificate returned
globus_gsi_callback_module: Could not verify credential
globus_gsi_callback_module: Can't get the local trusted CA certificate
Here is a link that Charles also pointed me to that has a better explanation of
The routine “ssl_verify_cert_chain” in
source-trees/gsi/openssl_gpt/ssl/s3_srvr.c needs to report a less generic error
message than “no certificate returned”. This problem was not obvious from the
Fix for C code committed to trunk:
Merged this back to the 4.0 branch. It should be available in 4.0.9.