Univention Bugzilla – Bug 48448
Make --notlsverify flag configurable for sieve-connect function in Dovecot listener
Last modified: 2023-03-25 06:48:36 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.
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.
(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.
@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
(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.
Bug 48485 is the better solution → WONTFIX
OK: customer uses workaround, fix for product will be in Bug #48485.