[CentOS] Mystery of email authentication

Sat Dec 24 03:06:11 UTC 2011
夜神 岩男 <supergiantpotato at yahoo.co.jp>

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