- Edited
Hi all,
Can the mailcow-dockerized be install in another location? Like /opt/mailcow-dockerized to /var/lib/docker/compose/mailcow. I am having some tls issues. I am not sure if that is the cause.
English
Hi all,
Can the mailcow-dockerized be install in another location? Like /opt/mailcow-dockerized to /var/lib/docker/compose/mailcow. I am having some tls issues. I am not sure if that is the cause.
Have something to say?
Join the community by quickly registering to participate in this discussion. We'd like to see you joining our great moo-community!
The directory where the stack is installed has absolutely nothing to do with TLS
Maybe try describing your problem in detail
Hi all,
I too found nothing in the documentation that mentions installation to other than /opt is not recommended so I believe it should be fine. Mailcow is working fine for clients on the newer machines (OS). We have an Oracle servers which can only work on TLS 1.1. I am planning to have the Oracle servers to send and receive emails using the Mailcow since we have moved the company emails to M365 which only accept TLS1.2 with some SMTP-AUTH requirements (mentioned by the MIS Team). I am having issues when connecting one of the Oracle server to Mailcow. When I tested the connection from another linux box using Openssl command line (openssl s_client -connect server:993 -tls1_1), I am getting error “no peer certificate available”. My certificate is from LetsEncrypt. When I try the same command but point to port 443, it works fine. I do not the certificate error.
Hi DocFraggle,
I have enabled it at Postfix extra.cf and Dovecot extra.cf using the same documentation.
Why don’t you install a simple Postfix on your Oracle servers which sends emails to a configured relay server? We did it this way at our company.
Why would you want to install a full groupware stack just for Oracle servers to be able to send mails in the first place?
But the MIS Team refuses that method saying Oracle is mission critical for the company and changing anything to it may cause issue bla bla bla …….. Since we used to provide that service (On premise Exchange), my team should provide same method alternatives. Therefore I will not go down that path except for providing the alternative to my on premise exchange.
When I ran the command “openssl s_client -starttls imap -connect mailserver:143 | openssl x509 -noout -text”, I got the error below. Is there anything wrong with my setting? There is no issue when checking with port 587 and 443.
write:errno=104
unable to load certificate
140653554096016:error:0906D06CEM routines
EM_read_bio:no start line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE
Below is the result when I query the certificate expiry date.
echo | openssl s_client -connect mailserver:143 -starttls imap 2>/dev/null | openssl x509 -inform pem -noout -enddate | cut -d “=” -f 2
unable to load certificate
140126333908880:error:0906D06CEM routines
EM_read_bio:no start line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE
Below is the result when I query the certificate expiry date.
echo | openssl s_client -connect mailserver:143 -starttls imap 2>/dev/null | openssl x509 -inform pem -noout -enddate | cut -d "=" -f 2
unable to load certificate
140126333908880:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE
Below is the result when I query the certificate expiry date.
echo | openssl s_client -connect mailserver:143 -starttls imap 2>/dev/null | openssl x509 -inform pem -noout -enddate | cut -d "=" -f 2
unable to load certificate
140126333908880:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE
Below is the result when I query the certificate expiry date.
echo | openssl s_client -connect mailserver:143 -starttls imap 2>/dev/null | openssl x509 -inform pem -noout -enddate | cut -d “=” -f 2
unable to load certificate
140126333908880:error:0906D06CEM routines
EM_read_bio:no start line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE
I got the same error when I query the certificate expiry date.
echo | openssl s_client -connect mailserver:587 -starttls smtp 2>/dev/null | openssl x509 -inform pem -noout -enddate | cut -d “=” -f 2
I got the same error when I query the certificate expiry date.
echo | openssl s_client -connect mailserver:587 -starttls smtp 2>/dev/null | openssl x509 -inform pem -noout -enddate | cut -d “=” -f 2
a
Something went wrong in my earlier entry. Checking on how to edit it
Question 1: why are you trying to connect to IMAP? IMAP is for receiving mail with an IMAP client. I thought you want to send mail? Try port 25 of your mailcow
Question 2: which OS are you running your Oracle databases on? We use RedHat, installed the Postfix package, configured it to use Exchange as relay and Oracle is sending mails via localhost:25
For question 1, that was how the communication was made to the old on premise exchange. I will confirm this again.
For question 2, they are using unix.
Oracle will send out approval email where the department head will respond. Oracle will the check the emails in the mailbox for the approvals and proceed with the next process.
I am getting this error in Dovecot;
dovecot-mailcow-1 | Sep 24 08:24:34 ad03f9862894 dovecot: master: Dovecot v2.3.21.1 (d492236fa0) starting up for imap, sieve, lmtp, pop3
dovecot-mailcow-1 | Sep 24 08:24:34 ad03f9862894 dovecot: doveadm: Error: SSL context initialization failed, disabling SSL: Can’t set cipher list to ‘ALL:!ADH:!LOW:!SSLv2:!!SSLv3:!EXP:!aNULL:!3DES:!MD5:!PSK:!DSS:!RC4:!SEED:!IDEA:+HIGH:+MEDIUM’ (ssl_cipher_list setting): error:0A000118:SSL routines::invalid command
dovecot-mailcow-1 | 2024-09-24 08:24:35,239 INFO success: processes entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
dovecot-mailcow-1 | 2024-09-24 08:24:35,239 INFO success: dovecot entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
dovecot-mailcow-1 | 2024-09-24 08:24:35,239 INFO success: syslog-ng entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
OK, I know what the “problem” is:
71f2e63f09c1:/# openssl version
OpenSSL 3.3.1 4 Jun 2024 (Library: OpenSSL 3.3.1 4 Jun 2024)
The dovecot container (and the postfix container as well) are using OpenSSL version 3. TLS 1.0 and 1.1 support has been removed completely. So unfortunately no chance for you to use TLS 1.0 and 1.1 with mailcow
@DerLinkman @pkernstock I think it would be best to add a note or completely remove the page at
Thank you for the update. Is there an older version of mailcow that supports TLS 1.1 I can fallback to?
On a side note, smtp over port 465 works fine though. Only imap over port 143 has issue.
DocFraggle Were did you read that?
@Azard What are your dovecot settings?
Did you modified dovecot’s extra.cf? The error is coming during boot. That is not a “normal” behaviour
DerLinkman Were did you read that?
I have to rephrase, it wasn’t removed completely, but:
SSL 3, TLS 1.0, TLS 1.1, and DTLS 1.0 only work at security level 0, except when RSA key exchange without SHA1 is used.
You need to switch to security level 0 by editing the openssl.cnf file like described here:
But I didn’t test it. A fact is, that without adjusting the OpenSSL config, you can’t enable TLS 1.0 and 1.1 just by editing the extra.conf files as described in with the current containers which use Openssl 3.x
DocFraggle You can. For me it works…
DerLinkman not working with my dovecot container:
3f7553eb96e7:/# doveadm config get ssl_min_protocol
ssl_min_protocol = TLSv1
3f7553eb96e7:/# openssl s_client -connect 127.0.0.1:993 -tls1_1 -brief
Connecting to 127.0.0.1
28FBC15DEB7F0000:error:0A0000BF:SSL routines:tls_setup_handshake:no protocols available:ssl/statem/statem_lib.c:153:
while trying TLS 1.2 works as expected
3f7553eb96e7:/# openssl s_client -connect 127.0.0.1:993 -tls1_2 -brief
Connecting to 127.0.0.1
Can't use SSL_get_servername
CONNECTION ESTABLISHED
Protocol version: TLSv1.2
Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
Peer certificate: CN=mail.domain.tld
Hash used: SHA256
Signature type: RSA-PSS
Verification: OK
Supported Elliptic Curve Point Formats: uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
Server Temp Key: X25519, 253 bits
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
This really works on your mailcow instance?
EDIT: after applying this inside the dovecot container it works:
sed -i '/\[openssl_init\]/a ssl_conf = ssl_configuration' /etc/ssl/openssl.cnf
echo "[ssl_configuration]" >> /etc/ssl/openssl.cnf \
&& echo "system_default = tls_system_default" >> /etc/ssl/openssl.cnf
echo "[tls_system_default]" >> /etc/ssl/openssl.cnf \
&& echo "MinProtocol = TLSv1" >> /etc/ssl/openssl.cnf \
&& echo "CipherString = DEFAULT@SECLEVEL=0" >> /etc/ssl/openssl.cnf
Now the output is:
3f7553eb96e7:/# openssl s_client -connect 127.0.0.1:993 -tls1_1 -brief
Connecting to 127.0.0.1
Can't use SSL_get_servername
CONNECTION ESTABLISHED
Protocol version: TLSv1.1
Ciphersuite: ECDHE-RSA-AES256-SHA
Peer certificate: CN=mail.domain.tld
Hash used: MD5-SHA1
Signature type: RSA
Verification: OK
Supported Elliptic Curve Point Formats: uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
Server Temp Key: X25519, 253 bits
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
But this change isn’t persistent after updates of the container