On 12/24/2011 08:54 PM, Timothy Murphy wrote: > 夜神 岩男 wrote: > >>> I'm trying to setup sendmail/dovecot on a new server running CentOS-6 >>> (well, CentOS-6.2 now). >>> Everything seems to go well, but when I run fetchmail I get this warning: >>> ------------------------------------ >>> [tim at grover ~]$ fetchmail imap.maths.tcd.ie >>> fetchmail: Warning: the connection is insecure, continuing anyways. >>> (Better use --sslcertck!) >>> ------------------------------------ >>> >>> If I do add --sslcertck (as suggested) I get the response: >>> ------------------------------------ >>> [tim at grover ~]$ fetchmail --sslcertck imap.maths.tcd.ie >>> fetchmail: Server certificate verification error: self signed certificate >>> fetchmail: This means that the root signing certificate (issued for >>> /C=IE/ST=Dublin/L=Dublin/O=School of Mathematics, Trinity College, >>> Dublin./OU=Automatically-generated IMAP SSL >>> key/CN=imap.maths.tcd.ie/emailAddress=postmaster- > k8gv5eYDmBCYFDSwBDOiMg at public.gmane.org) >>> is not in the trusted CA certificate locations, or that c_rehash needs to >>> be run on the certificate directory. For details, please see the >>> documentation of -- sslcertpath and --sslcertfile in the manual page. >>> 139925738739528:error:14090086:SSL >>> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify >>> failed:s3_clnt.c:1063: >>> fetchmail: SSL connection failed. >>> fetchmail: socket error while fetching from >>> tim at imap.maths.tcd.ie fetchmail: Query >>> status=2 (SOCKET) >>> ------------------------------------ > >> Its just healthier, more detailed warnings that what you got before. >> >> SSL/TLS relies on a third party verification of a certificate. This >> means a third party's signature on the certificate of the site you are >> connecting to. If, on the other hand, the site you're connecting to >> signed their own certificate themselves, then you have no way of knowing >> if they are really themselves because nobody outside of the 2-party >> connection is validating that the system you're taking to today is the >> same system you were talking to yesterday. > > Thanks very much for your explanation, > which throws some light on the subject. > > What I still find a little puzzling is that > "fetchmail --sslcertck imap.maths.tcd.ie" > tells me the SSL connection failed, > yet "fetchmail imap.maths.tcd.ie" seems to work. > > Also, I'm not clear if SSL will look at all the crt's > in /etc/pki/tls/certs , or just ca-bundle.crt? > --sslcertck is a switch that specifically demands certificate checking, and by strict standards a self-signed certificate is no good. The logic being that while technically nobody between you and the system you are directly connecting to can read your traffic, you have no guarantee that the system you're connecting to is authentic or is an imposter executing a man-in-the-middle attack. Most attacks involve silently passing traffic through anyway, so there is no way to arouse the suspicions of the victims, because they really do connect to their mail account (or whatever resource) and things function correctly. So --sslcertck is doing its job, denying you a chance at getting cracked. On the other hand you'll probably have no trouble connecting using "fetchmail --ssl imap.maths.tcd.ie" because it merely requires that some form of SSL connection be used, but doesn't care about authenication (which is worthless from a security perspective). It also permits a few other things considered simply not good enough, and should be avoided. The canonically "correct" way to use this is: "fetchmail --sslproto 'SSL3' --sslcertck hostname.domain" This forces tuse of SSL3, as SSL2 isn't considered good enough anymore, and requires a correct certificate that is signed by a certificate authority (someone with a root certificate, which can be your university's systems operator if he knows what he' about). As far as certs in /etc/pki/tls/certs/ ... Yes, they are all read. Anything with the extension .crt or .pem (and if .pem it needs to actually be in pem format, which is not always the case) will be scanned and cached by the system. Internally my company has a private root CA, and we just add our certificates as separate files in the directory -- and LDAP, websites, email, etc work just fine. Its actually pretty easy once you learn a bit about what's going on. The hard part is developing an initial understanding of how certificates are interpreted and managed -- and where insecurity in the system can arise. Key and certificate management is, in fact, the hardest part of staying cryptographically secure at the present time. Unfortunately this seems to be too much trouble for most large system administrators, even at enormously connected places like universities, so it just gets ignored and MitM attacks are more commonplace than most people realise. The effects of such are generally minimal enough that most people don't even know they've been snooped, however, which is a testament to how unimportant most of our private data/lives really are anyway. BTW, Merry Christmas, list.