Bug 48448 - Make --notlsverify flag configurable for sieve-connect function in Dovecot listener
Make --notlsverify flag configurable for sieve-connect function in Dovecot li...
Status: CLOSED WONTFIX
Product: UCS
Classification: Unclassified
Component: Mail
UCS 4.3
Other Linux
: P5 normal (vote)
: ---
Assigned To: Sönke Schwardt-Krummrich
Daniel Tröder
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-01-11 13:38 CET by Valentin Heidelberger
Modified: 2023-03-25 06:48 CET (History)
4 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 5: Major Usability: Impairs usability in key scenarios
Who will be affected by this bug?: 3: Will affect average number of installed domains
How will those affected feel about the bug?: 3: A User would likely not purchase the product
User Pain: 0.257
Enterprise Customer affected?:
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Valentin Heidelberger univentionstaff 2019-01-11 13:38:24 CET
(As requested in bug 38805) the Dovecot listener passes various flags to sieve-connect to verify the TLS certificate served by Dovecot. 

In a customer's domain this resulted in the following problem:

- Dovecot is configured to use Let's Encrypt certificates for an external domain name
- From this external domain name port 4190 (Sieve) is not reachable

-> sieve-connect fails to verify the certificate if it connects to the internal domain name and fails to connect to the external domain name because the port is closed.

sieve-connect has the flag --notlsverify. It would be nice if there was a UCR variable to make the listener use that flag in setups configured as described above. It should be set to false by default of course.
Comment 2 Daniel Tröder univentionstaff 2019-01-11 14:22:15 CET
We want to use SNI with Dovecot, so that the correct certificate would always be used. But there it could be a while, before we start working on this.
Comment 3 Valentin Heidelberger univentionstaff 2019-01-11 14:55:42 CET
(In reply to Daniel Tröder from comment #2)
> We want to use SNI with Dovecot, so that the correct certificate would
> always be used. But there it could be a while, before we start working on
> this.

That's certainly the best long-term solution.
But it'd be good to have this bug resolved as a workaround until that is implemented.
Comment 4 Sönke Schwardt-Krummrich univentionstaff 2019-01-13 21:12:40 CET
@Valentin: did you have a look at bug 41018 / erratum 360?

With a LE certificate, the following settings should work:
mail/dovecot/sieve/client/cafile=/etc/ssl/certs/ca-certificates.crt
mail/dovecot/sieve/client/server=PUBLIC_FQDN_OF_LE_CERTIFICATE
Comment 5 Valentin Heidelberger univentionstaff 2019-01-14 09:56:45 CET
(In reply to Sönke Schwardt-Krummrich from comment #4)
> @Valentin: did you have a look at bug 41018 / erratum 360?
> 
> With a LE certificate, the following settings should work:
> mail/dovecot/sieve/client/cafile=/etc/ssl/certs/ca-certificates.crt
> mail/dovecot/sieve/client/server=PUBLIC_FQDN_OF_LE_CERTIFICATE

Yes I saw that erratum but unfortunately that doesn't help if, as in this case, port 4190 is not reachable from outside and one is forced to use an internal FQDN. Whether that's considered a too specific use-case I can't determine.
Comment 6 Sönke Schwardt-Krummrich univentionstaff 2019-01-17 14:51:13 CET
Bug 48485 is the better solution → WONTFIX
Comment 7 Daniel Tröder univentionstaff 2019-03-11 13:36:20 CET
OK: customer uses workaround, fix for product will be in Bug #48485.