connection to dovecot on ports with SSL not possible

E

Erik66

Verified User
Joined
Sep 21, 2016
Messages
28
Location
Zwolle, The Netherlnads
I have used this article https://help.directadmin.com/item.php?id=629 to setup my server with a LE SSL certificate for all services. Yet, I can not connect to dovecot, neither via imap nor pop3, using a connection on any port that should use SSL. I use standard ports for dovecot and exim. The LE certificates are stored in /usr/local/directadmin/data/users/<USERNAME>/domains/<USERNAME>.cert ... etc. I even copied the contents of the .cert and .key files to /etc/exim.cert and /etc/exim.key . In the direactadmin.conf file, the parameters cacert and cakey point to the above files. carootcert points to /usr/local/directadmin/conf/bundle.crt.

Using SSLlabs checker I find the certificate at my server is actually A graded. But I assume this is because it checks port 443 and none of the ports used for email are checked here.

Does anybody have a suggestion where I could start looking for a solution?

Many thanks in advance,

Erik
 
Last edited:
It really depends on why you can't connect, i.e. the error message. Are the ports open in your firewall/iptables/csf?
You can test the connections with e.g. openssl:
Code: 
openssl s_client -connect <your hostname>:993
openssl s_client -connect <your hostname>:995
 
Last edited:
Thank you Kristian. I didn't mention but this was a working server where the firewall was setup correctly. All ports necessary are open.

I ran "openssl s_client -connect <your hostname>:993" anfd this is the result:


Code: 
[root@m01 /]# openssl s_client -connect <MYSERVERNAME>:993
CONNECTED(00000003)
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = <MYSERVERNAME>
verify return:1
---
Certificate chain
 0 s:/CN=<MYSERVERNAME>
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGMDCCBRigAwIBAgISAx9KEZPv42jF8XplnRaauSutMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTA2MjEwMjA0MjhaFw0yMTA5MTkwMjA0MjdaMCAxHjAcBgNVBAMT
FW0wMS5tYXN0ZXJzb2ZtZWRpYS5ubDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCC
AgoCggIBALVm9mlyBZSQMRtC6B1FS5kFxyZWes8JdRMBdgVxdDHgzUiacd4xUv+c
ys9m56a55q1Hx/IdGaNKJ/Qi3NWMmE+cvqElh/QnOgoi+19kEPBt8fTGObFl6gm/
Aicxw5comwB4et8Yzp1qEEpau6fhkXxB8Zr2hTXZYv2z2oCkq6TPHY8nDYqD2nCT
ytjYu5YBCnAz0OBZ+HZadfMn/gsdHOwAln/+EguVRlw9JpBGkxDpkBmJUHlKLoWe
X/FNSlr1EoiWbGgrEhG9daGFDZa7GqeVpRTjJX3+0UZfWg0VCGMw/E9rFffT4fhO
UDL0D+slxh7a27ldA5pTu7KSW777eXnK7vsuk5gSzZ3roJoj90jKDQzXt8hXIJYu
Du9jdiR54AbVbJgzcly3DWuB1Jmd3pNZ+Oc/qgf1KKpvrqGbr5OEndRrYJiKar/3
LS2ChxuDFcDTL7faN10JFqYXGlX4+zTH/wTPFPhXO+qd3tCE7P0gSr4LDRREbg6m
KQDbsFu0KbQDG9kRKbn3CGXSpCxXkU6fC0y8KPu5WQqj08+tTD2JgrhWlvo1GtMp
BUzpf0y6FecvA3RKbGyXXpqKIcc484Rn9GjrYzXgr4TOVob12tW3IRGXBGySru0v
EC2KOXf5zA7JEKKru9KFLS7XYwyAWPd9LG17OTiQMEbJvYrLj+jHAgMBAAGjggJQ
MIICTDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUF
BwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFIM22Gv0i8M8JmvQmDw0/BtjmktE
MB8GA1UdIwQYMBaAFBQusxe3WFbLrlAJQOYfr52LFMLGMFUGCCsGAQUFBwEBBEkw
RzAhBggrBgEFBQcwAYYVaHR0cDovL3IzLm8ubGVuY3Iub3JnMCIGCCsGAQUFBzAC
hhZodHRwOi8vcjMuaS5sZW5jci5vcmcvMCAGA1UdEQQZMBeCFW0wMS5tYXN0ZXJz
b2ZtZWRpYS5ubDBMBgNVHSAERTBDMAgGBmeBDAECATA3BgsrBgEEAYLfEwEBATAo
MCYGCCsGAQUFBwIBFhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCCAQQGCisG
AQQB1nkCBAIEgfUEgfIA8AB2AFzcQ5L+5qtFRLFemtRW5hA3+9X6R9yhc5SyXub2
xw7KAAABeiyGyB0AAAQDAEcwRQIgdU7lFLR0FADfQxe74AXX20AeCuYslliFBLLs
OoAc+AACIQDHdEoWmzRe8jVCocN6FTm6Jvd1EHysfLwwKx6xXoRMTAB2APZclC/R
dzAiFFQYCDCUVo7jTRMZM6/fDC8gC8xO8WTjAAABeiyGyDIAAAQDAEcwRQIgYykc
tnESjwqCjRhqp0OqpfvibfUSJVUWP2giPEkmApkCIQCRPfhjxs3BWu9ilW+mwl4D
SBVM7vqQlhOhoroAeQT35TANBgkqhkiG9w0BAQsFAAOCAQEAjgm7loCktKZ7rZyO
uUK+d2CAPVyNtcosJ4OVtOsV7IGUE4WR1C6FtLmtwkseZABqnKjDLvkTH4vHZ+sH
eBqKy5CK0Ibstn8UhS7Wk5HuhMMD5T6ri6kKzkmIVuyaHjwyRztwEJ9pJWg4j8Ou
IpPJBZAWBJ/w7kAbqw0an9nlg2iptHDWC1t2/gMP86BFWczhafHiUQp6L6YpDffC
6re4kr5z1JkjE+I+kgBZGUaFyJCaD9XmO4NixKMhNpQN+fwCUC7dsa+kUDrqWKzF
xYXsZU04jHChYDF4hEXJPXyJXG5x4UA+CLlmEVl0xDzBj0Cs1QELMRnYXu/Cg9Fj
04flgw==
-----END CERTIFICATE-----
subject=/CN=<MYSERVERNAME>
issuer=/C=US/O=Let's Encrypt/CN=R3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5195 bytes and written 415 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 2398C3979279652FB71CF48AACFC43B8D87123EE56C14F5745783A5959541595
    Session-ID-ctx:
    Master-Key: F2E621E32D91EABDE3A5990AF633C36F50FFC3A6BD07F91D9BA27ABA893DC2E93AE285B3533BFC59F082562E6E6EA1FF
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 2f b5 4d af ff 06 48 42-20 56 c9 8e 1f ab ec 2d   /.M...HB V.....-
    0010 - e2 a1 bf 41 a7 93 a5 da-75 af a2 1b 15 7d 65 b5   ...A....u....}e.
    0020 - 93 9d 84 fc 21 ee 52 3d-f2 b0 fb 40 ca 12 fd ce   ....!.R=...@....
    0030 - 1b b6 45 30 c5 87 77 29-da fe 59 17 42 e2 1f 19   ..E0..w)..Y.B...
    0040 - 8b 84 e0 0a ac e4 8e c1-7b ac 57 f8 92 5f 9c 94   ........{.W.._..
    0050 - e5 b0 29 a3 73 16 a8 64-31 f2 33 61 60 43 41 f2   ..).s..d1.3a`CA.
    0060 - 89 af 0f 96 b4 ef f2 87-95 2e a2 53 62 36 c5 45   ...........Sb6.E
    0070 - 48 cd 6b b1 67 85 52 35-e8 2b 2c 53 39 5e 3e f7   H.k.g.R5.+,S9^>.
    0080 - 43 e5 d8 f2 e0 cf a7 d7-96 06 bc 98 25 ac 7c a6   C...........%.|.
    0090 - 93 f2 bd 80 77 a7 6c 1a-20 88 33 ed 91 f4 01 9b   ....w.l. .3.....

    Start Time: 1624541646
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN] Dovecot DA ready.

For good measure: all CN values reported are identical and equal to the server name.

If I try to understand this output, it looks as if a correct secure connection is made.
 
This looks good to me. This bit says the certificate and the chain was recognized and approved by openssl:

Code: 
Verify return code: 0 (ok)

And this bit is Dovecot telling you that it's ready for you to log in and start your IMAP session:

Code: 
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN] Dovecot DA ready.

So from what I can see, all is good! If there's an error, it lies somewhere else than in the actual connection.
 
Erik66 said:
Thank you Kristian. I didn't mention but this was a working server where the firewall was setup correctly. All ports necessary are open.

I ran "openssl s_client -connect <your hostname>:993" anfd this is the result:


Code: 
[root@m01 /]# openssl s_client -connect <MYSERVERNAME>:993
CONNECTED(00000003)
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = <MYSERVERNAME>
verify return:1
---
Certificate chain
 0 s:/CN=<MYSERVERNAME>
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGMDCCBRigAwIBAgISAx9KEZPv42jF8XplnRaauSutMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTA2MjEwMjA0MjhaFw0yMTA5MTkwMjA0MjdaMCAxHjAcBgNVBAMT
FW0wMS5tYXN0ZXJzb2ZtZWRpYS5ubDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCC
AgoCggIBALVm9mlyBZSQMRtC6B1FS5kFxyZWes8JdRMBdgVxdDHgzUiacd4xUv+c
ys9m56a55q1Hx/IdGaNKJ/Qi3NWMmE+cvqElh/QnOgoi+19kEPBt8fTGObFl6gm/
Aicxw5comwB4et8Yzp1qEEpau6fhkXxB8Zr2hTXZYv2z2oCkq6TPHY8nDYqD2nCT
ytjYu5YBCnAz0OBZ+HZadfMn/gsdHOwAln/+EguVRlw9JpBGkxDpkBmJUHlKLoWe
X/FNSlr1EoiWbGgrEhG9daGFDZa7GqeVpRTjJX3+0UZfWg0VCGMw/E9rFffT4fhO
UDL0D+slxh7a27ldA5pTu7KSW777eXnK7vsuk5gSzZ3roJoj90jKDQzXt8hXIJYu
Du9jdiR54AbVbJgzcly3DWuB1Jmd3pNZ+Oc/qgf1KKpvrqGbr5OEndRrYJiKar/3
LS2ChxuDFcDTL7faN10JFqYXGlX4+zTH/wTPFPhXO+qd3tCE7P0gSr4LDRREbg6m
KQDbsFu0KbQDG9kRKbn3CGXSpCxXkU6fC0y8KPu5WQqj08+tTD2JgrhWlvo1GtMp
BUzpf0y6FecvA3RKbGyXXpqKIcc484Rn9GjrYzXgr4TOVob12tW3IRGXBGySru0v
EC2KOXf5zA7JEKKru9KFLS7XYwyAWPd9LG17OTiQMEbJvYrLj+jHAgMBAAGjggJQ
MIICTDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUF
BwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFIM22Gv0i8M8JmvQmDw0/BtjmktE
MB8GA1UdIwQYMBaAFBQusxe3WFbLrlAJQOYfr52LFMLGMFUGCCsGAQUFBwEBBEkw
RzAhBggrBgEFBQcwAYYVaHR0cDovL3IzLm8ubGVuY3Iub3JnMCIGCCsGAQUFBzAC
hhZodHRwOi8vcjMuaS5sZW5jci5vcmcvMCAGA1UdEQQZMBeCFW0wMS5tYXN0ZXJz
b2ZtZWRpYS5ubDBMBgNVHSAERTBDMAgGBmeBDAECATA3BgsrBgEEAYLfEwEBATAo
MCYGCCsGAQUFBwIBFhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCCAQQGCisG
AQQB1nkCBAIEgfUEgfIA8AB2AFzcQ5L+5qtFRLFemtRW5hA3+9X6R9yhc5SyXub2
xw7KAAABeiyGyB0AAAQDAEcwRQIgdU7lFLR0FADfQxe74AXX20AeCuYslliFBLLs
OoAc+AACIQDHdEoWmzRe8jVCocN6FTm6Jvd1EHysfLwwKx6xXoRMTAB2APZclC/R
dzAiFFQYCDCUVo7jTRMZM6/fDC8gC8xO8WTjAAABeiyGyDIAAAQDAEcwRQIgYykc
tnESjwqCjRhqp0OqpfvibfUSJVUWP2giPEkmApkCIQCRPfhjxs3BWu9ilW+mwl4D
SBVM7vqQlhOhoroAeQT35TANBgkqhkiG9w0BAQsFAAOCAQEAjgm7loCktKZ7rZyO
uUK+d2CAPVyNtcosJ4OVtOsV7IGUE4WR1C6FtLmtwkseZABqnKjDLvkTH4vHZ+sH
eBqKy5CK0Ibstn8UhS7Wk5HuhMMD5T6ri6kKzkmIVuyaHjwyRztwEJ9pJWg4j8Ou
IpPJBZAWBJ/w7kAbqw0an9nlg2iptHDWC1t2/gMP86BFWczhafHiUQp6L6YpDffC
6re4kr5z1JkjE+I+kgBZGUaFyJCaD9XmO4NixKMhNpQN+fwCUC7dsa+kUDrqWKzF
xYXsZU04jHChYDF4hEXJPXyJXG5x4UA+CLlmEVl0xDzBj0Cs1QELMRnYXu/Cg9Fj
04flgw==
-----END CERTIFICATE-----
subject=/CN=<MYSERVERNAME>
issuer=/C=US/O=Let's Encrypt/CN=R3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5195 bytes and written 415 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 2398C3979279652FB71CF48AACFC43B8D87123EE56C14F5745783A5959541595
    Session-ID-ctx:
    Master-Key: F2E621E32D91EABDE3A5990AF633C36F50FFC3A6BD07F91D9BA27ABA893DC2E93AE285B3533BFC59F082562E6E6EA1FF
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 2f b5 4d af ff 06 48 42-20 56 c9 8e 1f ab ec 2d   /.M...HB V.....-
    0010 - e2 a1 bf 41 a7 93 a5 da-75 af a2 1b 15 7d 65 b5   ...A....u....}e.
    0020 - 93 9d 84 fc 21 ee 52 3d-f2 b0 fb 40 ca 12 fd ce   ....!.R=...@....
    0030 - 1b b6 45 30 c5 87 77 29-da fe 59 17 42 e2 1f 19   ..E0..w)..Y.B...
    0040 - 8b 84 e0 0a ac e4 8e c1-7b ac 57 f8 92 5f 9c 94   ........{.W.._..
    0050 - e5 b0 29 a3 73 16 a8 64-31 f2 33 61 60 43 41 f2   ..).s..d1.3a`CA.
    0060 - 89 af 0f 96 b4 ef f2 87-95 2e a2 53 62 36 c5 45   ...........Sb6.E
    0070 - 48 cd 6b b1 67 85 52 35-e8 2b 2c 53 39 5e 3e f7   H.k.g.R5.+,S9^>.
    0080 - 43 e5 d8 f2 e0 cf a7 d7-96 06 bc 98 25 ac 7c a6   C...........%.|.
    0090 - 93 f2 bd 80 77 a7 6c 1a-20 88 33 ed 91 f4 01 9b   ....w.l. .3.....

    Start Time: 1624541646
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN] Dovecot DA ready.

For good measure: all CN values reported are identical and equal to the server name.

If I try to understand this output, it looks as if a correct secure connection is made.
Click to expand...
What are the values of ssl, ssl_cert and ssl_key in 10-ssl.conf from Dovecot?
 
As far as I know the 10-ssl.conf is not used (or not anymore or at least not by default), there is an example 10-ssl.conf, so maybe there starts your problem.
Normally the /etc/dovecot/conf/ssl.conf file is used.

If you're interested, mine looks like that:
Code: 
ssl_cert = </etc/exim.cert
ssl_key = </etc/exim.key
ssl_dh = </etc/dovecot/dh.pem

ssl_min_protocol = TLSv1.2
ssl_cipher_list = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256

As you can see I don't accept the old TLSv1.0 anymore, there are settings to change that.
Exactly what is going wrong in your case?
 
Richard G said:
As far as I know the 10-ssl.conf is not used (or not anymore or at least not by default), there is an example 10-ssl.conf, so maybe there starts your problem.
Normally the /etc/dovecot/conf/ssl.conf file is used.
Click to expand...
I was wondering if it even reads the file ?

Richard G said:
ssl_cert = </etc/exim.cert
ssl_key = </etc/exim.key
ssl_dh = </etc/dovecot/dh.pem
Click to expand...
Hmm, I have that:
Code: 
ssl_cert = </etc/letsencrypt/live/mail.justman10000.de/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.justman10000.de/privkey.pem

Richard G said:
Exactly what is going wrong in your case?
Click to expand...
This error:
IMAP Error: Login failed for justman10000 against mail.justman10000.de. Could not connect to ssl://mail.justman10000.de:993: Unknown reason in /home/roundcubemail/program/lib/Roundcube/rcube_imap.php on line 211
Click to expand...
 
Justman10000 said:
Hmm, I have that:
Click to expand...
Seems wrong to me, that is non existing. Unless you have some customisations made.
I've never seen a /etc/letsencrypt directory, not on DA and not on cPanel either.

I don't know if rebuilding stuff would fix this for you, it might or at least partly.

I've found several other things which might be part of the cause of your isse.
1.) There is no existing MX record.
2.) The rDNS/PTR record, points to vps2382160.dedi.server-hosting.expert, however, the mailserver says hello on answering with mail.justman10000.de which would normally mean (not always) that mail.justman10000.de is the real hostname of the server.
If that is the case, with DA this can also cause issues, you might consider changing it to something like server.justman10000.de instead.
3.) Be sure your hostname is present, maybe best way is to add it in DNS manager as a subdomain so it will also exist in /etc/virtual and then create an SSL certificate for it too.

If all of that is fixed, you might want to rebuild exim, exim.conf, dovecot and dovecot.conf.

I'm just wondering why the /etc/letsencrypt is coming from as this is most certainly not something that DA does.
 
Richard G said:
Seems wrong to me, that is non existing. Unless you have some customisations made.
I've never seen a /etc/letsencrypt directory, not on DA and not on cPanel either.

I don't know if rebuilding stuff would fix this for you, it might or at least partly.

I've found several other things which might be part of the cause of your isse.
1.) There is no existing MX record.
2.) The rDNS/PTR record, points to vps2382160.dedi.server-hosting.expert, however, the mailserver says hello on answering with mail.justman10000.de which would normally mean (not always) that mail.justman10000.de is the real hostname of the server.
If that is the case, with DA this can also cause issues, you might consider changing it to something like server.justman10000.de instead.
3.) Be sure your hostname is present, maybe best way is to add it in DNS manager as a subdomain so it will also exist in /etc/virtual and then create an SSL certificate for it too.

If all of that is fixed, you might want to rebuild exim, exim.conf, dovecot and dovecot.conf.

I'm just wondering why the /etc/letsencrypt is coming from as this is most certainly not something that DA does.
Click to expand...
Do not use DA or cPanel! I want to send the mails via @justman10000.de... Doesn't the hostname also have to be justman10000.de?
 
Justman10000 said:
Do not use DA or cPanel!
Click to expand...
So what are you doing here on this forum then?
This is a support forum for only DA admins or resellers, not a general ICT support forum. Can't help you further then, sorry.

I can answer your last question. Hostname needs to be a FQDN, so fully qualified domain name. So justman10000.de is the domain name.
For hostname you can use normally *.justman10000.de where * is almost anything. Mostly used is things like server or mail or vps or ns1 so like server.justman10000.de or vps.justman10000.de so almost whatever you like.
 
You must log in or register to reply here.
Back
Top