On 12/24/2011 11:34 AM, Timothy Murphy 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!) > ------------------------------------ > > I should say that everything runs fine on a CentOS-5.7 server, > and as far as I can see the setup on the new server is the same. > Under CentOS-5.7 I don't get the same warning: > ------------------------------------ > [tim at helen ~]$ fetchmail imap.maths.tcd.ie > fetchmail: No mail for tim at imap.maths.tcd.ie > ------------------------------------ > > 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 at maths.tcd.ie) 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) > ------------------------------------ > That is on the new server. > On the old server (where the fetchmail command works) > I get much the same warning, though briefer. > ------------------------------------ > [tim at helen ~]$ fetchmail --sslcertck imap.maths.tcd.ie > fetchmail: Server certificate verification error: self signed certificate > 11316:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate > verify failed:s3_clnt.c:915: > fetchmail: SSL connection failed. > fetchmail: socket error while fetching from tim at imap.maths.tcd.ie > fetchmail: Query status=2 (SOCKET) > ------------------------------------ > > I must admit I've never been very clear on SSL authentication 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. Deeper explanation is beyond an email list, but suffice to say the warnings are accurate. As for "how does a third party verify a certificate without a simultaneous connection in the session?" just don't worry about it. Its magic. It will remain magical until you do a lot of reading about exactly how the algorithms act as (nearly) one-way functions. The proper solution to this situation would be for whoever Lord Sysop is at your school to generate a real root certificate for the school and place it somewhere for download so that everyone can include it in their public certificate packs in browsers and email programs (check `less /etc/pki/tls/certs/ca-bundle.crt` or something similar to see the standard bundle). Then Lord Sysop can sign the certificates of all the school's official servers and users can rest reasonably well assured that they are really talking to actual school servers -- so long as the private part of the key used to generate the root certificate remains secret and NOT available for download (I've seen things done horribly wrong before, so its worth mentioning...).