You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
In the HTTP case we don't have access to raw or pem certs
and instead ask OpenSSL to supply the stack_of(x509). It would seem that
OpenSSL doesn't know (and probably shouldn't know) how to deal with
non-RFC compliant certs.
I don't understand this.
OpenSSL provides the STACK_OF(X509*) without doing any sort of chain validation (which is where non-RFC compliance is relevant). It is literally just a pointer to the ordered list of parsed X509 objects from OpenSSL. It's also what gets passed to security extractors and what worked in 4.x.
The fact you're seeing issues with old-style certificates suggests that something is either (a) not feeding the right chain to the certificate validation routines in XRootD or (b) somehow OpenSSL validation is being used. Either case is bad; even though the OpenSSL validation of RFC proxies can be invoked, these are known to be fairly buggy and I'd suggest to use the XRootD ones instead.
While I'm also ambivalent on fixing old-style proxies, this is a bit of a warning signal that something is broken in the new code for proxy validation. I wouldn't be surprised if we see other issues crop up here.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1