ok need some more info but in general ssl setup should be as follows.

FQHN - do have have proper dns reverses setup? - this is an upstream thing

for example :

forwards :

## nslookup mail18.scom.ca Server: 10.220.0.2 Address: 10.220.0.2#53

Name: mail18.scom.ca Address: 65.39.148.18

reverses :

## nslookup 65.39.148.18 18.148.39.65.in-addr.arpa name = sogo.scom.ca. 18.148.39.65.in-addr.arpa name = mail18.scom.ca. 18.148.39.65.in-addr.arpa name = ns2.scom.ca. 18.148.39.65.in-addr.arpa name = mail.scom.ca.

Authoritative answers can be found from:

it needs to be understood that the reverses are usually returned by your upstream isp and should be set accordingly, ie you will have to get them to program them.

if you note above you can have several mappings for reverses

next ssl rewriting (other then sni) does simply not work so well.

also you should have a static ip (assuming you do)

mail18 is in my reverse so this error wont be thrown.

also note the server name (mail18.scom.ca) for both dovecot and postfix MUST match the certificate and dns for all to work.

ssl when running a masil server should be setup with a proper ceretificate (i use a wildcard for mine), proper forwards and proper reverses. Lets Encrypt (free ssl) is not a stable way to go on a busy server. You can typically get an ssl cert (proper one) for 10~20 us? pending on the provider of the cert.

also note this has to be setup properly on postfix as well as that to could throw a FQHN error if they are connecting to port 25/465/587 as well.

My ssl config (example) - please note i run sni for multiple domains and certs

i typically run with the dovecot defaults under 2.3.18 and it seems to work ok.

# cat sni.conf #sni.conf ssl = yes verbose_ssl = yes ssl_dh =

#Default *.scom.ca ssl_key =

local_name .scom.ca { ssl_key = /programs/common/getssl.cert -c *.scom.ca -q yes ssl_cert = /programs/common/getssl.cert -c *.scom.ca -q yes ssl_ca = /programs/common/getssl.cert -c *.scom.ca -q yes }

local_name mail.clancyca.com { ssl_key = /programs/common/getssl.cert -c mail.clancyca.com -q yes ssl_cert = /programs/common/getssl.cert -c mail.clancyca.com -q yes ssl_ca = /programs/common/getssl.cert -c mail.clancyca.com -q yes }

local_name secure.clancyca.com { ssl_key = /programs/common/getssl.cert -c secure.clancyca.com -q yes ssl_cert = /programs/common/getssl.cert -c secure.clancyca.com -q yes ssl_ca = /programs/common/getssl.cert -c secure.clancyca.com -q yes }

local_name mail.paulkudla.net { ssl_key = /programs/common/getssl.cert -c mail.paulkudla.net -q yes ssl_cert = /programs/common/getssl.cert -c mail.paulkudla.net -q yes ssl_ca = /programs/common/getssl.cert -c mail.paulkudla.net -q yes }

local_name mail.ekst.ca { ssl_key = /programs/common/getssl.cert -c mail.ekst.ca -q yes ssl_cert = /programs/common/getssl.cert -c mail.ekst.ca -q yes ssl_ca = /programs/common/getssl.cert -c mail.ekst.ca -q yes }

local_name mail.hamletdevelopments.ca { ssl_key = /programs/common/getssl.cert -c mail.hamletdevelopments.ca -q yes ssl_cert = /programs/common/getssl.cert -c mail.hamletdevelopments.ca -q yes ssl_ca = /programs/common/getssl.cert -c mail.hamletdevelopments.ca -q yes }

Happy Monday !!! Thanks - paul

Paul Kudla

Scom.ca Internet Services http://www.scom.ca 004-1009 Byron Street South Whitby, Ontario - Canada L1N 4S3

Toronto 416.642.7266 Main 1.866.411.7266 Fax 1.888.892.7266

On 5/13/2022 10:38 PM, Elisamuel Resto wrote:

On 2022-05-13 5:02 pm, Greg Earle wrote:

...

Hello,

At work I'm running a Dovecot 2.3.15 server on a RHEL 7.9 system with OpenSSL 1.0.2k.

Our IT Security people are threatening to shut it down because of this:

...

We were notified of a possible TLS renegotiation vulnerability on [FQHN].

[Parent organization] ticket NNNNNNN is open to track efforts.

We conducted a manual test on the site for TLS Renegotiation on IMAP port 993.

We found that this was set to enabled.

In order to remediate we will need to either:

 1. Disable Renegotiation (preferred) 2. Set a max aggregated renegotiation

Please remediate as soon as possible.

References:

https://support.f5.com/csp/article/K15278

https://nvd.nist.gov/vuln/detail/cve-2011-1473

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1473

I did some Googling and among the results, I found a few old posts from this mailing list among them, which to summarize basically seemed to say "Yeah, we could write some code ... " but that was about it.

The IT Security rep sent me a reference to an ancient Red Hat article

https://access.redhat.com/articles/23543

which is hysterical - ancient history, references NSS and Tomcat, suggests changes to an add-on product (Red Hat Certificate Server) that is EOL, etc.

Is there any way to mitigate this issue?

(The only thing I can think of is to upgrade the Dovecot server to RHEL 8 and restrict connections to only TLSv1.3, but that ain't gonna happen overnight.)

Thanks,

        - Greg

Greg,

I believe this to be a configuration error, not a dovecot problem. The output of dovecot -n (as an attachment; look it over for any data you do not want publicized) would help to suggest changes to bring you back into compliance.

Regards, Elisamuel Resto