[horde] ingo TLS certificate error problem...working for now

[Andy Dorman]

On 11/02/2016 09:51 AM, Vilius Sumskas/LNK wrote:
>> 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.
>

Good catch Vilius.  You are correct that Nginx does not listen on port 
4190 and it looks like it will not support the sieve traffic. I feel 
like a real dummy.

I have reverted my backend config to go direct to the server and 
disabled tls.  This is currently not a security issue since all sieve 
traffic is on the cluster local network.  Now the user does not get an 
error and PHP is happy.

However, if we ever want to move our webmail service to a VM outside our 
local net we will either have to figure out how to tell sieve to use a 
certificate for the hostname or tell PHP to accept the service 
certificate instead of the hostname certificate.

Thank you everyone for your help and suggestions.

-- 
Andy Dorman