Bug#829272: [openssl-dev] [openssl.org #4602] Missing accessors
On Mon, Jul 25, 2016 at 01:44:18PM +, Salz, Rich via RT wrote: > I am not sure what to suggest. This conversation is bouncing across > two ticket systems and is all about a legacy certificate format that > is, what, outdated since 2002? > I am hard-pressed to see why OpenSSL 1.1 has to do anything other than > what Richard proposed. The two ticket systems is indeed annoying and I don't know what to do about that (I did not start this thread) other than removing one of them. The point is that if OpenSSL is providing a verification callback which can be used to provide a custom verification of the cert chain, then it should provide the necessary handles and the thing still missing from what Richard proposed is a way to point to the failing certificate in the chain. We can set the error, but not at which depth in the chain the error occurred. This in itself is not limited to our use-case but is a general API request. Mischa > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602 > Please log in as guest with password guest if prompted > -- Nikhef Room H155 Science Park 105Tel. +31-20-592 5102 1098 XG Amsterdam Fax +31-20-592 5155 The Netherlands Email msa...@nikhef.nl __ .. ... _._. ._ ... ._ ._.. ._.. .._..
Bug#829272: [openssl-dev] [openssl.org #4602] Missing accessors
I am not sure what to suggest. This conversation is bouncing across two ticket systems and is all about a legacy certificate format that is, what, outdated since 2002? I am hard-pressed to see why OpenSSL 1.1 has to do anything other than what Richard proposed.
Bug#829272: [openssl-dev] [openssl.org #4602] Missing accessors
On Mon, Jul 25, 2016 at 12:47:56PM +, Salz, Rich via RT wrote: > > > That's exactly what we currently do, we provide a verification callback, but > > we do need to be able to set the failing cert in a chain for that. > > Stick it in EXDAT? I don't think I understand what you mean... For a proper callback, we need to be able to indicate which cert in the chain has failed. This used to be done by setting the 'current_cert' field in the CTX. I'm perfectly happy if we need to do this differently e.g. by using something like a X509_STORE_CTX_set_error_depth(X509_STORE_CTX *ctx,int depth); similar to the existing X509_STORE_CTX_get_error_depth() That actually would make the most sense in any case I would think, although I would mean that for properly handling proxy chains it would have negative values according to the man-page... Mischa -- Nikhef Room H155 Science Park 105Tel. +31-20-592 5102 1098 XG Amsterdam Fax +31-20-592 5155 The Netherlands Email msa...@nikhef.nl __ .. ... _._. ._ ... ._ ._.. ._.. .._.. smime.p7s Description: S/MIME cryptographic signature
Bug#829272: [openssl-dev] [openssl.org #4602] Missing accessors
On Mon, Jul 25, 2016 at 12:42:21PM +, Salz, Rich via RT wrote: > Perhaps the GRID folks can just write their own validation routine completely? That's exactly what we currently do, we provide a verification callback, but we do need to be able to set the failing cert in a chain for that. Mischa > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602 > Please log in as guest with password guest if prompted > -- Nikhef Room H155 Science Park 105Tel. +31-20-592 5102 1098 XG Amsterdam Fax +31-20-592 5155 The Netherlands Email msa...@nikhef.nl __ .. ... _._. ._ ... ._ ._.. ._.. .._.. smime.p7s Description: S/MIME cryptographic signature
Bug#829272: [openssl-dev] [openssl.org #4602] Missing accessors
Perhaps the GRID folks can just write their own validation routine completely?
Bug#829272: [openssl-dev] [openssl.org #4602] Missing accessors
> That's exactly what we currently do, we provide a verification callback, but > we do need to be able to set the failing cert in a chain for that. Stick it in EXDAT?
Bug#829272: [openssl-dev] [openssl.org #4602] Missing accessors
Hi Richard, On 20/07/16 17:14, Richard Levitte via RT wrote: On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote: I guess having a more restrictive accessor that only sets the EXFLAG_PROXY bit could work. I suggested the more general solution of having set/clear accessors for arbitrary flags since it was - well more general. So let me ask this in a different manner, does OpenSSL 1.1 still not set the EXFLAG_PROXY flag correctly? In what situations does that happen? That may be worth a bug report of its own. this ties into my earlier question and example of verifying proxy certificates. What if I want to explicitly *set* the EXFLAG_PROXY for a stack of certificates? how would I do that? how can I ensure that OpenSSL 1.1 will automagically trigger this flag for me? Is there a 'get_*' function to determine which flags were set during certificate verification? thanks for any pointers or advice, JJK / Jan Just Keijser
Bug#829272: [openssl-dev] [openssl.org #4602] Missing accessors
On Mon, 2016-07-11 at 13:08 +, Mattias Ellert via RT wrote: > > > Looking at the various places in the code where get_issuer > and check_issued are accessed, they mostly use the context rather than > the store. Here are the places I have found: > > https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L71 > > https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1581 > > https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1588 > > https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L367 > > https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L1059 > > https://sources.debian.net/src/globus-gsi-credential/7.9-2/library/globus_gsi_cred_handle.c/#L1997 > > And the following one actually uses the store and not the context: > > https://sources.debian.net/src/globus-gssapi-gsi/12.1-1/library/globus_i_gsi_gss_utils.c/#L448 I was using store.get_issuer() in OpenConnect too, because I need to manually build the trust chain to include it on the wire — because even today the server might *still* suffer RT#1942 and fail to trust our client cert unless we help it by providing the *right* chain. I've worked around the lack of access to get_issuer() by doing a dummy call to X509_verify_cert(), throwing away its result and then hoping that we have something useful in store.chain (which we *can* still access). That seems to work but I'm not stunningly happy with it; if we can have an accessor I'd much rather go back to doing it the old way. http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0 (in workaround_openssl_certchain_bug() in the hunk around line 1306) -- dwmw2
