[rt-users] msmtp setup woes (continued)

[Scott Sjodin]

Ok, so I found the right certificate, but when I run a test with msmtp -a
default username at domain.com...it just hangs. Tried it with all three SSL
ports (465, 587, 25) with the same result....what happens now? I can't
troubleshoot without error messages...

Thanks for everyone's assistance so far.

On Sun, May 13, 2012 at 10:00 PM, Ram <ram0502 at gmail.com> wrote:

> > From: Scott Sjodin <scott.sjodin at gmail.com>
> > Message-ID:
> >        <
> CAAfAOiWep9ZH3MCEGGtNQ0kom4fzAa+yaJ7qrkJgKyCuoLmsCg at mail.gmail.com>
>
> > So I've got my msmtp setup (almost). It's running. I can telnet in to
> > smtp.mydomain.com 587 and 25 and send over the creds (but not with 465)
> > successfully. I can run openssl, with 465 I get the following:
> >
> >
> > openssl s_client -CApath
> > /etc/ssl/certs/Equifax_Secure_Certificate_Authority.cer -connect
> > smtp.mydomain.com:465
> >
> > Verify return code: 20 (unable to get local issuer certificate)
> >
> > When testing msmtp -a default username at domain.com I get the following
> > results (with port numbers corresponding to changes in the msmtprc file)
> >
> >
> > When I change up the port number to 587:
> >
> > msmtp: TLS certificate verification failed: the certificate is not
> trusted
> > When I change up the port number to 25:
> > msmtp: TLS certificate verification failed: the certificate is not
> trusted
> > When I change up the port number to 465:
> > msmtp: network read error: Connection reset by peer.
> >
> > My msmtprc file is listed below:
> >
> > defaults
> > tls on
> > tls_starttls on
> > tls_trust_file /etc/ssl/certs/Equifax_Secure_Certificate_Authority.cer
> >
> > #this was downloaded direct from GeoTrust's website -
> > #http://www.geotrust.com/resources/root-certificates/index.html
>
> I suspect the server does not have it's certificate installed properly
> - specifically the intermediate or chain certificate is probably not
> installed/configured. Ideally this would be fixed on the server side
> but you can work around it by adding the correct chain certificate(s)
> to the client trusted certificate list.
>
> As a test try going to that same port and dump the certificates it
> offers up like so:
> # openssl s_client -connect example.com.:443
>
> You should see a section in the output like so:
> ---
> Certificate chain
>  0 s:/serialNumber=1234/C=US/O=example.com/OU=NoAuthFromUs/OU=See
> someurl/cps (c)11/OU=Domain Control Validated -
> RapidSSL(R)/CN=example.com
>   i:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
>  1 s:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
>   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
>  2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
>   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
>
>
> You should see three entries (0, 1, 2) though the names will be
> different than above. If you only see two then the the chain
> certificate is missing from the server.
>
> cheers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20120514/54461937/attachment.htm>