configuring Dovecot with wforced and auth_policy_server_url with https results in assertion failed

[Aki Tuomi]

On 28.3.2019 22.34, Robert Kudyba via dovecot wrote:
>>>>> Set
>>>>>
>>>>> ssl_client_ca_file=/path/to/cacert.pem to validate the certificate 
>>>>
>>>> Can this be the Lets Encrypt cert that we already have? In other
>>>> words we have:
>>>> ssl_cert = </etc/pki/dovecot/certs/dovecot.pem
>>>> ssl_key = </etc/pki/dovecot/private/dovecot.pem
>>>>
>>>> Can those be used?
>>>
>>> Set it to *CA* cert. You can also use
>>>
>>> ssl_client_ca_file=/etc/pki/tls/ca-bundle crt (on centos) 
>
> OK did that.
>
>>> ssl_client_ca_dir=/etc/ssl/certs (on debian based)
>>>>> Are you using haproxy or something in front of dovecot?
>>>>
>>>> No. Just Squirrelmail webmail with sendmail.
>>>>
>>> Maybe squirrelmail supports forwarding original client ip with ID
>>> command. Otherwise dovecot cannot know it. Or you could configure
>>> squirrelmail to use weakforced ?
>
> I see some options
> in http://squirrelmail.org/docs/admin/admin-5.html#ss5.3. Would it be
> a plugin?
>
>> Also check that auth_policy_request_attributes use %{rip} and not
>> %{real_rip}. You can see this with 
>>
>> `doveconf auth_policy_request_attributes`
>
> Yes I’ve confirmed it matches. Still getting the URL or IP of the
> webmail address as well as errors like SSL handshake to
> ex.ter.na.lip:8084 failed: Connection closed
>
> Mar 28 16:13:36 auth: Debug: http-client[1]: queue
> https://ourdomain:8084: Timeout (now: 2019-03-28 16:13:36.300)
> Mar 28 16:13:36 auth: Debug: http-client[1]: queue
> https://ourdomain:8084: Absolute timeout expired for request [Req10:
> POST https://ourdomain:8084/?command=allow] (Request queued 2.002 secs
> ago, not yet sent, 0.000 in other ioloops)
> Mar 28 16:13:36 auth: Debug: http-client[1]: request [Req10: POST
> https://ourdomain:8084/?command=allow]: Error: 9008 Absolute request
> timeout expired (Request queued 2.002 secs ago, not yet sent, 0.000 in
> other ioloops)
> Mar 28 16:13:36 auth: Debug: http-client[1]: queue
> https://ourdomain:8084: Dropping request [Req10: POST
> https://ourdomain:8084/?command=allow]
> Mar 28 16:13:36 auth: Error: policy(abc,127.0.0.1,<5aBSMC2FROF/AAAB>):
> Policy server HTTP error: Absolute request timeout expired (Request
> queued 2.002 secs ago, not yet sent, 0.000 in other ioloops)
> Mar 28 16:13:36 auth: Debug: http-client[1]: request [Req10: POST
> https://ourdomain:8084/?command=allow]: Destroy (requests left=1)
> Mar 28 16:13:36 auth: Debug: http-client[1]: request [Req10: POST
> https://ourdomain:8084/?command=allow]: Free (requests left=0)
> Mar 28 16:13:36 auth-worker(32249): Debug:
> pam(abc,127.0.0.1,<5aBSMC2FROF/AAAB>): lookup service=dovecot
> Mar 28 16:13:36 auth-worker(32249): Debug:
> pam(abc,127.0.0.1,<5aBSMC2FROF/AAAB>): #1/1 style=1 msg=Password: 
> Mar 28 16:13:38 auth-worker(32249): Info:
> pam(abc,127.0.0.1,<5aBSMC2FROF/AAAB>): unknown user
> Mar 28 16:13:38 auth: Debug: policy(abc,127.0.0.1,<5aBSMC2FROF/AAAB>):
> Policy request https://ourdomain:8084/?command=report
> Mar 28 16:13:38 auth: Debug: policy(abc,127.0.0.1,<5aBSMC2FROF/AAAB>):
> Policy server request JSON:
> {"device_id":"","login":"abc","protocol":"imap","pwhash":"00","remote":"127.0.0.1","success":false,"policy_reject":false,"tls":false}
>

Well, as I said, it's up to squirrelmail to actually provide the real
client IP. Otherwise dovecot cannot know it. You can try turning on imap
rawlogs (see https://wiki.dovecot.org/Debugging/Rawlog) and check if
squirrelmail is forwarding client ip or not.

Aki


Aki

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dovecot.org/pipermail/dovecot/attachments/20190329/b6766abd/attachment-0001.html>