Re: ssl client certificates

Andrew Steets wrote:

>Though I just realized that I made a change to an .h file and
>not the .html file so cvs is currently broken, also I broke
>"webbot -v w/ the last patch too :) Patch to fix is below.
>  
>
Easy enough, though it would be nice to generate the html from the source.

    Checking in Library/src/SSL/HTSSL.html;
    /sources/public/libwww/Library/src/SSL/HTSSL.html,v  <--  HTSSL.html
    new revision: 1.4; previous revision: 1.3
    done
    Checking in Robot/src/RobotMain.c;
    /sources/public/libwww/Robot/src/RobotMain.c,v  <--  RobotMain.c
    new revision: 1.15; previous revision: 1.14
    done

Moving around the "-v" option processing sort of brings up how handy 
getopt could be . . .

BTW, the log files only show a couple of things.  Had you noticed, either

    /usr/share/aclocal/gob2.m4:7: warning: underquoted definition of
    GOB2_HOOK
      run info '(automake)Extending aclocal'
      or see
    http://sources.redhat.com/automake/automake.html#Extending-aclocal

or

    HTRobot.c:403: warning: null argument where non-null required (arg 1)
    HTRobot.c:403: warning: null argument where non-null required (arg 2)
    HTRobot.c:403: warning: null argument where non-null required (arg 1)
    HTRobot.c:403: warning: null argument where non-null required (arg 1)
    HTRobot.c:403: warning: null argument where non-null required (arg 1)
    HTRobot.c:403: warning: null argument where non-null required (arg 2)
    HTRobot.c:403: warning: null argument where non-null required (arg 1)
    HTRobot.c:403: warning: null argument where non-null required (arg 2)

Not that we can do anything about the first one, but the "null 
arguement" one . . .

>So I also have some thoughts I'd like your opinion on.  The current
>libwww SSL does not verify anything other than the length of the cert
>chain from the server (the "verifydepth").  That is, it does _not_
>verify against any trusted CA certs or check activation/expiration
>dates or anything like that.  
>
Yes, it currently just does the very basic bit of function.

>According to <openssl/x509_vfy.h> there are nearly 30 reasons a server cert could be invalid and we only check one.  We are getting encryption, but not really any proper authentication.  
>
Is there a good way detect and report such authentication failures ?  

>I will have to tighten this up (in verify_callback()
>from HTSSL.c) for the particular application I have in mind, but I was
>curious if you know of a good way to do this and fit it in w/ the
>whole libwww scheme of things.
>  
>
Good question.  For example, how would we want to treat date range 
errors like,

    #define         X509_V_ERR_CERT_NOT_YET_VALID                   9      
    #define         X509_V_ERR_CERT_HAS_EXPIRED                     10
    #define         X509_V_ERR_CRL_NOT_YET_VALID                    11
    #define         X509_V_ERR_CRL_HAS_EXPIRED                      12

as differing from an invalid certificate authority like,

    #define         X509_V_ERR_INVALID_CA                           24

Is the error handling an application policy decision that might vary by 
use case ?

more,
l8r,
v

Received on Monday, 28 February 2005 05:22:10 UTC