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

[Andy Dorman]

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;
$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.

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.

-- 
Andy Dorman