Hi,
thanks for the reading and the hint - you are absolutely right. I didn't know
that s_client connects despite a broken certificate chain (I'm new to this
stuff and never had to look into it that deep).
So I rechecked with openssl s_client and indeed, openssl can't verify the first
certificate either:
verify error:num=20:unable to get local issuer certificate
So the certificate chain is broken from the start.
I also used ltrace on the workaround applied earlier (save the server
certificate locally and feed it to mbsync from there), and it seems that the
authentication error might still be due to the ssl problem. At least in the
ltrace log I see some lines hinting to a broken ssl connection when mbsync is
trying to send my (encrypted) credentials to the server.
memcpy(0xe42e20, "AUTHENTICATE PLAIN GWMxMjyyxjdAa"..., 119)
= 0xe42e20
vsnprintf("2 AUTHENTICATE PLAIN GWMxMjyyxjd"..., 1024, "%d %s\r\n",
0x7ffc6075a8b8) = 123
malloc(1036)
= 0xe42ea0
memcpy(0xe42eac, "2 AUTHENTICATE PLAIN YWMxMjgyMjd"..., 123)
= 0xe42eac
time(0)
= 1481206498
free(0xe42db0)
= <void>
free(0xe52670)
= <void>
free(0xe52790)
= <void>
memchr("", '\n', 0)
= 0
SSL_write(0xe3bd70, 0xe42eac, 123, 0x7f766d4803a3)
= 123
SSL_get_error(0xe3bd70, 123, 123, 0)
= 0
free(0xe42ea0)
= <void>
SSL_pending(0xe3bd70, 0, 0, 0)
= 0
time(0)
= 1481206498
poll(0xe1cd80, 1, 0x4e20, 0xe3c550)
= 1
time(0)
= 1481206500
SSL_read(0xe3bd70, 0x7f766d4803a3, 0x185c1, 0x7f766befd550)
= 41
SSL_get_error(0xe3bd70, 41, 41, 0)
= 0
memchr("2 NO incorrect password or accou"..., '\n', 41)
= 0x7f766d4803cb
If I understand this right, this means that the problem is still server and ssl
related (broken certificate chain) and that the workaround to feed the server
certificate to mbsync locally did not work because there is something wrong
with that certificate (it can't be verified).
I also checked openssl s_client -connect with another imap server and that
connection worked out fine (also no problems syncing with that server).
I'll try to solve the certificate related problems with the server
administrator. Thank you for helping me pin down the problem.
Best,
Claus-Michael
On Thu, Dec 08, 2016 at 02:16:46PM +0100, Markus wrote:
> Am Thu, 08. Dec 16 - 13:42:29 schrieb Claus-Michael Schlesinger:
> > [...]
> >
> > 2) straced mbsync and openssl s_client -connect --> it seems to me
> > that both programs try to call the same local cert data without
> > finding anything (the two certificate both programs look for in
> > /etc/ssl/certs/ don't exist). Connection is established but mbsync
> > does not continue with the certificate chain whereas openssl does. I
> > can't quite figure out why due to lack of technical understanding on
> > my side.
> >
> > Here's the full strace output from mbsync:
> > http://dock.in-berlin.de/paste/mbsync.strace
> > from openssl s_client -connect:
> > http://dock.in-berlin.de/paste/openssl.strace
> > and a diff from these two straces:
> > http://dock.in-berlin.de/paste/diff.mbsync.openssl.strace
>
> Hi there,
>
> just a quick heads-up that may retroactively reveal your initial
> problem:
>
> The openssl stacktrace hints at the same cert error as mbsync, there are
> some verification errors
>
> write(2, "verify error:num=20:unable to ge"..., 59) = 59
> write(2, "verify error:num=21:unable to ve"..., 59) = 59
> write(1, " Verify return code: 21 (unab"..., 68) = 68
>
> Looks to me like openssl didn't like the certificate any more than
> mbsync did. Just for clarification: openssl s_client connects to the
> given hostname regardless of certificate problems. It shows the
> certificate chain and its details, so you have to read its output to
> uncover any problems with certificate validity.
>
> In case openssl s_client and mbsync both give the same validation error,
> this might be a certificate mismatch on the ssl proxy. Otherwise, please
> ignore my babbling ;-)
>
>
> HTH,
> Markus
>
> > On Thu, Dec 08, 2016 at 10:24:14AM +0100, Oswald Buddenhagen wrote:
> > > On Wed, Dec 07, 2016 at 12:11:35PM +0100, Claus-Michael Schlesinger wrote:
> > > > SSL error connecting mbox.uni-stuttgart.de (129.69.1.9:996): unable to
> > > > get local issuer certificate
> > > >
> > > > Connecting with openssl s_client still works fine.
> > > >
> > > this suggests that mbsync is for some reason using different defaults
> > > than openssl.
> > > are you sure that both link to the same libssl version? verify with ldd.
> > > other than that, you can use ltrace/strace to find out where the
> > > programs are looking for the CA certificate store.
> > >
> > > to work around the issue, you can use get-cert to fetch the proxy's
> > > certificate and put it into the CertificateFile option. this bypasses
> > > the certificate chain verification on mbsync's side.
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> _______________________________________________
> isync-devel mailing list
> isync-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/isync-devel
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
_______________________________________________
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel
