FYI, I finally got this working. I recompiled against a locally compiled OpenSSL 0.9.8h and it handles the pathlen/proxies issue now. I came across the comments in some of the code in the 4.2.0 release -- I'll have to cite which file tomorrow, I think it was in "x509_vrfy.c" or may be the gsi callback code, something like that -- which mentioned the proxy issue with certain OSSL versions between certain 0.9.7x and 0.9.8x versions. I exported OPENSSL_CFLAGS, OPENSSL_LIBS, OPENSSL_INCLUDES and PATH to point to the later OpenSSL install and configured the build with "--enable-system-openssl" and ... voila ... no more path length exceeded errors!
On Thu, Aug 14, 2008 at 12:38 PM, I8abyte <[EMAIL PROTECTED]> wrote: > On Wed, Aug 13, 2008 at 2:45 PM, John Bresnahan <[EMAIL PROTECTED]> wrote: >> export GLOBUS_GSI_CALLBACK_DEBUG_LEVEL=3 >> >>> Here's a naive question ... how do I use >>> GLOBUS_GSI_CALLBACK_DEBUG_LEVEL with 'globus-crft', is there a doc or >>> something you can point me to? I'm just aiming to get a standalone >>> GridFTP/RFT service going with the new 'globus-crft' utility at this >>> point so I'm not sure how to employ GLOBUS_GSI_CALLBACK_DEBUG_LEVEL >>> with that. >>> >>> Ben-- >>> >> >> > > Dunno, that didn't seem to reveal a great deal that I could tell so > I'm not going to belabor that right now. Do any of you guys have a > description of how the path length relates in numeric constraints > (e.g., 0, 1, 2, 3 etc.)? It seems to be my 2nd level CA that's the > problem, it's path of "2" appears to be the constraint. > > Unfortunately my PKI knowledge is grossly limited. I.e., I have a > root CA with a path-length of "3" and a 2nd level CA with a > path-length of "2"; my 2nd level CA is the one that signed my personal > cert. Shouldn't that mean that certificates it issues are capable of > signing certs (proxies)? > > Can I limit or reduce the path-length checking without totally > compromising security? >
