Re: [fetchmail-users] Server certificate verification error: self signed certificate

[Chris <cpo...@em...>]

On Tue, 2010-08-24 at 19:28 +0200, Matthias Andree wrote:
> Am 23.08.2010 08:01, schrieb Rob MacGregor:
> > On Sun, Aug 22, 2010 at 23:25, Chris <cpo...@em...> wrote:
> >> I've upgraded this morning from fetchmail 6.3.9 to 6.3.17 and noticed a 
> >> change in the logging entries:
> > <---SNIP--->
> >> Though this doesn't prevent mail from being picked up is there a way I can 
> >> get the new certificate? The domain belongs to me however is hosted by 
> >> someone else. I've contacted the person who is hosting it for me and 
> >> hopefully he'll reply but I'd like to have a fallback way to get the cert 
> >> just in case. I currently do not have a certificate for toadnet.com in my 
> >> ~/certs/.certs folder.
> > 
> > The FAQ lists one option
> > (http://fetchmail.berlios.de/fetchmail-FAQ.html#K5). I've also used the
> > following to get the certificate:
> > 
> > openssl s_client -connect remote.server.net:993 </dev/null | sed -ne
> > '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
> >> /my/ssl/path/remote.server.net.pem && c_rehash
> > 
> > You'll possibly want to use the servers correct name too 
> > (linuxsrv01.usdcservers.net) to avoid the warning about the mis-match.
> 
> Chris, Rob,
> 
> I'm sorry to contradict:
> 
> A. what you propose, extracting the server's certificate and marking it
> trusted (by dropping it into the certs/ directory), is an *insecure
> practice.* It is also inefficient for maintenance because server
> certificates usually expire quicker than the signing CAs' certificates.
> 
> It is also an *insecure practice* to look at the fingerprint in -v mode
> and record it, *unless* you have verified the fingerprint through a
> separate, secure channel.
> 
> Reason: If the download is under attack, the whole setup will be
> insecure for the time being and you will only know after the
> man-in-the-middle attack has ended.
> 
> The certificate needs to be downloaded through a secure link, or at
> least the fingerprints verified over a distinct channel.
> 
> 
> B. the names of the .pem files in the /path-to/ssl/certs/ are irrelevant
> and only used for human convenience to ease maintenance of the directory.
>   OpenSSL uses the hash symlinks generated by c_rehash (such as
> 21337432.0) to look up the certificates, and uses the common name and
> subject alternative names from within the certificate.
> 
> 
> The recent README.SSL
> <http://gitorious.org/fetchmail/fetchmail/blobs/master/README.SSL>
> explains a bit more, and the short version is:
> 
> 0. in this particular case only: have a new certificate issued with the
> server's DNS as its common name or subject alternative name
> 
> 1. get the CA certificate that was used to sign the server's certificate
> and drop it into /etc/ssl/certs (or wherever your OpenSSL keeps that),
> or append it (in PEM format) to /etc/ssl/cert.pem (or wherever your
> OpenSSL keeps that).  If you want to keep these separate, the
> --sslcertfile and --sslcertpath options are at your service.
> 
> 2. if it's a separate file in the certs directory, or you're using
> --sslcertpath, run c_rehash on the same directory (c_rehash /etc/ssl/certs)
> 
> Hope that helps.
> 
> Best regards
> Matthias
I believe I understand now Matthias, bottom line I can't be positively
sure that the sslfingerprint I have or the certificate I downloaded
actually belongs to either my domain or to the server it's being hosted
on without verifying it with a CA. Checking for certificates at
http://www.sslshopper.com/ssl-checker.html?host=toadnet.com#hostname=toadnet.com

I see:

	
toadnet.com resolves to 208.78.40.140
 	
Server Type: Apache/2.2.15 (Unix) mod_ssl/2.2.15
OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4 mod_perl/2.0.4 Perl/v5.8.8
 	
There was an unknown error verifying the certificate:
 	
This certificate has expired (14847 days ago). Renew now.
 	
None of the common names in the certificate match the name that was
entered (toadnet.com). You may receive an error when accessing this site
in a web browser. Learn more about name mismatch errors.

The same for linuxsrv01.usdcservers.net which is where it's hosted.
Since it's now reported in the fetchmail log that it's a self-signed
certificate I really have my doubts that the days since expiration, 40+
years is at all correct. I've emailed the person who hosts my domain but
in case he doesn't get back to me what options do I have?

Chris


-- 
Chris
KeyID 0xE372A7DA98E6705C