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 =</usr/local/etc/dovecot/dh-4096.pem
ssl_prefer_server_ciphers = yes
#ssl_min_protocol = TLSv1.2
#Default *.scom.ca
ssl_key =</usr/local/etc/dovecot/scom.pem
ssl_cert =</usr/local/etc/dovecot/scom.pem
ssl_ca =</usr/local/etc/dovecot/scom.pem
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
