Re: proposal, library error codes for TLS failures

Dmitri Pal wrote: > On 04/17/2012 05:21 PM, Howard Chu wrote: >> Jan Vcelak wrote: >>>> About the -Z option (attempted TLS without verification): >>> >>> Actually this is not about -Z behavior. I just mentioned in the mail, >>> that it would be great if the library provided more information >>> about the type of the failure. >> >> Perhaps more context about where this perceived need is coming from >> would have helped the public discussion. Dmitri Pal @ Red Hat pointed >> me to a bug report that seems to have been the catalyst for this >> request. We exchanged a few responses and I thought it would be useful >> to re-join the public conversation. >> >> Dmitri Pal wrote: >>> On 04/17/2012 01:43 PM, Howard Chu wrote: >>>> Dmitri Pal wrote: >>>>> I did not say it is a major problem but we have seen multiple >> times on >>>>> our community lists people trying to setup TLS for SSSD (openssl >> or nss) >>>>> manually and getting the certificate problems that are hard to >> diagnose. >>>>> Here is one of them filed by our QE as we followed up on one of the >>>>> community threads: >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=640393 >>>>> And as you see it is not on the NSS or openssl level. If the paths >> are >>>>> not configured properly (a typo in the path for example) you will >> get a >>>>> certificate error but it is actually a wrong path. Unfortunately the >>>>> lowest layer that knows about the issue is openldap not underlying >>>>> crypto module. >>>>> This is the kind of issue that we want to fix. >>>> >>>> This is exactly the kind of issue that NSS makes messy to fix. >>>> Normally we know that cacertdir and cacert must point to a directory >>>> and a file, respectively. It would be feasible to check access(path, >>>> R_OK) or something at the time that an app calls ldap_set_option() on >>>> them. But with NSS, these parameters might be something else entirely >>>> - a DB path and a cert name within the DB, and such pathname-based >>>> checks would give spurious failures. >>>> >>>> Because of NSS, nobody but the underlying crypto module knows what >>>> these parameters actually mean. >> >> I.e., it is not an OpenLDAP level issue, it is precisely an NSS issue. >> >>>> path not found/no permission is certainly a common failure condition, >>>> but running in debug mode makes that obvious, because the explicit >>>> error text is logged on stderr. >>>> >>>> If I configure slapd.conf with >>>> TLSCACertificateFile /some/bogus/path >>>> >>>> and try to start it, I get: >>>> >>>> TLS: could not load verify locations >>>> (file:`/some/bogus/path',dir:`'). >>>> TLS: error:02001002:system library:fopen:No such file or directory >>>> bss_file.c:169 >>>> TLS: error:2006D080:BIO routines:BIO_new_file:no such file >> bss_file.c:172 >>>> TLS: error:0B084002:x509 certificate >>>> routines:X509_load_cert_crl_file:system lib by_file.c:274 >>>> 4f8daa38 main: TLS init def ctx failed: -1 >>>> 4f8daa38 slapd destroy: freeing system resources. >>>> 4f8daa38 slapd stopped. >>>> 4f8daa38 connections_destroy: nothing to destroy. >>>> >>>> It's quite obvious "No such file or directory". >>>> >>>> If the cause of failure isn't as obvious with NSS, then again I have >>>> to say, it seems to me that you're looking in the wrong place for a >>>> solution. > I value everybody's time too and understand that creating a good > abstraction is a cost especially if single solution worked in the past. > So following the rules of the meritocracy it is completely reasonable to > expect that whoever has the need does the work. And this is the case > here. But we want to do the work in the least intrusive way and to > address as many concerns as possible. So the question was and is "can > you please let us know how we should implement it to make things work > for everybody?". OK. But at the moment I still don't understand why providing the debug output (as we already do) isn't sufficient to allow administrators to identify their misconfiguration issues.