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

Re: error reporting in tls_get_cert()


Ok, I see. The error number was reported earlier on with the '-d' option. I did not notice that

Howard Chu wrote:
...
> My tendency here is to lean on the

conservative side since that's the point of using TLS in the first place,
and make the default be to treat verify failures as fatal errors.


I agree.  verify failures should be fatal.

Another issue this brings up is that in openldap, there doesn't seem to be a standard error message prefix. This makes it hard to distinguish between 'informational', 'warning', and 'error' messages.

A prefix should be introduced. This could be anything really, although something that stands out would be nice. 'error:', '##error:', 'ERROR:', '##ERROR:', '##ERROR!!:' would all work. The '##' before the prefix itself seems to be popular, both gcc and make does this, iirc.

Currently the warning looks like...
...
TLS trace: SSL_connect:SSLv3 read server hello A
TLS certificate verification: depth: 0, err: 18, subject: /C=US/ST=FLORIDA/L=MELBOURNE/O=FIT/OU=IT/CN=bashful.eng.fit.edu, issuer: /C=US/ST=FLORIDA/L=MELBOURNE/O=FIT/OU=IT/CN=bashful.eng.fit.edu
TLS trace: SSL_connect:SSLv3 read server certificate A
...

Notice the lines beginning with "TLS trace:" are only informational, but there is no way to distinguish it from the warning message ( which should be an error ) in the middle.

I think warnings and errors should be prefixed, while informational messages don't have to. So we would have...

...
TLS trace: SSL_connect:SSLv3 read server hello A
##WARNING: TLS certificate verification: depth: 0, err: 18, subject: /C=US/ST=FLORIDA/L=MELBOURNE/O=FIT/OU=IT/CN=bashful.eng.fit.edu, issuer: /C=US/ST=FLORIDA/L=MELBOURNE/O=FIT/OU=IT/CN=bashful.eng.fit.edu
TLS trace: SSL_connect:SSLv3 read server certificate A
...

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support


-----Original Message-----
From: owner-openldap-devel@OpenLDAP.org
[mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Kervin L. Pierre



Hello,

I've been trying to track down the reason for SSL/TLS not working on my
system from current CVS.

In the function tls_get_cert() verifies certs, but lumps all errors
returned from SSL_get_verify_result() as "bad certificate".

The test in tls_get_cert() looks like...

tls_get_cert( SSL *s )
{
        /* If peer cert was bad, treat as if no cert was given */
        if (SSL_get_verify_result(s)) {
                /* If we can send an alert, do so */
...

The value returned from SSL_get_verify_result() is thrown away.  But
this value is important for debugging and should be reported to the
user.  The error messages for the return value can be found in the
"openssl verify" manpage or http://www.openssl.org/docs/apps/verify.html

I know logging is in flux right now.  But can this be reported to the
user at some debug level?  I am willing to do the patch if advised.

--Kervin 




--Kervin