[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: proposal, library error codes for TLS failures



On 04/17/2012 06:15 PM, Howard Chu wrote:
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.

We need some way for developers writing applications that use the OpenLDAP API to get more detailed information from TLS/SSL connection and other failures.