Re: IMAP certificate warning

[Brian Stafford <brian stafford uklinux net>]

On Thu,  8 November 14:09 Carlos Morgado wrote:
> 
> On 2001.11.08 13:35:19 +0000 Pawel Salek wrote:
>> 
>> On 2001.11.08 13:27 Toralf Lund wrote:
>>> When connecting to an imap server using TLS or SSL I always get the 
>>> message "This certificate accepted but not verified". I used to think that 
>>> this happened because we were using a self-signed certificate, but we now 
>>> have purchased an official one, and the warning is still displayed. I this 
>>> expected to happen? Is certificate check implemented at all?
>> 
>> It's not yet implemented.
>> 
> 
> actually, we go through the cert check functions, and where mutt would ask
> the user 'what do you want to do now' we just put out that error and get
> on with it.
> the error message is a bit misleading, it doesn't mean the cert is invalid,
> it means we couldn't verify it.  that may happen cause we don't know the
> signers key or somesuch. i'll have to check into this a bit harder, stare
> down my openssl config and try to get some clue.
> 
> brian, do you have any insight into all this openssl and cert checking
> thing ?

Sorry about the late reply, my mail was off line yesterday afternoon!

I guess you know what is in the next paragraph but I'll say it anyway :)
===

Regarding validation of the server certificate in a client; the SSL/TLS 
protocol will supply the server certificate to the client.  The default 
validation callback in OpenSSL handles the typical case reasonably, however if 
it cannot verify the certificate based on the trusted CAs or the cert is self 
signed or is otherwise inconsistent, the call to SSL_connect() will fail and 
no TLS session is established.  For this reason, it might be useful to supply 
a custom validation callback which accepts any certificate for establishing a 
connection, this will allow SSL_connect() to succeed with unknown CAs etc.  
Either way, SSL_get_verify_result() can then be used to decide whether to 
proceed; even with the default callback there are conditions where some 
clients might not accept a certificate that is otherwise acceptable to OpenSSL.

===
End of stating the obvious ;)

What I suspect is happening is that Balsa does not have a list of trusted top 
level CAs and hence is unable to verify that the official certificate is 
genuine.  If you look for starttls_create_ctx() in smtp-tls.c (with the 
libESMTP distro) you will see my approach to setting up the trusted CA list.  
I guess libmutt does something similar.

Part the problem here is that OpenSSL (AFAIK) has no system wide structure for 
configuring CRLs, CA certifictates etc. so every application does its own 
thing.  It is possible that the top level CAs are set up for another app. but 
balsa (or libESMTP for that matter) has no idea where they are, even if the 
other app is an OpenSSL one.  Another problem is that certs are stored in PEM 
format which is simple but not used by most CAs.  This means most punters will 
have a problem installing the CA certificate - worse, it has to be done for 
every app.  Since some apps will try to use more conventional certificate 
formats than PEM installation is a nightmare - convert to format for app a, 
store in directory for app a - convert to format for app b ... you get the 
picture.


A thought occurrs to me.  I noticed the GNU TLS suite mentioned on Freshmeat 
the other day.  Perhaps we should look into this for TLS in our (L)GPLed 
programs; if we got in soon enough it might be in time to solve the 
certificate management side of things on a system wide basis.  Thoughts?

Brian