Re: [fetchmail-users] User poll: how do you expect --sslcertpath to behave?

[Matthias A. <mat...@gm...>]

Am 20.04.2010, 01:23 Uhr, schrieb Michael Banack:

> (2) Offhand, I think that your personal ones should be checked first, so
> if you have a custom certificate, it gets used before the general ones.
> But I don't understand why this matters.  Won't a certificate check
> succeed if it finds a matching authority?  Whether its checked first or
> second, it shouldn't be visible to the users.  Unless someone wants to
> replace a particular root cert with their own personal version (which is
> really weird), in which case the one they gave should be used first.

Hi Michael,

Thanks for your input.

I am just picking out (2) to reply to: it appears to matter because the  
OpenSSL documentation - the manual page  
SSL_CTX_load_verify_locations(3ssl) reads, as of 0.9.8,

       "... Certificate matching
        is done based on the subject name, the key identifier (if present),  
and
        the serial number as taken from the certificate to be verified. If
        these data do not match, the next certificate will be tried. If a  
first
        certificate matching the parameters is found, the verification  
process
        will be performed; no other certificates for the same parameters  
will
        be searched in case of failure."

I do not currently oversee what parameter would be changed without the  
certificate being considered different in a typical failure scenario (lack  
of experience), but using the default paths first means that the user  
cannot locally override a broken/outdated/reissued system certificate  
without precluding the system path altogether. I guess such failures would  
be subtle and hard to debug because the most obvious thing, namely the  
certificate subjects and issuer, might be the same. I also guess that a  
decent CA would bump the serial number when changing, for instance,  
subjectAltNames, but then again, errors do happen even without any malice  
or cluelessness involved.

Most of these considerations apply to scenarios where the user has no  
control over the system-wide certs directory, else the user can fix the  
root cause of his/her issues.

HTH

-- 
Matthias Andree