[horde] ingo TLS certificate error problem...an update

[Vilius Sumskas/LNK]

> On 11/01/2016 03:44 PM, Andy Dorman wrote:
> > On 11/01/2016 03:26 PM, Arjen de Korte wrote:
> >>
> >> I don't see how this is ever going to work if you can't resolve the 
CN
> >> of the certificate to the IP address of the server (which in your 
case
> >> will never work). How can a client verify if the certificate a server
> >> presents is for that server, other than by checking if one of the 
Common
> >> Names matches a with the IP address of the server?
> >>
> >>> For now I suppose I will turn off tls.  That is OK since all our 
sieve
> >>> requests use a private internal network space. We will just have to
> >>> figure out a solution before we can move our IMAP servers to VMs in
> >>> remote hosts.
> >>
> >> You'll have much more to figure out, since IMAP clients will not 
trust
> >> the certificates either for the same reason above.
> >>
> >
> > Strangely enough, IMAP through our nginx proxy (which also uses the
> > mail.fanmail.com SSL certificate) does the exact same LDAP lookup to
> > direct requests to the correct IMAP host and this handles TLS just 
fine.
> >
> > Perhaps we need to adjust our webmail config to go through the nginx
> > proxy like all other external clients instead of trying to connect to
> > IMAP/Sieve direct on the correct server.
> >
> 
> Thanks Arien...you make a very good point.
> 
> So, instead of going direct to the specific server for ingo/sieve, I 
> modified our development server to use our Nginx front-end proxy just 
> like external IMAP clients do (and tls works fine for external IMAP 
> clients). Here are the updated settings in ingo/backends.local.php:
> 
> $backends['imap']['disabled'] = true;
> $backends['sieve']['disabled'] = false;
> $backends['sieve']['preferred'] = '';
> 
> $backends['sieve']['script'][Ingo::RULE_ALL]['driver'] = 'sieve';
> $backends['sieve']['script'][Ingo::RULE_ALL]['params']['utf8'] = true;
> $backends['sieve']['script'][Ingo::RULE_ALL]['params']['imapflags'] = 
true;
> $backends['sieve']['script'][Ingo::RULE_ALL]['params']['notify'] = true;
> 
> $backends['sieve']['transport'][Ingo::RULE_ALL]['driver'] = 'timsieved';
> $backends['sieve']['transport'][Ingo::RULE_ALL]['params']['hostspec'] = 
> 'mail.fanmail.com';
> $backends['sieve']['transport'][Ingo::RULE_ALL]['params']['logintype'] = 

> 'PLAIN';
> $backends['sieve']['transport'][Ingo::RULE_ALL]['params']['usetls'] = 
true;
> $backends['sieve']['transport'][Ingo::RULE_ALL]['params']['port'] = 
4190;

Does your Nginx proxy actually listens on that port? FWIW I don't think 
Nginx supports proxying of Sieve protocol.

https://lists.andrew.cmu.edu/pipermail/info-cyrus/2013-December/037112.html


> $backends['sieve']['transport'][Ingo::RULE_ALL]['params']['scriptname'] 
> = 'ingo';
> 
> Now the PHP ERROR log entry is gone and sieve filter changes work (FWIW 
> they always worked but they still do), but the user error notification 
> on the web page still pops up.
> 
> We actually see 2 notifications that seem to contradict:
> 
> - Changes saved.
> - Script not updated: There was an error activating the script. The 
> driver said: Connection refused.

Changes get saved to local Horde store (cache), but they are not sent to 
sieve probably.
 
> I am NOT a PHP expert, but I am going to do some code diving and see if 
> I can figure out what is causing the error notification even when 
> everything works.  Since this is not happening to anyone else there must 

> be something else I am missing in my configuration.
> 
> Again, this is a Debian setup with Horde Groupware Webmail Edition 
> 5.2.16 (Horde 5.2.12, Imp 6.2.16 & Ingo 3.2.12), Cyrus IMAP 2.5.10 and 
> PHP 5.6.26.

-- 
   Vilius