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...).