[horde] ingo TLS certificate error problem

[Arjen de Korte]

Citeren Andy Dorman <adorman at ironicdesign.com>:

> On 11/01/2016 10:48 AM, Arjen de Korte wrote:
>> Citeren Andy Dorman <adorman at ironicdesign.com>:
>>
>>> We have several servers that support a spam/virus filtering service
>>> and an email service of a different name.  The email filtering and
>>> email hosting services use different domain names and the server host
>>> names use a third, our company domain name.
>>>
>>> The problem happens when Ingo tries to use TLS to connect and the
>>> certificate is for the email hosting service (mail.FanMail.com) and
>>> the server name is for our company (IronicDesign.com).
>>>
>>> This causes PHP to complain as shown here
>>>
>>> HORDE: [ingo] PHP ERROR: stream_socket_enable_crypto(): Peer
>>> certificate CN=`mail.fanmail.com' did not match expected
>>> CN=`yorick.ironicdesign.com' [pid 26001 on line 1215 of
>>> "/usr/share/php/Net/Sieve.php"]
>>>
>>> and the user sees an error: "Script not updated: There was an error
>>> activating the script. The driver said: Failed to establish TLS
>>> connection"
>>>
>>> After Googling I found where I can tell PHP to not verify the peer
>>>
>>> $conf['ssl']['verify_peer'] = FALSE;
>>> $conf['ssl']['verify_peer_name'] = FALSE;
>>>
>>> OR I could possibly tell Ingo to use the mail.fanmail.com certificate?
>>>
>>> I am trying to figure out which approach will work and how to apply
>>> it. I would prefer to use ingo/backends.local.php which we already use
>>> to set the appropriate host name for a user to connect to.
>>
>> In that case, you should set the hostspec to 'mail.fanmail.com'. Of
>> course, that name should (DNS) resolve to the IP address of the server
>> where Sieve is living.
>>
>> <?php
>> $backends['imap']['disabled'] = true;
>> $backends['sieve']['disabled'] = false;
>> $backends['sieve']['transport'][Ingo::RULE_ALL]['params']['hostspec'] =
>> 'mail.fanmail.com';
>>
>> Of course, the certificate on the server should contain
>> CN='mail.fanmail.com'. TLS doesn't care about hostname greetings, the
>> verification process uses the CN in the certificate and must match the
>> (forward) DNS record of that CN (reverse is not required).
>>
>>> However, I can not find an option like these below in our current
>>> backends.local.php to tell Ingo or PHP to use the 'mail.fanmail.com'
>>> certificate.
>>>
>>> $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;
>>>
>>> I suppose a third option is to set 'usetls' to false, but I would
>>> prefer not to do that as some day we hope to move our mail servers
>>> into VMs outside our local network.
>>>
>>> Thanks for any help.
>>>
>>> --
>>> Andy Dorman
>>
> Sorry, I would love to do that, but it won't work.  We have a bunch  
> of servers that are all doing email+sieve for mail.fanmail.com users  
> and domain.
>
> When the user logs into webmail, the Imp/Ingo client does an LDAP  
> lookup (in backends.local.php) for the specific server/host that  
> contains that user's email+sieve scripts. That email+sieve server  
> (yorick.ironicdesign.com in my log line above) has to be used in the  
> hostspec so Imp and Ingo pass their requests to the correct server.
>
> So I have to set hostspec to be the physical server, but the SSL  
> certificate is for the service, mail.fanmail.com.

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.