[Dovecot] SSL with startssl.com certificates
I'm using Dovecot 2.2.5. I'm setting up and new IMAPS server for personal use (i.e. only me).
I have success with self-signed certificates but not with others (e.g. StartSSL.com)
With StartSSL certs:
I've been able to connect and test commands via: openssl s_client -connect imaps.unixathome.org:993
Can you configure your iPhone or Macbook to access the above?
Authentication isn't the issue. Connection is the issue.
I've been able to get Thunderbird to connect and access my mail.
However, I've been unable to get my iPhone or my Mac configured to use the same IMAP server. On the iPhone, adding the new Mail account causes the Settings app to crash on a persistently consistent basis when adding the new account. The crash occurs when connecting to the IMAPS server. Configuration never completes.
I suspect the problem is SSL because in both cases (iPhone and Mac), I see these messages I see in the logs:
*** /var/log/debug.log *** Sep 13 11:50:32 imaps dovecot: imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [166.137.84.11] Sep 13 11:50:45 imaps dovecot: auth: Debug: auth client connected (pid=31647) Sep 13 11:50:45 imaps dovecot: imap-login: Debug: SSL: where=0x10, ret=1: before/accept initialization [166.137.84.11] Sep 13 11:50:45 imaps dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: before/accept initialization [166.137.84.11] Sep 13 11:50:45 imaps dovecot: imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv2/v3 read client hello A [166.137.84.11] Sep 13 11:50:45 imaps dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client hello A [166.137.84.11] Sep 13 11:50:45 imaps dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server hello A [166.137.84.11] Sep 13 11:50:45 imaps dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write certificate A [166.137.84.11] Sep 13 11:50:45 imaps dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server done A [166.137.84.11] Sep 13 11:50:45 imaps dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data [166.137.84.11] Sep 13 11:50:45 imaps dovecot: imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [166.137.84.11]
*** /var/log/maillog *** Sep 13 11:50:46 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [166.137.84.11] Sep 13 11:50:46 imaps dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=166.137.84.11, lip=199.233.228.197, TLS handshaking: Disconnected, session=<a7AJd0LmWwCmiVQL>
/usr/local/etc/ssl/imaps.unixathome.org.crt contains only the cert issued by StartSSL /usr/local/etc/ssl/imaps.unixathome.org.nopassword.key contains a no-password key generated by myself.
Output of doveconf -n:
# 2.2.5: /usr/local/etc/dovecot/dovecot.conf # OS: FreeBSD 9.1-RELEASE-p6 amd64 auth_debug = yes auth_verbose = yes first_valid_gid = 1001 first_valid_uid = 1001 mail_debug = yes mail_location = maildir:~/Maildir mail_privileged_group = mail passdb { args = scheme=BLF-CRYPT /var/db/dovecot.users driver = passwd-file } protocols = imap service imap-login { inet_listener imap { port = 0 } inet_listener imaps { address = 199.233.228.197 } } ssl = required ssl_cert =
-- Dan Langille - http://langille.org/
On 09/13/13 07:59 AM, Dan Langille wrote:
I'm using Dovecot 2.2.5. I'm setting up and new IMAPS server for personal use (i.e. only me).
I have success with self-signed certificates but not with others (e.g. StartSSL.com)
/usr/local/etc/ssl/imaps.unixathome.org.crt contains only the cert issued by StartSSL
Maybe you are missing some of the certificate chain. http://wiki2.dovecot.org/SSL/DovecotConfiguration "Chained SSL certificates"
On 2013-09-13 09:18, Oscar del Rio wrote:
On 09/13/13 07:59 AM, Dan Langille wrote: I'm using Dovecot 2.2.5. I'm setting up and new IMAPS server for personal use (i.e. only me).
I have success with self-signed certificates but not with others (e.g. StartSSL.com)
/usr/local/etc/ssl/imaps.unixathome.org.crt contains only the cert issued by StartSSL
Maybe you are missing some of the certificate chain. http://wiki2.dovecot.org/SSL/DovecotConfiguration "Chained SSL certificates"
I tried that yesterday and it seemed to make no difference. My attempts were based on http://openssl.6102.n7.nabble.com/check-certificate-chain-in-a-pem-file-td43...
Perhaps I am doing the chain incorrectly. I just tried again. The server is now set up with the following:
I have three certs in this chain file:
cat imaps.unixathome.org.pem sub.class1.server.ca.pem ca.pem > testing.chain.pem
1 - the certificate issued by startssl for my server 2 & 3 - the PEM files for StartSSL as found at http://www.startssl.com/certs/
I am not convinced that I have the appropriate PEM files for StartSSL.
I verified the cert chain:
# openssl verify -CAfile testing.chain.pem imaps.unixathome.org.crt imaps.unixathome.org.crt: OK
When I test the connection, I see:
$ openssl s_client -connect imaps.unixathome.org:993 -quiet depth=2 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN] Dovecot ready.
Ideas?
-- Dan Langille - http://langille.org/
On 2013-09-13 10:18, Dan Langille wrote:
On 2013-09-13 09:18, Oscar del Rio wrote: On 09/13/13 07:59 AM, Dan Langille wrote: I'm using Dovecot 2.2.5. I'm setting up and new IMAPS server for personal use (i.e. only me).
I have success with self-signed certificates but not with others (e.g. StartSSL.com)
/usr/local/etc/ssl/imaps.unixathome.org.crt contains only the cert issued by StartSSL
Maybe you are missing some of the certificate chain. http://wiki2.dovecot.org/SSL/DovecotConfiguration "Chained SSL certificates"
I tried that yesterday and it seemed to make no difference. My attempts were based on http://openssl.6102.n7.nabble.com/check-certificate-chain-in-a-pem-file-td43...
Perhaps I am doing the chain incorrectly. I just tried again. The server is now set up with the following:
I have three certs in this chain file:
cat imaps.unixathome.org.pem sub.class1.server.ca.pem ca.pem > testing.chain.pem
1 - the certificate issued by startssl for my server 2 & 3 - the PEM files for StartSSL as found at http://www.startssl.com/certs/
The following test seems to indicate I have SSL configured correctly:
http://www.sslshopper.com/ssl-checker.html#hostname=imaps.unixathome.org:993
A similar test from http://www.digicert.com/help/ does not find an issue.
Even better, this test shows the certs it finds: http://certlogik.com/ssl-checker/
Not sure what to conclude yet.
On Fri, 2013-09-13 at 10:18 -0400, Dan Langille wrote:
Perhaps I am doing the chain incorrectly. I just tried again. The server is now set up with the following:
I have three certs in this chain file:
cat imaps.unixathome.org.pem sub.class1.server.ca.pem ca.pem > testing.chain.pem
1 - the certificate issued by startssl for my server 2 & 3 - the PEM files for StartSSL as found at http://www.startssl.com/certs/
That is the correct chain method, and order
$ openssl s_client -connect imaps.unixathome.org:993 -quiet depth=2 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority verify error:num=19:self signed certificate in certificate chain
Never panic about the above, it is just indicating (rightly so) you have a local certificate (the first) in your chain.
ssl_cert =
correct method, so long as the cert and key files are named correctly and in the right location.
ssl = required
Bit dangerous... and may be the cause of your problems, change to : ssl = yes
We use startssl and have many android, blackberry, and iphone users (maybe even win phone Lusers too ;) who knows) amongst desktop/laptop types and never had any problems with them using startssl
On Sep 13, 2013, at 9:55 PM, Noel Butler wrote:
On Fri, 2013-09-13 at 10:18 -0400, Dan Langille wrote:
Perhaps I am doing the chain incorrectly. I just tried again. The server is now set up with the following:
I have three certs in this chain file:
cat imaps.unixathome.org.pem sub.class1.server.ca.pem ca.pem > testing.chain.pem
1 - the certificate issued by startssl for my server 2 & 3 - the PEM files for StartSSL as found at http://www.startssl.com/certs/
That is the correct chain method, and order
$ openssl s_client -connect imaps.unixathome.org:993 -quiet depth=2 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority verify error:num=19:self signed certificate in certificate chain
Never panic about the above, it is just indicating (rightly so) you have a local certificate (the first) in your chain.
ssl_cert =
correct method, so long as the cert and key files are named correctly and in the right location.
ssl = required
Bit dangerous... and may be the cause of your problems, change to : ssl = yes
We use startssl and have many android, blackberry, and iphone users (maybe even win phone Lusers too ;) who knows) amongst desktop/laptop types and never had any problems with them using startssl
Hmmm, I tried ssl = yes. Mail.app still crashes when trying to connect.
I also try the cert bundle mentioned by Johan.
The server says:
Sep 14 19:19:22 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [173.49.195.214] Sep 14 19:19:22 imaps dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=173.49.195.214, lip=199.233.228.197, TLS handshaking: Disconnected, session=<8+862VzmPwCtMcPW>
What is this… read client certificate? There is no client certification in this config.
: doveconf -n
# 2.2.5: /usr/local/etc/dovecot/dovecot.conf
# OS: FreeBSD 9.1-RELEASE-p6 amd64
auth_debug = yes
auth_verbose = yes
first_valid_gid = 1001
first_valid_uid = 1001
mail_debug = yes
mail_location = maildir:~/Maildir
mail_privileged_group = mail
passdb {
args = scheme=BLF-CRYPT /var/db/dovecot.users
driver = passwd-file
}
protocols = imap
service imap-login {
inet_listener imap {
port = 0
}
inet_listener imaps {
address = 199.233.228.197
}
}
ssl_cert =
-- Dan Langille - http://langille.org
Are you getting asked to add an exception to the email applications certificate dialogue box?
This is an example with Thunderbird.
http://jwrr.com/content/Hostgator-Thunderbird-Email-Configuration/images/thu...
Dan
On Sat, Sep 14, 2013 at 7:21 PM, Dan Langille dan@langille.org wrote:
On Sep 13, 2013, at 9:55 PM, Noel Butler wrote:
On Fri, 2013-09-13 at 10:18 -0400, Dan Langille wrote:
Perhaps I am doing the chain incorrectly. I just tried again. The server is now set up with the following:
I have three certs in this chain file:
cat imaps.unixathome.org.pem sub.class1.server.ca.pem ca.pem > testing.chain.pem
1 - the certificate issued by startssl for my server 2 & 3 - the PEM files for StartSSL as found at http://www.startssl.com/certs/
That is the correct chain method, and order
$ openssl s_client -connect imaps.unixathome.org:993 -quiet depth=2 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority verify error:num=19:self signed certificate in certificate chain
Never panic about the above, it is just indicating (rightly so) you have a local certificate (the first) in your chain.
ssl_cert =
correct method, so long as the cert and key files are named correctly and in the right location.
ssl = required
Bit dangerous... and may be the cause of your problems, change to : ssl = yes
We use startssl and have many android, blackberry, and iphone users (maybe even win phone Lusers too ;) who knows) amongst desktop/laptop types and never had any problems with them using startssl
Hmmm, I tried ssl = yes. Mail.app still crashes when trying to connect.
I also try the cert bundle mentioned by Johan.
The server says:
Sep 14 19:19:22 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [173.49.195.214] Sep 14 19:19:22 imaps dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=173.49.195.214, lip=199.233.228.197, TLS handshaking: Disconnected, session=<8+862VzmPwCtMcPW>
What is this… read client certificate? There is no client certification in this config.
: doveconf -n # 2.2.5: /usr/local/etc/dovecot/dovecot.conf # OS: FreeBSD 9.1-RELEASE-p6 amd64 auth_debug = yes auth_verbose = yes first_valid_gid = 1001 first_valid_uid = 1001 mail_debug = yes mail_location = maildir:~/Maildir mail_privileged_group = mail passdb { args = scheme=BLF-CRYPT /var/db/dovecot.users driver = passwd-file } protocols = imap service imap-login { inet_listener imap { port = 0 } inet_listener imaps { address = 199.233.228.197 } } ssl_cert =
-- Dan Langille - http://langille.org
-- Daniel Reinhardt cryptodan@cryptodan.net http://www.cryptodan.net 301-875-7018(c) 410-455-0488(h)
On Sep 14, 2013, at 3:28 PM, Daniel Reinhardt wrote:
Are you getting asked to add an exception to the email applications certificate dialogue box?
This is an example with Thunderbird.
http://jwrr.com/content/Hostgator-Thunderbird-Email-Configuration/images/thu...
No, it never gets to that point. Mail.app crashes right after I start it.
I am able to access this IMAP server with Thunderbird.
Dan
On Sat, Sep 14, 2013 at 7:21 PM, Dan Langille dan@langille.org wrote:
On Sep 13, 2013, at 9:55 PM, Noel Butler wrote:
On Fri, 2013-09-13 at 10:18 -0400, Dan Langille wrote:
Perhaps I am doing the chain incorrectly. I just tried again. The server is now set up with the following:
I have three certs in this chain file:
cat imaps.unixathome.org.pem sub.class1.server.ca.pem ca.pem > testing.chain.pem
1 - the certificate issued by startssl for my server 2 & 3 - the PEM files for StartSSL as found at http://www.startssl.com/certs/
That is the correct chain method, and order
$ openssl s_client -connect imaps.unixathome.org:993 -quiet depth=2 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority verify error:num=19:self signed certificate in certificate chain
Never panic about the above, it is just indicating (rightly so) you have a local certificate (the first) in your chain.
ssl_cert =
correct method, so long as the cert and key files are named correctly and in the right location.
ssl = required
Bit dangerous... and may be the cause of your problems, change to : ssl = yes
We use startssl and have many android, blackberry, and iphone users (maybe even win phone Lusers too ;) who knows) amongst desktop/laptop types and never had any problems with them using startssl
Hmmm, I tried ssl = yes. Mail.app still crashes when trying to connect.
I also try the cert bundle mentioned by Johan.
The server says:
Sep 14 19:19:22 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [173.49.195.214] Sep 14 19:19:22 imaps dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=173.49.195.214, lip=199.233.228.197, TLS handshaking: Disconnected, session=<8+862VzmPwCtMcPW>
What is this… read client certificate? There is no client certification in this config.
: doveconf -n # 2.2.5: /usr/local/etc/dovecot/dovecot.conf # OS: FreeBSD 9.1-RELEASE-p6 amd64 auth_debug = yes auth_verbose = yes first_valid_gid = 1001 first_valid_uid = 1001 mail_debug = yes mail_location = maildir:~/Maildir mail_privileged_group = mail passdb { args = scheme=BLF-CRYPT /var/db/dovecot.users driver = passwd-file } protocols = imap service imap-login { inet_listener imap { port = 0 } inet_listener imaps { address = 199.233.228.197 } } ssl_cert =
-- Dan Langille - http://langille.org
-- Daniel Reinhardt cryptodan@cryptodan.net http://www.cryptodan.net 301-875-7018(c) 410-455-0488(h)
-- Dan Langille - http://langille.org
On Sat, 2013-09-14 at 15:21 -0400, Dan Langille wrote:
Hmmm, I tried ssl = yes. Mail.app still crashes when trying to connect.
Well, its likely an Apple fault, after all their implementation of pop3 has been known to be broken for many many many years, but still after all these years are incapable of finding a developer to fix it by inserting a QUIT after its done everything.
Sep 14 19:19:22 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [173.49.195.214]
What is this… read client certificate? There is no client certification in this config.
dovecot wants to know if your client wishes to authenticate using a local-to-client certificate, wouldnt focus too much on that (unless that client is trying to give a certificate that is invalid - not sure, I have never ever in 20 years, seen any client try to auth with a local certificate to a mail server)...
is this just one user? or all using apple? is it you?
Have you/they tried simply using TLS on 143? (preferred as POP3s/IMAPs has really be deprecated everywhere for some time now)
a successful TLS login appears like (and this particular user I know uses an ipad) :
Sep 15 12:09:38 imap-login: Debug: SSL: where=0x10, ret=1: before/accept initialization [101.xxxx] Sep 15 12:09:38 imap-login: Debug: SSL: where=0x2001, ret=1: before/accept initialization [101.xx] Sep 15 12:09:38 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv2/v3 read client hello A [101.xxx] Sep 15 12:09:38 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client hello A [101.xxx] Sep 15 12:09:38 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server hello A [101.xxxx] Sep 15 12:09:38 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write certificate A [101.xxxxx] Sep 15 12:09:38 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server done A [101.xxxxx] Sep 15 12:09:38 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data [101.xxxxxx] Sep 15 12:09:38 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [101.xxxx] Sep 15 12:09:38 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [101.xxx] Sep 15 12:09:45 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client key exchange A [101.xxxx] Sep 15 12:09:45 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read finished A [101.xxxxxxx] Sep 15 12:09:45 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write change cipher spec A [101.xxxx] Sep 15 12:09:45 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write finished A [101.xxxxx] Sep 15 12:09:45 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data [101.xxxxxx] Sep 15 12:09:45 imap-login: Debug: SSL: where=0x20, ret=1: SSL negotiation finished successfully [101.xxxxxx] Sep 15 12:09:45 imap-login: Debug: SSL: where=0x2002, ret=1: SSL negotiation finished successfully [101.xxxxx] Sep 15 12:09:45 imap-login: Info: Login: userx@x, method=PLAIN, rip=xxxxx, TLS
protocols = imap service imap-login { inet_listener imap { port = 0 } inet_listener imaps { address = 199.233.228.197 } }
inet_listener imap {
port = 143 <-- use it for TLS, its possiblethis is why fails as its falling back to TLS, i cant test that theory
} since we all use
android devices.
inet_listener imaps {
port = 993
}
Anyway, the fact you said thunderbird works, indicates it is not a cert issue, and I fail to see dovecot issue, have they tried another mail app?
On Sep 14, 2013, at 10:36 PM, Noel Butler wrote:
On Sat, 2013-09-14 at 15:21 -0400, Dan Langille wrote:
Hmmm, I tried ssl = yes. Mail.app still crashes when trying to connect.
Well, its likely an Apple fault, after all their implementation of pop3 has been known to be broken for many many many years, but still after all these years are incapable of finding a developer to fix it by inserting a QUIT after its done everything.
Sep 14 19:19:22 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [173.49.195.214]
What is this… read client certificate? There is no client certification in this config.
dovecot wants to know if your client wishes to authenticate using a local-to-client certificate, wouldnt focus too much on that (unless that client is trying to give a certificate that is invalid - not sure, I have never ever in 20 years, seen any client try to auth with a local certificate to a mail server)...
is this just one user? or all using apple? is it you?
It is just me (I'm my only user).
Neither my Macbook nor my iPhone can use this IMAP server.
I got a colleague to try his iPhone; same problem there too.
Have you/they tried simply using TLS on 143? (preferred as POP3s/IMAPs has really be deprecated everywhere for some time now)
For this test, I reconfigured the server to NOT use IMAPS and restarted it. Then I went to my iPhone and turned off SSL for this mail account.
That configuration works for my iPhone.
# doveconf nf -n
# 2.2.5: /usr/local/etc/dovecot/dovecot.conf
# OS: FreeBSD 9.1-RELEASE-p6 amd64
auth_debug = yes
auth_verbose = yes
disable_plaintext_auth = no
first_valid_gid = 1001
first_valid_uid = 1001
mail_debug = yes
mail_location = maildir:~/Maildir
mail_privileged_group = mail
passdb {
args = scheme=BLF-CRYPT /var/db/dovecot.users
driver = passwd-file
}
protocols = imap
service imap-login {
inet_listener imap {
address = 199.233.228.197
}
inet_listener imaps {
port = 0
}
}
userdb {
args = /var/db/dovecot.users
driver = passwd-file
}
verbose_proctitle = yes
verbose_ssl = yes
protocol imap {
imap_client_workarounds = delay-newmail tb-extra-mailbox-sep
}
Looking via tcpdump, I can see that emails are indeed being downloaded in clear text.
I suppose that's not so big an issue, given they are delivered in plain text. But it would be better
to have the IMAP connection secured.
a successful TLS login appears like (and this particular user I know uses an ipad) :
Sep 15 12:09:38 imap-login: Debug: SSL: where=0x10, ret=1: before/accept initialization [101.xxxx] Sep 15 12:09:38 imap-login: Debug: SSL: where=0x2001, ret=1: before/accept initialization [101.xx] Sep 15 12:09:38 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv2/v3 read client hello A [101.xxx] Sep 15 12:09:38 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client hello A [101.xxx] Sep 15 12:09:38 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server hello A [101.xxxx] Sep 15 12:09:38 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write certificate A [101.xxxxx] Sep 15 12:09:38 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server done A [101.xxxxx] Sep 15 12:09:38 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data [101.xxxxxx] Sep 15 12:09:38 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [101.xxxx] Sep 15 12:09:38 imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [101.xxx] Sep 15 12:09:45 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client key exchange A [101.xxxx] Sep 15 12:09:45 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read finished A [101.xxxxxxx] Sep 15 12:09:45 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write change cipher spec A [101.xxxx] Sep 15 12:09:45 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write finished A [101.xxxxx] Sep 15 12:09:45 imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data [101.xxxxxx] Sep 15 12:09:45 imap-login: Debug: SSL: where=0x20, ret=1: SSL negotiation finished successfully [101.xxxxxx] Sep 15 12:09:45 imap-login: Debug: SSL: where=0x2002, ret=1: SSL negotiation finished successfully [101.xxxxx] Sep 15 12:09:45 imap-login: Info: Login: userx@x, method=PLAIN, rip=xxxxx, TLS
protocols = imap service imap-login { inet_listener imap { port = 0 } inet_listener imaps { address = 199.233.228.197 } }
inet_listener imap { port = 143 <-- use it for TLS, its possiblethis is why fails as its falling back to TLS, i cant test that theory } since we all use android devices. inet_listener imaps { port = 993
}Anyway, the fact you said thunderbird works, indicates it is not a cert issue, and I fail to see dovecot issue, have they tried another mail app?
I have not. That's a good test… I'm searching for a free mail client to test with now…. failing...
-- Dan Langille - http://langille.org
Am 16.09.2013 16:10, schrieb Dan Langille:
Have you/they tried simply using TLS on 143? (preferred as POP3s/IMAPs has really be deprecated everywhere for some time now)
For this test, I reconfigured the server to NOT use IMAPS and restarted it. Then I went to my iPhone and turned off SSL for this mail account.
That configuration works for my iPhone.
Looking via tcpdump, I can see that emails are indeed being downloaded in clear text
you need to understand the difference between IMAPS/POP3S on the dedicated 9xx ports versus STARTLS on 143/110
http://en.wikipedia.org/wiki/STARTTLS
if you turn off SSL it is turned off on sane clients like thunderbird you can switch between cleartext/STARTTLS and SSL
On Sep 16, 2013, at 10:21 AM, Reindl Harald wrote:
Am 16.09.2013 16:10, schrieb Dan Langille:
Have you/they tried simply using TLS on 143? (preferred as POP3s/IMAPs has really be deprecated everywhere for some time now)
For this test, I reconfigured the server to NOT use IMAPS and restarted it. Then I went to my iPhone and turned off SSL for this mail account.
That configuration works for my iPhone.
Looking via tcpdump, I can see that emails are indeed being downloaded in clear text
you need to understand the difference between IMAPS/POP3S on the dedicated 9xx ports versus STARTLS on 143/110
I believe I do understand.
Yes, that's what I those STARTTLS was.
if you turn off SSL it is turned off on sane clients like thunderbird you can switch between cleartext/STARTTLS and SSL
So far, with all we've tried, the only secure option appears to be self signed certificates.
-- Dan Langille - http://langille.org
Am 16.09.2013 16:48, schrieb Dan Langille:
On Sep 16, 2013, at 10:21 AM, Reindl Harald wrote:
Am 16.09.2013 16:10, schrieb Dan Langille:
Have you/they tried simply using TLS on 143? (preferred as POP3s/IMAPs has really be deprecated everywhere for some time now)
For this test, I reconfigured the server to NOT use IMAPS and restarted it. Then I went to my iPhone and turned off SSL for this mail account.
That configuration works for my iPhone.
Looking via tcpdump, I can see that emails are indeed being downloaded in clear text
you need to understand the difference between IMAPS/POP3S on the dedicated 9xx ports versus STARTLS on 143/110
I believe I do understand.
Yes, that's what I those STARTTLS was.
if you turn off SSL it is turned off on sane clients like thunderbird you can switch between cleartext/STARTTLS and SSL
So far, with all we've tried, the only secure option appears to be self signed certificates
having like here since 2009 a Thawte certificate for SMTP/POP3/IMAP/HTTPS without any issue is the better option because it is accepted by *any* client and not *that* expensive
dealing with self-signed certificates is *plain wrong* because you educate your users happily confirm SSL warnings in their clients and having the final result of this in mind it's better not offer SSL at all
On Sep 16, 2013, at 10:56 AM, Reindl Harald wrote:
Am 16.09.2013 16:48, schrieb Dan Langille:
On Sep 16, 2013, at 10:21 AM, Reindl Harald wrote:
Am 16.09.2013 16:10, schrieb Dan Langille:
Have you/they tried simply using TLS on 143? (preferred as POP3s/IMAPs has really be deprecated everywhere for some time now)
For this test, I reconfigured the server to NOT use IMAPS and restarted it. Then I went to my iPhone and turned off SSL for this mail account.
That configuration works for my iPhone.
Looking via tcpdump, I can see that emails are indeed being downloaded in clear text
you need to understand the difference between IMAPS/POP3S on the dedicated 9xx ports versus STARTLS on 143/110
I believe I do understand.
Yes, that's what I those STARTTLS was.
if you turn off SSL it is turned off on sane clients like thunderbird you can switch between cleartext/STARTTLS and SSL
So far, with all we've tried, the only secure option appears to be self signed certificates
having like here since 2009 a Thawte certificate for SMTP/POP3/IMAP/HTTPS without any issue is the better option because it is accepted by *any* client and not *that* expensive
dealing with self-signed certificates is *plain wrong* because you educate your users happily confirm SSL warnings in their clients and having the final result of this in mind it's better not offer SSL at all
When I am setting up servers for others to use, I agree. In this case. I am the only user.
-- Dan Langille - http://langille.org
On Mon, 2013-09-16 at 10:10 -0400, Dan Langille wrote:
On Sep 14, 2013, at 10:36 PM, Noel Butler wrote:
On Sat, 2013-09-14 at 15:21 -0400, Dan Langille wrote:
Hmmm, I tried ssl = yes. Mail.app still crashes when trying to connect.
Well, its likely an Apple fault, after all their implementation of pop3 has been known to be broken for many many many years, but still after all these years are incapable of finding a developer to fix it by inserting a QUIT after its done everything.
Since we just ruled this one out, might I suggest you grab the source and build it, install it all under /opt/dovecot that way it wont interfere with your ports installation and try that, the one you successfully just tested uses dovecot 2.1 not 2.2, so maybe try source of 2.1 and see if it works.
But, if it does work on port 143 with TLS I wouldnt worry too much about it, the only place that seems to prefer it is the NSA's mail server, oops, I mean gmail, not many ISP's these days bother with it, it has been withdrawn for years since most clients can handle TLS, the better way to do it, like they dont bother with smtps either, the *s version is really only supported for those running antique versions of windows that dont understand TLS, and yes thats more micro$lops fault, just like SNI thats been available even in lynx and other older browsers/ epihany/galeon etc) since 2005ish. But M$ doesnt give a toss about its users, a very senior M$ dev on his personal blog a year or so ago wrote " they need to upgrade to windows 7 or 8" yup they only see $$$ not happy users (I posted a comment btw that went along the lines of "or mid last decade version of linux" ;)
On 2013-09-16 20:28, Noel Butler wrote:
On Mon, 2013-09-16 at 10:10 -0400, Dan Langille wrote:
On Sep 14, 2013, at 10:36 PM, Noel Butler wrote:
On Sat, 2013-09-14 at 15:21 -0400, Dan Langille wrote:
Hmmm, I tried ssl = yes. Mail.app still crashes when trying to connect.
Well, its likely an Apple fault, after all their implementation of pop3 has been known to be broken for many many many years, but still after all these years are incapable of finding a developer to fix it by inserting a QUIT after its done everything.
Since we just ruled this one out, might I suggest you grab the source and build it, install it all under /opt/dovecot that way it wont interfere with your ports installation and try that, the one you successfully just tested uses dovecot 2.1 not 2.2, so maybe try source of 2.1 and see if it works.
I just tried 2.1.16. The iPhone has no trouble on 143 but on 993, it's just like 2.2
But, if it does work on port 143 with TLS I wouldnt worry too much about it
tcpdump is showing me raw text going past, so I know I'm not getting TLS on either Dovecot 2.1 or 2.2
It seems that TLS is not supported by my client. Pity.
I thank you for your help though. We have a workaround, which is good enough for my particular situation: self-signed certificates. However, that solution is not ideal for most people. It is for that reason that I'm willing to keep hacking at this if others have further ideas / suggestions.
-- Dan Langille - http://langille.org/
Am 17.09.2013 14:39, schrieb Dan Langille:
On 2013-09-16 20:28, Noel Butler wrote:
Since we just ruled this one out, might I suggest you grab the source and build it, install it all under /opt/dovecot that way it wont interfere with your ports installation and try that, the one you successfully just tested uses dovecot 2.1 not 2.2, so maybe try source of 2.1 and see if it works.
I just tried 2.1.16. The iPhone has no trouble on 143 but on 993, it's just like 2.2
But, if it does work on port 143 with TLS I wouldnt worry too much about it
tcpdump is showing me raw text going past, so I know I'm not getting TLS on either Dovecot 2.1 or 2.2
It seems that TLS is not supported by my client. Pity.
iPhone is the worst mail client on this planet but for sure supports TLS
Apple is here the same as Microsoft
- remove the account completly
- add it again and it will detect that encryption is available
On 2013-09-17 08:43, Reindl Harald wrote:
Am 17.09.2013 14:39, schrieb Dan Langille: On 2013-09-16 20:28, Noel Butler wrote: Since we just ruled this one out, might I suggest you grab the source and build it, install it all under /opt/dovecot that way it wont interfere with your ports installation and try that, the one you successfully just tested uses dovecot 2.1 not 2.2, so maybe try source of 2.1 and see if it works.
I just tried 2.1.16. The iPhone has no trouble on 143 but on 993, it's just like 2.2
But, if it does work on port 143 with TLS I wouldnt worry too much about it
tcpdump is showing me raw text going past, so I know I'm not getting TLS on either Dovecot 2.1 or 2.2
It seems that TLS is not supported by my client. Pity.
iPhone is the worst mail client on this planet but for sure supports TLS
Apple is here the same as Microsoft
- remove the account completly
- add it again and it will detect that encryption is available
Done. But tcpdump is still showing me plain text.
# dovecot -n # 2.1.16: /usr/local/etc/dovecot/dovecot.conf # OS: FreeBSD 9.1-RELEASE-p6 amd64 auth_debug = yes auth_verbose = yes disable_plaintext_auth = no first_valid_gid = 1001 first_valid_uid = 1001 mail_debug = yes mail_location = maildir:~/Maildir mail_privileged_group = mail passdb { args = scheme=BLF-CRYPT /var/db/dovecot.users driver = passwd-file } protocols = imap service imap-login { inet_listener imap { address = 199.233.228.197 } inet_listener imaps { address = 199.233.228.197 port = 0 } } ssl_cert =
-- Dan Langille - http://langille.org/
On Tue, 17 Sep 2013 09:01:49 -0400 Dan Langille articulated:
On 2013-09-17 08:43, Reindl Harald wrote:
Am 17.09.2013 14:39, schrieb Dan Langille: On 2013-09-16 20:28, Noel Butler wrote: Since we just ruled this one out, might I suggest you grab the source and build it, install it all under /opt/dovecot that way it wont interfere with your ports installation and try that, the one you successfully just tested uses dovecot 2.1 not 2.2, so maybe try source of 2.1 and see if it works.
I just tried 2.1.16. The iPhone has no trouble on 143 but on 993, it's just like 2.2
But, if it does work on port 143 with TLS I wouldnt worry too much about it
tcpdump is showing me raw text going past, so I know I'm not getting TLS on either Dovecot 2.1 or 2.2
It seems that TLS is not supported by my client. Pity.
iPhone is the worst mail client on this planet but for sure supports TLS
Apple is here the same as Microsoft
- remove the account completly
- add it again and it will detect that encryption is available
Done. But tcpdump is still showing me plain text.
# dovecot -n # 2.1.16: /usr/local/etc/dovecot/dovecot.conf # OS: FreeBSD 9.1-RELEASE-p6 amd64 auth_debug = yes auth_verbose = yes disable_plaintext_auth = no first_valid_gid = 1001 first_valid_uid = 1001 mail_debug = yes mail_location = maildir:~/Maildir mail_privileged_group = mail passdb { args = scheme=BLF-CRYPT /var/db/dovecot.users driver = passwd-file } protocols = imap service imap-login { inet_listener imap { address = 199.233.228.197 } inet_listener imaps { address = 199.233.228.197 port = 0 } } ssl_cert =
Show the entire dump from when you first attempt to make a connection to the start of message transmission.
-- Jerry ♔
Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header.
On 2013-09-17 09:08, Jerry wrote:
On Tue, 17 Sep 2013 09:01:49 -0400 Dan Langille articulated:
On 2013-09-17 08:43, Reindl Harald wrote:
Am 17.09.2013 14:39, schrieb Dan Langille: On 2013-09-16 20:28, Noel Butler wrote: Since we just ruled this one out, might I suggest you grab the source and build it, install it all under /opt/dovecot that way it wont interfere with your ports installation and try that, the one you successfully just tested uses dovecot 2.1 not 2.2, so maybe try source of 2.1 and see if it works.
I just tried 2.1.16. The iPhone has no trouble on 143 but on 993, it's just like 2.2
But, if it does work on port 143 with TLS I wouldnt worry too much about it
tcpdump is showing me raw text going past, so I know I'm not getting TLS on either Dovecot 2.1 or 2.2
It seems that TLS is not supported by my client. Pity.
iPhone is the worst mail client on this planet but for sure supports TLS
Apple is here the same as Microsoft
- remove the account completly
- add it again and it will detect that encryption is available
Done. But tcpdump is still showing me plain text.
# dovecot -n # 2.1.16: /usr/local/etc/dovecot/dovecot.conf # OS: FreeBSD 9.1-RELEASE-p6 amd64 auth_debug = yes auth_verbose = yes disable_plaintext_auth = no first_valid_gid = 1001 first_valid_uid = 1001 mail_debug = yes mail_location = maildir:~/Maildir mail_privileged_group = mail passdb { args = scheme=BLF-CRYPT /var/db/dovecot.users driver = passwd-file } protocols = imap service imap-login { inet_listener imap { address = 199.233.228.197 } inet_listener imaps { address = 199.233.228.197 port = 0 } } ssl_cert =
Show the entire dump from when you first attempt to make a connection to the start of message transmission.
13:22:17.985508 IP 166.137.85.50.51685 > 199.233.228.197.143: Flags [S], seq 2703590158, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 773682446 ecr 0,sackOK,eol], length 0 EH.@?.@.3._...U2.........%.................Z....... ..u......... 13:22:17.985579 IP 199.233.228.197.143 > 166.137.85.50.51685: Flags [S.], seq 2030926149, ack 2703590159, win 65535, options [mss 1370,nop,wscale 6,sackOK,TS val 2484342793 ecr 773682446], length 0 yE.%......w......Z....... ... ..u. 13:22:18.066507 IP 166.137.85.50.51685 > 199.233.228.197.143: Flags [.], ack 1, win 8232, options [nop,nop,TS val 773682522 ecr 2484342793], length 0 yF.. (........U2.........%..y ..uZ... 13:22:18.093983 IP 199.233.228.197.143 > 166.137.85.50.51685: Flags [P.], seq 1:113, ack 1, win 1039, options [nop,nop,TS val 2484342901 ecr 773682522], length 112 yF.%......R.......U2....y ...u..uZ* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN] Dovecot ready. 13:22:18.224227 IP 166.137.85.50.51685 > 199.233.228.197.143: Flags [.], ack 113, win 8225, options [nop,nop,TS val 773682659 ecr 2484342901], length 0 y... !.9......U2.........%..y ..u....u
It was after this that the login details were passsed. That was in plain text, and omitted from this paste.
13:22:18.245486 IP 199.233.228.197.143 > 166.137.85.50.51685: Flags [P.], seq 113:432, ack 32, win 1039, options [nop,nop,TS val 2484343053 ecr 773682667], length 319 y..%..............U2....y ..u.1 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS SPECIAL-USE] Logged in
13:22:18.311309 IP 166.137.85.50.51685 > 199.233.228.197.143: Flags [.], ack 432, win 8205, options [nop,nop,TS val 773682774 ecr 2484343053], length 0 ........3.s...U2.........%..y ..vV... 13:22:18.384236 IP 166.137.85.50.51685 > 199.233.228.197.143: Flags [P.], seq 32:121, ack 432, win 8205, options [nop,nop,TS val 773682824 ecr 2484343053], length 89 .!......3.6...U2.........%..y 2 ID ("name" "iPhone Mail" "version" "10B350" "os" "iOS" "os-version" "6.1.4 (10B350)")
13:22:18.384634 IP 199.233.228.197.143 > 166.137.85.50.51685: Flags [P.], seq 432:462, ack 121, win 1039, options [nop,nop,TS val 2484343192 ecr 773682824], length 30 z..%..............U2....y ......v.* ID NIL 2 OK ID completed.
13:22:18.455096 IP 166.137.85.50.51685 > 199.233.228.197.143: Flags [.], ack 462, win 8204, options [nop,nop,TS val 773682899 ecr 2484343192], length 0 {... ..f......U2.........%..y ..v..... 13:22:18.464945 IP 166.137.85.50.51685 > 199.233.228.197.143: Flags [P.], seq 121:136, ack 462, win 8204, options [nop,nop,TS val 773682901 ecr 2484343192], length 15 {... .........U2.........%..y ..v.....3 LIST "" "*"
-- Dan Langille - http://langille.org/
Am 17.09.2013 15:01, schrieb Dan Langille:
On 2013-09-17 08:43, Reindl Harald wrote:
Am 17.09.2013 14:39, schrieb Dan Langille: On 2013-09-16 20:28, Noel Butler wrote: Since we just ruled this one out, might I suggest you grab the source and build it, install it all under /opt/dovecot that way it wont interfere with your ports installation and try that, the one you successfully just tested uses dovecot 2.1 not 2.2, so maybe try source of 2.1 and see if it works.
I just tried 2.1.16. The iPhone has no trouble on 143 but on 993, it's just like 2.2
But, if it does work on port 143 with TLS I wouldnt worry too much about it
tcpdump is showing me raw text going past, so I know I'm not getting TLS on either Dovecot 2.1 or 2.2
It seems that TLS is not supported by my client. Pity.
iPhone is the worst mail client on this planet but for sure supports TLS
Apple is here the same as Microsoft
- remove the account completly
- add it again and it will detect that encryption is available
Done. But tcpdump is still showing me plain text.
and you surely have "ssl = yes" in your configuration? "dovecot -n" does not show it here too while it is there
*what* says "telnet your-server 143" if it is configured correctly you see "STARTTLS" in the capabilities if you do not see it than the problem is a completlöy different one
- OK [CAPABILITY IMAP4 IMAP4rev1 ACL RIGHTS=texk NAMESPACE CHILDREN SORT QUOTA THREAD=ORDEREDSUBJECT UNSELECT IDLE STARTTLS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN AUTH=SCRAM-SHA-1]
On 2013-09-17 09:26, Reindl Harald wrote:
Am 17.09.2013 15:01, schrieb Dan Langille: On 2013-09-17 08:43, Reindl Harald wrote: Am 17.09.2013 14:39, schrieb Dan Langille: On 2013-09-16 20:28, Noel Butler wrote: Since we just ruled this one out, might I suggest you grab the source and build it, install it all under /opt/dovecot that way it wont interfere with your ports installation and try that, the one you successfully just tested uses dovecot 2.1 not 2.2, so maybe try source of 2.1 and see if it works.
I just tried 2.1.16. The iPhone has no trouble on 143 but on 993, it's just like 2.2
But, if it does work on port 143 with TLS I wouldnt worry too much about it
tcpdump is showing me raw text going past, so I know I'm not getting TLS on either Dovecot 2.1 or 2.2
It seems that TLS is not supported by my client. Pity.
iPhone is the worst mail client on this planet but for sure supports TLS
Apple is here the same as Microsoft
- remove the account completly
- add it again and it will detect that encryption is available
Done. But tcpdump is still showing me plain text.
and you surely have "ssl = yes" in your configuration? "dovecot -n" does not show it here too while it is there
I do.
"dovecot -n" does not show it here too while it is there
*what* says "telnet your-server 143"
$ telnet imaps.unixathome.org 143 Trying 199.233.228.197... Connected to imaps.unixathome.org. Escape character is '^]'.
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN] Dovecot ready.
if it is configured correctly you see "STARTTLS" in the capabilities if you do not see it than the problem is a completlöy different one
- OK [CAPABILITY IMAP4 IMAP4rev1 ACL RIGHTS=texk NAMESPACE CHILDREN SORT QUOTA THREAD=ORDEREDSUBJECT UNSELECT IDLE STARTTLS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN AUTH=SCRAM-SHA-1]
-- Dan Langille - http://langille.org/
Am 17.09.2013 15:57, schrieb Dan Langille:
On 2013-09-17 09:26, Reindl Harald wrote:
Am 17.09.2013 15:01, schrieb Dan Langille: On 2013-09-17 08:43, Reindl Harald wrote: Am 17.09.2013 14:39, schrieb Dan Langille: On 2013-09-16 20:28, Noel Butler wrote: Since we just ruled this one out, might I suggest you grab the source and build it, install it all under /opt/dovecot that way it wont interfere with your ports installation and try that, the one you successfully just tested uses dovecot 2.1 not 2.2, so maybe try source of 2.1 and see if it works.
I just tried 2.1.16. The iPhone has no trouble on 143 but on 993, it's just like 2.2
But, if it does work on port 143 with TLS I wouldnt worry too much about it
tcpdump is showing me raw text going past, so I know I'm not getting TLS on either Dovecot 2.1 or 2.2
It seems that TLS is not supported by my client. Pity.
iPhone is the worst mail client on this planet but for sure supports TLS
Apple is here the same as Microsoft
- remove the account completly
- add it again and it will detect that encryption is available
Done. But tcpdump is still showing me plain text.
and you surely have "ssl = yes" in your configuration? "dovecot -n" does not show it here too while it is there
I do.
"dovecot -n" does not show it here too while it is there
*what* says "telnet your-server 143"
$ telnet imaps.unixathome.org 143 Trying 199.233.228.197... Connected to imaps.unixathome.org. Escape character is '^]'.
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN] Dovecot ready.
if it is configured correctly you see "STARTTLS" in the capabilities if you do not see it than the problem is a completlöy different one
- OK [CAPABILITY IMAP4 IMAP4rev1 ACL RIGHTS=texk NAMESPACE CHILDREN SORT QUOTA THREAD=ORDEREDSUBJECT UNSELECT IDLE STARTTLS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN AUTH=SCRAM-SHA-1]
may i suggest that you try a different mail client? pretty sure that this is one of the uncountable cases where Apple devices are failing
On 2013-09-17 10:05, Reindl Harald wrote:
Am 17.09.2013 15:57, schrieb Dan Langille: On 2013-09-17 09:26, Reindl Harald wrote: Am 17.09.2013 15:01, schrieb Dan Langille: On 2013-09-17 08:43, Reindl Harald wrote: Am 17.09.2013 14:39, schrieb Dan Langille: On 2013-09-16 20:28, Noel Butler wrote: Since we just ruled this one out, might I suggest you grab the source and build it, install it all under /opt/dovecot that way it wont interfere with your ports installation and try that, the one you successfully just tested uses dovecot 2.1 not 2.2, so maybe try source of 2.1 and see if it works.
I just tried 2.1.16. The iPhone has no trouble on 143 but on 993, it's just like 2.2
But, if it does work on port 143 with TLS I wouldnt worry too much about it
tcpdump is showing me raw text going past, so I know I'm not getting TLS on either Dovecot 2.1 or 2.2
It seems that TLS is not supported by my client. Pity.
iPhone is the worst mail client on this planet but for sure supports TLS
Apple is here the same as Microsoft
- remove the account completly
- add it again and it will detect that encryption is available
Done. But tcpdump is still showing me plain text.
and you surely have "ssl = yes" in your configuration? "dovecot -n" does not show it here too while it is there
I do.
"dovecot -n" does not show it here too while it is there
*what* says "telnet your-server 143"
$ telnet imaps.unixathome.org 143 Trying 199.233.228.197... Connected to imaps.unixathome.org. Escape character is '^]'.
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN] Dovecot ready.
if it is configured correctly you see "STARTTLS" in the capabilities if you do not see it than the problem is a completlöy different one
- OK [CAPABILITY IMAP4 IMAP4rev1 ACL RIGHTS=texk NAMESPACE CHILDREN SORT QUOTA THREAD=ORDEREDSUBJECT UNSELECT IDLE STARTTLS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=LOGIN AUTH=PLAIN AUTH=SCRAM-SHA-1]
may i suggest that you try a different mail client? pretty sure that this is one of the uncountable cases where Apple devices are failing
At present, I am using dovecot-1.2.17 on another server with a certificate from StartCom:
$ openssl s_client -connect nyi.unixathome.org:993 -quiet depth=0 /description=khACEsbS0LZ8es5F/C=US/CN=nyi.unixathome.org/emailAddress=postmaster@unixathome.org verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /description=khACEsbS0LZ8es5F/C=US/CN=nyi.unixathome.org/emailAddress=postmaster@unixathome.org verify error:num=27:certificate not trusted verify return:1 depth=0 /description=khACEsbS0LZ8es5F/C=US/CN=nyi.unixathome.org/emailAddress=postmaster@unixathome.org verify error:num=21:unable to verify the first certificate verify return:1
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN] Dovecot ready.
The server which fails me is running 2.1.16 (was 2.2 before this morning)
$ openssl s_client -connect imaps.unixathome.org:993 -quiet depth=0 /description=P4s7A2l6clvQRRJ4/C=US/CN=imaps.unixathome.org/emailAddress=postmaster@unixathome.org verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /description=P4s7A2l6clvQRRJ4/C=US/CN=imaps.unixathome.org/emailAddress=postmaster@unixathome.org verify error:num=27:certificate not trusted verify return:1 depth=0 /description=P4s7A2l6clvQRRJ4/C=US/CN=imaps.unixathome.org/emailAddress=postmaster@unixathome.org verify error:num=21:unable to verify the first certificate verify return:1
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN] Dovecot ready.
Somewhere, somehow, there is something vastly different and not working.
-- Dan Langille - http://langille.org/
Am 17.09.2013 16:32, schrieb Dan Langille:
*what* says "telnet your-server 143" $ telnet imaps.unixathome.org 143
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN] Dovecot ready.
At present, I am using dovecot-1.2.17 on another server with a certificate from StartCom:
$ openssl s_client -connect nyi.unixathome.org:993 -quiet
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN] Dovecot ready.
The server which fails me is running 2.1.16 (was 2.2 before this morning)
$ openssl s_client -connect imaps.unixathome.org:993 -quiet
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN] Dovecot ready.
Somewhere, somehow, there is something vastly different and not working
you are making it hard to impossible to help you if you are mixing servers and their responses and port 993 will *never ever* show STARTTLS because it is IMAPS which enforces a encrypted connection and *not* STARTTLS where the inital connection is unencrpyted by design
so *please* stay at *one* config, *one* machine and *one* port for debugging
if the machine in question announces STARTTLS on port 143 it should work and that is why i asked if *a different client* than a iPhone is using STARTTLS on *that* machine with *that config*
On 2013-09-17 10:39, Reindl Harald wrote:
Am 17.09.2013 16:32, schrieb Dan Langille: *what* says "telnet your-server 143" $ telnet imaps.unixathome.org 143
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN] Dovecot ready.
At present, I am using dovecot-1.2.17 on another server with a certificate from StartCom:
$ openssl s_client -connect nyi.unixathome.org:993 -quiet
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN] Dovecot ready.
The server which fails me is running 2.1.16 (was 2.2 before this morning)
$ openssl s_client -connect imaps.unixathome.org:993 -quiet
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN] Dovecot ready.
Somewhere, somehow, there is something vastly different and not working
you are making it hard to impossible to help you if you are mixing servers and their responses and port 993 will *never ever* show STARTTLS because it is IMAPS which enforces a encrypted connection and *not* STARTTLS where the inital connection is unencrpyted by design
so *please* stay at *one* config, *one* machine and *one* port for debugging
if the machine in question announces STARTTLS on port 143 it should work and that is why i asked if *a different client* than a iPhone is using STARTTLS on *that* machine with *that config*
Oh I misunderstood. I thought you were suggesting I stop trying to get this to work, give in, and *just use another email client*. My apologies.
I was looking for another iPhone email client which was free and did iMap. I failed. I think I'll just have to pay for one and try it.
I've run out of time just now. I'll try again soon.
Thank you.
-- Dan Langille - http://langille.org/
Am 17.09.2013 16:44, schrieb Dan Langille:
On 2013-09-17 10:39, Reindl Harald wrote:
you are making it hard to impossible to help you if you are mixing servers and their responses and port 993 will *never ever* show STARTTLS because it is IMAPS which enforces a encrypted connection and *not* STARTTLS where the inital connection is unencrpyted by design
so *please* stay at *one* config, *one* machine and *one* port for debugging
if the machine in question announces STARTTLS on port 143 it should work and that is why i asked if *a different client* than a iPhone is using STARTTLS on *that* machine with *that config*
Oh I misunderstood. I thought you were suggesting I stop trying to get this to work, give in, and *just use another email client*. My apologies.
I was looking for another iPhone email client which was free and did iMap. I failed. I think I'll just have to pay for one and try it.
I've run out of time just now. I'll try again soon
i asked for using *a different device* like Thunderbird or whatever on a PC to confirm that STARTLS is working in general or not and not a different application on the same Apple device as we all know that any app on a iPhone is using *the same* backends as the vendor application
that's why there is no Firefox because the would have to use Safari and make a nice window around it but not a own rendering engine
with thunderbird you can *explicit* switch between IMAPS on 993 and STARTTLS on port 143 and so easy verify if the server is working and only your specific client have a problem
Le 17/09/2013 à 16:32, Dan Langille a écrit :
$ openssl s_client -connect imaps.unixathome.org:993 -quiet depth=0 /description=P4s7A2l6clvQRRJ4/C=US/CN=imaps.unixathome.org/emailAddress=postmaster@unixathome.org
verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /description=P4s7A2l6clvQRRJ4/C=US/CN=imaps.unixathome.org/emailAddress=postmaster@unixathome.org
verify error:num=27:certificate not trusted verify return:1 depth=0 /description=P4s7A2l6clvQRRJ4/C=US/CN=imaps.unixathome.org/emailAddress=postmaster@unixathome.org
verify error:num=21:unable to verify the first certificate verify return:1
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN] Dovecot ready.
Somewhere, somehow, there is something vastly different and not working.
Hi,
Something is definitely wrong with your certificate chain. The first certificate listed in your chain (depth 2) should be StartCom's root CA, bearing "CN = StartCom Certification Authority", the 2nd one (depth 1) should be the intermediate cert, bearing "CN = StartCom Class 1 Primary Intermediate Server CA" and the last one (depth 0) should be yours.
You told in an earlier message that you had put the 3 certs (yours, then the intermediate, and then the root) in your crt file. Is it still the case ? If not, you really *must* do it, even if you find it makes no difference. Maybe there's another problem somewhere else, but this chain is a prerequisite for many clients to work.
Regards,
Bruno
--
- Service Hydrographique et Oceanographique de la Marine - DMGS/INF
- 13, rue du Chatellier - CS 92803 - 29228 Brest Cedex 2, FRANCE
Phone: +33 2 98 22 17 49 - Email: Bruno.Treguier@shom.fr
On Sep 17, 2013, at 10:59 AM, Bruno Tréguier wrote:
Le 17/09/2013 à 16:32, Dan Langille a écrit :
$ openssl s_client -connect imaps.unixathome.org:993 -quiet depth=0 /description=P4s7A2l6clvQRRJ4/C=US/CN=imaps.unixathome.org/emailAddress=postmaster@unixathome.org
verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /description=P4s7A2l6clvQRRJ4/C=US/CN=imaps.unixathome.org/emailAddress=postmaster@unixathome.org
verify error:num=27:certificate not trusted verify return:1 depth=0 /description=P4s7A2l6clvQRRJ4/C=US/CN=imaps.unixathome.org/emailAddress=postmaster@unixathome.org
verify error:num=21:unable to verify the first certificate verify return:1
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN] Dovecot ready.
Somewhere, somehow, there is something vastly different and not working.
Hi,
Something is definitely wrong with your certificate chain. The first certificate listed in your chain (depth 2) should be StartCom's root CA, bearing "CN = StartCom Certification Authority", the 2nd one (depth 1) should be the intermediate cert, bearing "CN = StartCom Class 1 Primary Intermediate Server CA" and the last one (depth 0) should be yours.
You told in an earlier message that you had put the 3 certs (yours, then the intermediate, and then the root) in your crt file. Is it still the case ? If not, you really *must* do it, even if you find it makes no difference. Maybe there's another problem somewhere else, but this chain is a prerequisite for many clients to work.
After a long delay, I'm ready to tackle this again.
This is my configuration:
# dovecot -n
# 2.2.6: /usr/local/etc/dovecot/dovecot.conf
# OS: FreeBSD 9.1-RELEASE-p6 amd64
auth_debug = yes
auth_verbose = yes
first_valid_gid = 1001
first_valid_uid = 1001
mail_debug = yes
mail_location = maildir:~/Maildir
mail_privileged_group = mail
passdb {
args = scheme=SHA512-CRYPT /var/db/dovecot.users
driver = passwd-file
}
protocols = imap
service imap-login {
inet_listener imap {
address = 199.233.228.197
port = 0
}
inet_listener imaps {
address = 199.233.228.197
}
}
ssl_cert =
/usr/local/etc/ssl/dovecot.pem was created via:
cat imaps.unixathome.org.crt sub.class2.server.ca.pem ca.pem > dovecot.pem
All the certs are startssl.com certs.
Testing via the command line gives:
$ openssl s_client -connect imaps.unixathome.org:993 CONNECTED(00000003) depth=2 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0
Certificate chain 0 s:/description=VwhdJi0sLHP3BDtQ/C=US/ST=Pennsylvania/L=Media/O=Daniel Langille/CN=imaps.unixathome.org/emailAddress=postmaster@unixathome.org i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority 2 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
Server certificate -----BEGIN CERTIFICATE----- MIIHsjCCBpqgAwIBAgIDAaiZMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJ TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MiBQcmltYXJ5IEludGVybWVkaWF0ZSBTZXJ2ZXIgQ0EwHhcNMTMxMDA2MTIzODI3 WhcNMTUxMDA2MjA1NzI4WjCBsjEZMBcGA1UEDRMQVndoZEppMHNMSFAzQkR0UTEL MAkGA1UEBhMCVVMxFTATBgNVBAgTDFBlbm5zeWx2YW5pYTEOMAwGA1UEBxMFTWVk aWExGDAWBgNVBAoTD0RhbmllbCBMYW5naWxsZTEdMBsGA1UEAxMUaW1hcHMudW5p eGF0aG9tZS5vcmcxKDAmBgkqhkiG9w0BCQEWGXBvc3RtYXN0ZXJAdW5peGF0aG9t ZS5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQLgy4N8rCnhZS5t uwA0/4gTmMNdNflfwUgWGGUoeOC3qcodt2EitcnuhLfvDJORrpZtxKYYK0SMAlJt RHg+DTp+9mSCicDWjoxOcc1WbUUkAiFdkL155LtMEd2xSB/NaEbjeone86ln5erz 4BLJqiaaubOkhAwXrJy/Owfp6RUbqEKUToGI1bF+q5EFFGqh3rO7/3Gpx0qihScx 6sGa04CgqhT0G6JOw6zJ5zJE0PSX4U/S7nAJCA/ktXNU3v23Jd+RYIOqrmuyHnf6 dISQH8HQKr83L3D3Yq64GCadvf0Nv/xrxc/4UO2mpiZlZppf+8Q+vTgfwl98OH62 mqdUM8hspGMAtRGmt8ccB73ukmqHvY9QJEGNNvx181VlTTcAygi/R5LiEtwFewAj Zk4QvC4O3O3Rxl6VKfEgmoO93EXFfbVylv7MQqs6NKGeIdMgBpcxdsrlXo8ofVCz uIQvJV8G8mlejP/RstZAoGxtUP5BRrLbcke3q77l6d6DYrTAhb7SgxP31AYrSknj I+sCNb5IJvrrZe9lZt8OYlm3Yog8wjiTCgeBlytes7L95Dr0Xn8jZk4Dzg59HbO4 AIlSVdMistZatAvM9QFBPUdt36dyNkFOGpAtNblfmV3pB1Wyz0LlxhS2n3XFxSJB ZgHvBYV891UoSm6julSzeE2i/6liIQIDAQABo4IC8zCCAu8wCQYDVR0TBAIwADAL BgNVHQ8EBAMCA6gwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMB0GA1Ud DgQWBBTuSWRJewXVTNYjoX6gw/DdaXcDqTAfBgNVHSMEGDAWgBQR2yNF/VTManFv hIoD1773AS8mhjAvBgNVHREEKDAmghRpbWFwcy51bml4YXRob21lLm9yZ4IOdW5p eGF0aG9tZS5vcmcwggFWBgNVHSAEggFNMIIBSTAIBgZngQwBAgIwggE7BgsrBgEE AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1 ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1l bnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9y IHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlp bmcgcGFydHkgb2JsaWdhdGlvbnMuMDUGA1UdHwQuMCwwKqAooCaGJGh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL2NydDItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5 BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIv c2VydmVyL2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MyLnNlcnZlci5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBHkfLREbnBtJUE MPDsaHEZSEDe5uagtAvuNMQh03qcu5UG2x5KkjeT6OK7JwrrjEehA+m5t2JcGtPY dLN8VB9w7WdPg4ezNR/F4sKdeOPNl8+Us5pWMXRPnLN8EqAp4Kg5KzfJli8Jnaxw Snbs1Itmwxm19lYF2nWPUMMBru4CxHN7U5jbii+wqpi3LhRK/okuMEbG7xogcboP n2CDTFk6Yc9W0BE7XBwr1t0xE8KFgvlKu87RS3C+d1AkzM92NUDgS0JQgmO6F2T/ nBsediEpNGORzEvSuq/4wVych5tUKFkksy5X4CHXZw86YjZccPcrtpLrWxs5EhUD s+tkDOSK -----END CERTIFICATE----- subject=/description=VwhdJi0sLHP3BDtQ/C=US/ST=Pennsylvania/L=Media/O=Daniel Langille/CN=imaps.unixathome.org/emailAddress=postmaster@unixathome.org issuer=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
No client certificate CA names sent
SSL handshake has read 6672 bytes and written 409 bytes
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 4098 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: AE8788A1289F10CB6417E4578F2EB86AFC132B3637748B237C559C72ECE26D77 Session-ID-ctx: Master-Key: 9D2151FF1BB2C45F32C1DBB1E49E45FA1E03F82387EE9FCCB50D7F2DB02BB0169D82B4ED386DCD17221856DD35CB1617 Key-Arg : None PSK identity: None PSK identity hint: None TLS session ticket: 0000 - a4 61 9f 61 21 7e 67 45-71 2d 46 97 c7 4c 6c 99 .a.a!~gEq-F..Ll. 0010 - e8 7a 4b 5b 5d f5 32 e7-fe 1d 78 fa 4e 43 72 6e .zK[].2...x.NCrn 0020 - 68 22 4b 60 68 91 98 39-d1 50 09 0a 2a 08 f0 ae h"K`h..9.P..*... 0030 - a9 6e 14 b8 d9 82 09 3b-7d ef 1a b0 f1 d8 a7 c4 .n.....;}....... 0040 - 2c 83 57 a1 03 6e 17 89-13 ff 82 e0 06 88 c9 a1 ,.W..n.......... 0050 - dc 79 e7 3f 3b d4 da da-47 d8 63 07 71 6c df 2b .y.?;...G.c.ql.+ 0060 - 39 b2 0f f7 bf ac 8e b3-37 24 6f 58 83 1f 2a 65 9.......7$oX..*e 0070 - 7f 19 fb 1c 9a 46 1f 35-73 b1 cb 73 6b b5 c6 84 .....F.5s..sk... 0080 - dc d3 4b cb e7 db bb 7c-f3 52 b4 69 1b 42 9e 21 ..K....|.R.i.B.! 0090 - 4d c0 50 19 d2 98 77 be-b8 0e 9e 66 e7 d7 d9 52 M.P...w....f...R
Start Time: 1381089774
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN] Dovecot ready.
I can login fine. This is the temporary login and password. There is nothing private in there at present. If anyone wishes to confirm this works, please feel free to connect in. I'm especially interested in those of you with Mac or iPhones. Is this only me? All Mac/iPhone?
a1 login dan password a1 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS SPECIAL-USE BINARY MOVE] Logged in
and commands work OK:
a3 examine inbox
- FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
- OK [PERMANENTFLAGS ()] Read-only mailbox.
- 0 EXISTS
- 0 RECENT
- OK [UIDVALIDITY 1379426958] UIDs valid
- OK [UIDNEXT 1] Predicted next UID
- OK [NOMODSEQ] No permanent modsequences a3 OK [READ-ONLY] Examine completed (0.014 secs).
Logout:
a5 LOGOUT
- BYE Logging out a5 OK Logout completed. closed
All looks good.
/var/log/maillog shows:
Oct 6 20:06:28 imaps dovecot: imap-login: Login: user=<dan>, method=PLAIN, rip=98.111.147.220, lip=199.233.228.197, mpid=81052, TLS, session=<fYUwEhjoVgBib5Pc> Oct 6 20:08:21 imaps dovecot: imap(dan): Disconnected: Logged out in=26 out=691
I have Thunderbird working just fine on my Macbook.
But my goal is mail.app on my iPhone and my Macbook. When they try to connect, the mail server logs are:
Oct 6 20:20:25 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [98.111.147.220] Oct 6 20:20:25 imaps dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=98.111.147.220, lip=199.233.228.197, TLS handshaking: Disconnected, session=<Ux8HRBjo7QBib5Pc>
Yet, the same iPhone and Macbook connect fine to a dovecot 1.2.17 installation. That's my current IMAP server. I'm moving to another server and failing so far.
Suggestions to use another client app or platform will not be entertained, because, clearly, this works with dovecot 1.
-- Dan Langille - http://langille.org
Am 06.10.2013 22:42, schrieb Dan Langille:
I have Thunderbird working just fine on my Macbook.
But my goal is mail.app on my iPhone and my Macbook. When they try to connect, the mail server logs are:
Oct 6 20:20:25 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [98.111.147.220] Oct 6 20:20:25 imaps dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=98.111.147.220, lip=199.233.228.197, TLS handshaking: Disconnected, session=<Ux8HRBjo7QBib5Pc> Yet, the same iPhone and Macbook connect fine to a dovecot 1.2.17 installation. That's my current IMAP server. I'm moving to another server and failing so far.
Suggestions to use another client app or platform will not be entertained, because, clearly, this works with dovecot 1
and mail.app is working even with *self signed* certificates and dovecot 2.2 you only have to accept / import the certificate proven by a testserver all day long
so i assume the problem exists between chair and keyboard
On 2013-10-06 17:06, Reindl Harald wrote:
Am 06.10.2013 22:42, schrieb Dan Langille: I have Thunderbird working just fine on my Macbook.
But my goal is mail.app on my iPhone and my Macbook. When they try to connect, the mail server logs are:
Oct 6 20:20:25 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [98.111.147.220] Oct 6 20:20:25 imaps dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=98.111.147.220, lip=199.233.228.197, TLS handshaking: Disconnected, session=<Ux8HRBjo7QBib5Pc> Yet, the same iPhone and Macbook connect fine to a dovecot 1.2.17 installation. That's my current IMAP server. I'm moving to another server and failing so far.
Suggestions to use another client app or platform will not be entertained, because, clearly, this works with dovecot 1
and mail.app is working even with *self signed* certificates and dovecot 2.2 you only have to accept / import the certificate proven by a testserver all day long
so i assume the problem exists between chair and keyboard
It is something I am doing. Without a doubt.
Clearly, there is something unique about this situation which is not going well. I want to discover the problem so others do not encounter it in future.
-- Dan Langille - http://langille.org/
On Oct 6, 2013, at 5:06 PM, Reindl Harald wrote:
Am 06.10.2013 22:42, schrieb Dan Langille:
I have Thunderbird working just fine on my Macbook.
But my goal is mail.app on my iPhone and my Macbook. When they try to connect, the mail server logs are:
Oct 6 20:20:25 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [98.111.147.220] Oct 6 20:20:25 imaps dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=98.111.147.220, lip=199.233.228.197, TLS handshaking: Disconnected, session=<Ux8HRBjo7QBib5Pc> Yet, the same iPhone and Macbook connect fine to a dovecot 1.2.17 installation. That's my current IMAP server. I'm moving to another server and failing so far.
Suggestions to use another client app or platform will not be entertained, because, clearly, this works with dovecot 1
and mail.app is working even with *self signed* certificates and dovecot 2.2 you only have to accept / import the certificate proven by a testserver all day long
It seems that the test server is not testing this particular situation.
so i assume the problem exists between chair and keyboard
Turns out, this assumption is incorrect.
Just saying….
-- Dan Langille - http://langille.org
Am 09.10.2013 21:06, schrieb Dan Langille:
On Oct 6, 2013, at 5:06 PM, Reindl Harald wrote:
and mail.app is working even with *self signed* certificates and dovecot 2.2 you only have to accept / import the certificate proven by a testserver all day long
It seems that the test server is not testing this particular situation.
it is not the servers job to accept the cert the particular server makes it even harder as defaults
ssl_cipher_list = EECDH-AES256:EECDH-AES:DHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:EDH-AES256:EDH-AES128:EDH-AES:EECDH-RC4:DHE-RC4:EDH-RC4:AES256-SHA:AES128-SHA:TLSv1+HIGH:HIGH:RC4+MEDIUM:!aNULL:!eNULL:!EXP:!MD5:!LOW:!SSLv2:!PSK:@STRENGTH ssl_prefer_server_ciphers = yes
so i assume the problem exists between chair and keyboard
Turns out, this assumption is incorrect.
Just saying
imap-login: OK: imap@testserver.rhsoft.net, 91.118.73.200, CRAM-MD5, TLSv1 with cipher DHE-RSA-AES256-SHA
- dovecot 2.2.6 / openssl-1.0.1e
- self signed certificate
- 4096 Bit (recently changed from 2048 bit and had to be again accepted by the user)
- Apple OSX Mail.app
it's not the job of the server to accept the cert period
Le 06/10/2013 à 22:42, Dan Langille a écrit :
After a long delay, I'm ready to tackle this again.
[...]
Testing via the command line gives:
$ openssl s_client -connect imaps.unixathome.org:993 CONNECTED(00000003) depth=2 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0
Ok, this is fine, and different from the result you were getting a few weeks ago. Your cert chain is ok, it seems. The "errornum=19:self signed certificate in certificate chain" is a "normal" errot, due to the fact that you didn't tell openssl where to find a list of valid root certs.
All looks good.
/var/log/maillog shows:
Oct 6 20:06:28 imaps dovecot: imap-login: Login: user=<dan>, method=PLAIN, rip=98.111.147.220, lip=199.233.228.197, mpid=81052, TLS, session=<fYUwEhjoVgBib5Pc> Oct 6 20:08:21 imaps dovecot: imap(dan): Disconnected: Logged out in=26 out=691
I have Thunderbird working just fine on my Macbook.
But my goal is mail.app on my iPhone and my Macbook. When they try to connect, the mail server logs are:
Oct 6 20:20:25 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [98.111.147.220] Oct 6 20:20:25 imaps dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=98.111.147.220, lip=199.233.228.197, TLS handshaking: Disconnected, session=<Ux8HRBjo7QBib5Pc>
Yet, the same iPhone and Macbook connect fine to a dovecot 1.2.17 installation. That's my current IMAP server. I'm moving to another server and failing so far.
Suggestions to use another client app or platform will not be entertained, because, clearly, this works with dovecot 1.
Well, sorry but no further suggestions as far as I'm concerned then, except that some people tend to think that mail.app is pretty crappy and behaves quite strangely in certain situations...
Best regards,
Bruno
--
- Service Hydrographique et Oceanographique de la Marine - DMGS/INF
- 13, rue du Chatellier - CS 92803 - 29228 Brest Cedex 2, FRANCE
Phone: +33 2 98 22 17 49 - Email: Bruno.Treguier@shom.fr
On 2013-10-07 13:57, Bruno Tréguier wrote:
Le 06/10/2013 à 22:42, Dan Langille a écrit : After a long delay, I'm ready to tackle this again.
[...] Testing via the command line gives:
$ openssl s_client -connect imaps.unixathome.org:993 CONNECTED(00000003) depth=2 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0
Ok, this is fine, and different from the result you were getting a few weeks ago. Your cert chain is ok, it seems. The "errornum=19:self signed certificate in certificate chain" is a "normal" errot, due to the fact that you didn't tell openssl where to find a list of valid root certs.
All looks good.
/var/log/maillog shows:
Oct 6 20:06:28 imaps dovecot: imap-login: Login: user=<dan>, method=PLAIN, rip=98.111.147.220, lip=199.233.228.197, mpid=81052, TLS, session=<fYUwEhjoVgBib5Pc> Oct 6 20:08:21 imaps dovecot: imap(dan): Disconnected: Logged out in=26 out=691
I have Thunderbird working just fine on my Macbook.
But my goal is mail.app on my iPhone and my Macbook. When they try to connect, the mail server logs are:
Oct 6 20:20:25 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [98.111.147.220] Oct 6 20:20:25 imaps dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=98.111.147.220, lip=199.233.228.197, TLS handshaking: Disconnected, session=<Ux8HRBjo7QBib5Pc>
Yet, the same iPhone and Macbook connect fine to a dovecot 1.2.17 installation. That's my current IMAP server. I'm moving to another server and failing so far.
Suggestions to use another client app or platform will not be entertained, because, clearly, this works with dovecot 1.
Well, sorry but no further suggestions as far as I'm concerned then, except that some people tend to think that mail.app is pretty crappy and behaves quite strangely in certain situations...
I have given up. As much as I'd like to solve this problem, I must move on. I will resort to self-signed certificates.[1] I had hoped to resolve the issue so that others can use the solution.
My thanks to those that have offered suggestions and help.
[1] - FYI, I am the only user of this IMAP server.
-- Dan Langille - http://langille.org/
On Oct 8, 2013, at 8:59 AM, Dan Langille wrote:
On 2013-10-07 13:57, Bruno Tréguier wrote:
Le 06/10/2013 à 22:42, Dan Langille a écrit : After a long delay, I'm ready to tackle this again. [...] Testing via the command line gives: $ openssl s_client -connect imaps.unixathome.org:993 CONNECTED(00000003) depth=2 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0 Ok, this is fine, and different from the result you were getting a few weeks ago. Your cert chain is ok, it seems. The "errornum=19:self signed certificate in certificate chain" is a "normal" errot, due to the fact that you didn't tell openssl where to find a list of valid root certs. All looks good. /var/log/maillog shows: Oct 6 20:06:28 imaps dovecot: imap-login: Login: user=<dan>, method=PLAIN, rip=98.111.147.220, lip=199.233.228.197, mpid=81052, TLS, session=<fYUwEhjoVgBib5Pc> Oct 6 20:08:21 imaps dovecot: imap(dan): Disconnected: Logged out in=26 out=691 I have Thunderbird working just fine on my Macbook. But my goal is mail.app on my iPhone and my Macbook. When they try to connect, the mail server logs are: Oct 6 20:20:25 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [98.111.147.220] Oct 6 20:20:25 imaps dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=98.111.147.220, lip=199.233.228.197, TLS handshaking: Disconnected, session=<Ux8HRBjo7QBib5Pc> Yet, the same iPhone and Macbook connect fine to a dovecot 1.2.17 installation. That's my current IMAP server. I'm moving to another server and failing so far. Suggestions to use another client app or platform will not be entertained, because, clearly, this works with dovecot 1. Well, sorry but no further suggestions as far as I'm concerned then, except that some people tend to think that mail.app is pretty crappy and behaves quite strangely in certain situations...
I have given up. As much as I'd like to solve this problem, I must move on. I will resort to self-signed certificates.[1] I had hoped to resolve the issue so that others can use the solution.
My thanks to those that have offered suggestions and help.
[1] - FYI, I am the only user of this IMAP server.
The problem *may* be with 4096 bit certificates. I've been able to connect with a 2048-bit, but not with a 4096-bit.
More testing to be done.
-- Dan Langille - http://langille.org
On Tue, 2013-09-17 at 08:39 -0400, Dan Langille wrote:
Since we just ruled this one out, might I suggest you grab the source and build it, install it all under /opt/dovecot that way it wont interfere with your ports installation and try that, the one you successfully just tested uses dovecot 2.1 not 2.2, so maybe try source of 2.1 and see if it works.
I just tried 2.1.16. The iPhone has no trouble on 143 but on 993, it's just like 2.2
But, if it does work on port 143 with TLS I wouldnt worry too much about it
tcpdump is showing me raw text going past, so I know I'm not getting TLS on either Dovecot 2.1 or 2.2
Hrmm, do you still have that profile of when you used my test a/c? if so TLS definitely worked, so just try changing the user/pass/server... or see whats different between the two profiles.
It seems that TLS is not supported by my client. Pity.
Yes, TLS is supported on your iphone, and works imap-login: Info: Login: user=xxx@xxxxxxxx, method=PLAIN, rip=xxxxxxx, TLS
I thank you for your help though. We have a workaround, which is good enough for my particular situation: self-signed certificates. However, that solution is not ideal for most people. It is for that reason that I'm willing to keep hacking at this if others have further ideas / suggestions.
Do you have another PC based mail client you can test with? one that you have never used to the mail server before and wont have ever accepted a cert from that server, be it startssl's, or self signed, so something completely clean, and try connect and see if cert fails?
On 16 Sep 2013, at 08:10 , Dan Langille dan@langille.org wrote:
For this test, I reconfigured the server to NOT use IMAPS and restarted it. Then I went to my iPhone and turned off SSL for this mail account.
That configuration works for my iPhone.
This is very odd. For the record, I used an iPhone (iOS 7) and iPad (iOS 7), and a couple of Macs, and at least 5 other users use iPhones with iOS 6, and several people are using Macs (OS X 10.6 through 10.9) to connect to my server via SSL.
The only thing that may be different is that I do not allow non-secure connections.
in the account setting on the phone:
Use SSL [X] authentication: Password IMAP Path Prefix: / Server Port: 993
the '/' is grayed out as the default no entry choice
STARTTLS works just fine on the Submission port (587)
-- Evil is a little man afraid for his job.
I'm using Dovecot 2.2.5. I'm setting up and new IMAPS server for personal use (i.e. only me).
I have success with self-signed certificates but not with others (e.g.
my setup is similar (although I'm at dovecot 2.1.17) using certs from StartSSL with several macs and many iphones, and it works. The only thing (that seems relevant) that's different in our configs is that I have this line:
ssl_ca =
which is just http://www.startssl.com/certs/ca-bundle.pem
.jh
On 09/13/2013 02:59 PM, Dan Langille wrote:
*** /var/log/maillog *** Sep 13 11:50:46 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [166.137.84.11] Sep 13 11:50:46 imaps dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=166.137.84.11, lip=199.233.228.197, TLS handshaking: Disconnected, session=<a7AJd0LmWwCmiVQL>
How about tring to use a username to identify the user?? it is very clear that there is nothing that the client tries to do...
Eliezer
Am 09.10.2013 21:27, schrieb Eliezer Croitoru:
On 09/13/2013 02:59 PM, Dan Langille wrote:
*** /var/log/maillog *** Sep 13 11:50:46 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [166.137.84.11] Sep 13 11:50:46 imaps dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=166.137.84.11, lip=199.233.228.197, TLS handshaking: Disconnected, session=<a7AJd0LmWwCmiVQL>
How about tring to use a username to identify the user?? it is very clear that there is nothing that the client tries to do...
it is much more clear that there is no username if the client refuses the SSL handshake because it does not like the cert or the offered ssl-ciphers
user=<> is pretty normal in a lot of cases
- ssl cert not accepted and not allowed by the user in case of untrusted
- no cipher the client accpets
- no auth-mech the client accepts offered by the server
so how do *you* imagine to see a username in the log?
On 10/09/2013 10:31 PM, Reindl Harald wrote:
Am 09.10.2013 21:27, schrieb Eliezer Croitoru:
On 09/13/2013 02:59 PM, Dan Langille wrote:
*** /var/log/maillog *** Sep 13 11:50:46 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [166.137.84.11] Sep 13 11:50:46 imaps dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=166.137.84.11, lip=199.233.228.197, TLS handshaking: Disconnected, session=<a7AJd0LmWwCmiVQL>
How about tring to use a username to identify the user?? it is very clear that there is nothing that the client tries to do...
it is much more clear that there is no username if the client refuses the SSL handshake because it does not like the cert or the offered ssl-ciphers
user=<> is pretty normal in a lot of cases
- ssl cert not accepted and not allowed by the user in case of untrusted
- no cipher the client accpets
- no auth-mech the client accepts offered by the server
so how do *you* imagine to see a username in the log?
I expect that StarSSL will put a good configuration examples for Apache Postfix Dovecot Exim nginx and more.. This way their service would give much more... I am just still unsure How long would it take to write the docs that exalain all the mentioned above: there is a SSL hirarcy and StarSSL uses this hirarchy which you need to understand and then the next thing to do is to answer a question or two to make sure you understand that everything is OK with the service etc.
A basic openssl client into a ssl port should be sufficent but in a case of a special client that verifies two way key it's another story.
Hope there was a solution in the upper part of the thread.
Eliezer
Am 09.10.2013 21:45, schrieb Eliezer Croitoru:
On 10/09/2013 10:31 PM, Reindl Harald wrote:
Am 09.10.2013 21:27, schrieb Eliezer Croitoru:
On 09/13/2013 02:59 PM, Dan Langille wrote:
*** /var/log/maillog *** Sep 13 11:50:46 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [166.137.84.11] Sep 13 11:50:46 imaps dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=166.137.84.11, lip=199.233.228.197, TLS handshaking: Disconnected, session=<a7AJd0LmWwCmiVQL>
How about tring to use a username to identify the user?? it is very clear that there is nothing that the client tries to do...
it is much more clear that there is no username if the client refuses the SSL handshake because it does not like the cert or the offered ssl-ciphers
user=<> is pretty normal in a lot of cases
- ssl cert not accepted and not allowed by the user in case of untrusted
- no cipher the client accpets
- no auth-mech the client accepts offered by the server
so how do *you* imagine to see a username in the log?
I expect that StarSSL will put a good configuration examples for Apache Postfix Dovecot Exim nginx and more..
not their job and not part of the problem
- your client accepts a certificate
- your client does not accept your certificate
in case it does not *you* as enduser have to accept/import the servers cert
http://stackoverflow.com/questions/10879370/startssl-class-1-certificate-not... http://www.startssl.com/?app=25#31
if someone does not know what a "intermediate CA" he needs to RTFM or *read* messages of his client or buy by all major clients acepted certificates
but that all has less to do with your blunty "it is very clear that there is nothing that the client tries to do" showing that you have zero expierience how a client handshake works -> it does not send usernames or even passwords until it is not satisfied with the negotiation of auth-mechs and ssl-handshake
On 10/09/2013 10:55 PM, Reindl Harald wrote:
Am 09.10.2013 21:45, schrieb Eliezer Croitoru:
On 10/09/2013 10:31 PM, Reindl Harald wrote:
Am 09.10.2013 21:27, schrieb Eliezer Croitoru:
On 09/13/2013 02:59 PM, Dan Langille wrote:
*** /var/log/maillog *** Sep 13 11:50:46 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [166.137.84.11] Sep 13 11:50:46 imaps dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=166.137.84.11, lip=199.233.228.197, TLS handshaking: Disconnected, session=<a7AJd0LmWwCmiVQL>
How about tring to use a username to identify the user?? it is very clear that there is nothing that the client tries to do...
it is much more clear that there is no username if the client refuses the SSL handshake because it does not like the cert or the offered ssl-ciphers
user=<> is pretty normal in a lot of cases
- ssl cert not accepted and not allowed by the user in case of untrusted
- no cipher the client accpets
- no auth-mech the client accepts offered by the server
so how do *you* imagine to see a username in the log?
I expect that StarSSL will put a good configuration examples for Apache Postfix Dovecot Exim nginx and more..
not their job and not part of the problem
- your client accepts a certificate
- your client does not accept your certificate
in case it does not *you* as enduser have to accept/import the servers cert
http://stackoverflow.com/questions/10879370/startssl-class-1-certificate-not... http://www.startssl.com/?app=25#31
if someone does not know what a "intermediate CA" he needs to RTFM or *read* messages of his client or buy by all major clients acepted certificates
but that all has less to do with your blunty "it is very clear that there is nothing that the client tries to do" showing that you have zero expierience how a client handshake works -> it does not send usernames or even passwords until it is not satisfied with the negotiation of auth-mechs and ssl-handshake
I Would try to use StartSSL with squid and I will see if the docs in squid ssl-bump explains the subject in a way I can understand. As Dan explained his major problem is with specific encryption cypher in a very specific size.. I would imaging that 4k bits certificate handshake and validation can take more then 1 sec.. Am I right about it?
Thanks, Eliezer
Am 09.10.2013 22:09, schrieb Eliezer Croitoru:
On 10/09/2013 10:55 PM, Reindl Harald wrote:
Am 09.10.2013 21:45, schrieb Eliezer Croitoru:
On 10/09/2013 10:31 PM, Reindl Harald wrote:
Am 09.10.2013 21:27, schrieb Eliezer Croitoru:
On 09/13/2013 02:59 PM, Dan Langille wrote:
*** /var/log/maillog *** Sep 13 11:50:46 imaps dovecot: imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [166.137.84.11] Sep 13 11:50:46 imaps dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=166.137.84.11, lip=199.233.228.197, TLS handshaking: Disconnected, session=<a7AJd0LmWwCmiVQL>
How about tring to use a username to identify the user?? it is very clear that there is nothing that the client tries to do...
it is much more clear that there is no username if the client refuses the SSL handshake because it does not like the cert or the offered ssl-ciphers
user=<> is pretty normal in a lot of cases
- ssl cert not accepted and not allowed by the user in case of untrusted
- no cipher the client accpets
- no auth-mech the client accepts offered by the server
so how do *you* imagine to see a username in the log?
I expect that StarSSL will put a good configuration examples for Apache Postfix Dovecot Exim nginx and more..
not their job and not part of the problem
- your client accepts a certificate
- your client does not accept your certificate
in case it does not *you* as enduser have to accept/import the servers cert
http://stackoverflow.com/questions/10879370/startssl-class-1-certificate-not... http://www.startssl.com/?app=25#31
if someone does not know what a "intermediate CA" he needs to RTFM or *read* messages of his client or buy by all major clients acepted certificates
but that all has less to do with your blunty "it is very clear that there is nothing that the client tries to do" showing that you have zero expierience how a client handshake works -> it does not send usernames or even passwords until it is not satisfied with the negotiation of auth-mechs and ssl-handshake
I Would try to use StartSSL with squid and I will see if the docs in squid ssl-bump explains the subject in a way I can understand
RTFM http://www.startssl.com/?app=25 or go to http://www.thawte.com/
As Dan explained his major problem is with specific encryption cypher in a very specific size.. I would imaging that 4k bits certificate handshake and validation can take more then 1 sec.. Am I right about it?
why in the world should it take more than 1 second? and even if - how does this matter?
On 10/09/2013 11:15 PM, Reindl Harald wrote:
why in the world should it take more than 1 second? and even if - how does this matter? The dovecot daemon waited only 1 second for responnse.. and if there is a 900 Mhz client like many devices that uses android how long it would take to encypt end decrypt over Mobile network a 4k encryption without any assisting crypt cards??
Eliezer
Am 09.10.2013 23:09, schrieb Eliezer Croitoru:
On 10/09/2013 11:15 PM, Reindl Harald wrote:
why in the world should it take more than 1 second? and even if - how does this matter? The dovecot daemon waited only 1 second for responnse..
says who?
the *client* closed the connection within one second because it did not accept cert/ciphers/auth-mechs
and if there is a 900 Mhz client like many devices that uses android how long it would take to encypt end decrypt over Mobile network a 4k encryption without any assisting crypt cards??
you need to understand basics for assumptions
encypt/decrypt what amount of data? for the handshake - meaningless
On 10/10/2013 06:09, Eliezer Croitoru wrote:
I would imaging that 4k bits certificate handshake and validation can take more then 1 sec.. Am I right about it?
hardly
and the size is not his problem.
he was given a test account on my network when I last saw this thread (few weeks back?), that uses startssl, and 4096 certs, his mail.app connected fine.
On Oct 9, 2013, at 6:33 PM, Noel Butler wrote:
On 10/10/2013 06:09, Eliezer Croitoru wrote:
I would imaging that 4k bits certificate handshake and validation can take more then 1 sec.. Am I right about it?
hardly
and the size is not his problem.
he was given a test account on my network when I last saw this thread (few weeks back?), that uses startssl, and 4096 certs, his mail.app connected fine.
I would like to investigate that more if you like. Others have experienced problem connected to my test server. I can't believe I've created a non-functional Dovecot configuration.
One avenue I will purse: if I swap from 4096 to 2048, why does it work?
Here is a connection with a 4096 cert:
$ openssl s_ s_client -connect imaps.unixathome.org:993 CONNECTED(00000003) depth=2 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0
Certificate chain 0 s:/description=VwhdJi0sLHP3BDtQ/C=US/ST=Pennsylvania/L=Media/O=Daniel Langille/CN=imaps.unixathome.org/emailAddress=postmaster@unixathome.org i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority 2 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
Here is it with a 2048 cert:
$ openssl s_client -connect imaps.unixathome.org:993 CONNECTED(00000003) depth=2 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0
Certificate chain 0 s:/description=3Hs89se3p9RsmJBG/C=US/ST=Pennsylvania/L=Media/O=Daniel Langille/CN=test1.langille.org/emailAddress=postmaster@langille.org i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority 2 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
The only thing I change in the configuration is:
# MY KEYS #ssl_cert =
# My 2048 key ssl_cert =
Current configuration is:
# doveconf -n
# 2.2.6: /usr/local/etc/dovecot/dovecot.conf
# OS: FreeBSD 9.1-RELEASE-p6 amd64
auth_debug = yes
auth_verbose = yes
first_valid_gid = 1001
first_valid_uid = 1001
mail_debug = yes
mail_location = maildir:~/Maildir
mail_privileged_group = mail
passdb {
args = scheme=SHA512-CRYPT /var/db/dovecot.users
driver = passwd-file
}
protocols = imap
service imap-login {
inet_listener imap {
address = 199.233.228.197
}
inet_listener imaps {
address = 199.233.228.197
}
}
ssl_ca =
-- Dan Langille - http://langille.org
I can't recall if we previously discussed it, but, why the fascination with imaps, why not use TLS on 143, or wont that connect either? tried pop3 TLS ? pop3s?
and when you test, use -CAfile /path/to/(startssl's)CA.pem
I see no auth mech statement, so using hte default is limited, IIRC, login is re
auth_mechanisms = plain login
On 10/10/2013 10:51, Dan Langille wrote:
On Oct 9, 2013, at 6:33 PM, Noel Butler wrote:
On 10/10/2013 06:09, Eliezer Croitoru wrote:
I would imaging that 4k bits certificate handshake and validation can take more then 1 sec.. Am I right about it?
hardly
and the size is not his problem.
he was given a test account on my network when I last saw this thread (few weeks back?), that uses startssl, and 4096 certs, his mail.app connected fine.
I would like to investigate that more if you like. Others have experienced problem connected to my test server. I can't believe I've created a non-functional Dovecot configuration.
One avenue I will purse: if I swap from 4096 to 2048, why does it work?
Here is a connection with a 4096 cert:
$ openssl s_ s_client -connect imaps.unixathome.org:993 CONNECTED(00000003) depth=2 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0
Certificate chain 0 s:/description=VwhdJi0sLHP3BDtQ/C=US/ST=Pennsylvania/L=Media/O=Daniel Langille/CN=imaps.unixathome.org/emailAddress=postmaster@unixathome.org i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority 2 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
Here is it with a 2048 cert:
$ openssl s_client -connect imaps.unixathome.org:993 CONNECTED(00000003) depth=2 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0
Certificate chain 0 s:/description=3Hs89se3p9RsmJBG/C=US/ST=Pennsylvania/L=Media/O=Daniel Langille/CN=test1.langille.org/emailAddress=postmaster@langille.org i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority 2 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
The only thing I change in the configuration is:
# MY KEYS #ssl_cert =
# My 2048 key ssl_cert =
Current configuration is:
# doveconf -n # 2.2.6: /usr/local/etc/dovecot/dovecot.conf # OS: FreeBSD 9.1-RELEASE-p6 amd64 auth_debug = yes auth_verbose = yes first_valid_gid = 1001 first_valid_uid = 1001 mail_debug = yes mail_location = maildir:~/Maildir mail_privileged_group = mail passdb { args = scheme=SHA512-CRYPT /var/db/dovecot.users driver = passwd-file } protocols = imap service imap-login { inet_listener imap { address = 199.233.228.197 } inet_listener imaps { address = 199.233.228.197 } } ssl_ca =
On 10/10/2013 13:36, Noel Butler wrote:
I can't recall if we previously discussed it, but, why the fascination with imaps, why not use TLS on 143, or wont that connect either? tried pop3 TLS ? pop3s?
and when you test, use -CAfile /path/to/(startssl's)CA.pem
I see no auth mech statement, so using hte default is limited, IIRC, login is re
auth_mechanisms = plain login
bugger...... stupid webmail... as I was trying to say, IIRC type login is required for ssl ,at least with winblow sclients, try adding the above and see what goes. plain is preferred, but that's because TLS is preferred.
use the local - int- ca > cert.pem and remove the ssl_ca option
On Oct 9, 2013, at 11:43 PM, Noel Butler wrote:
On 10/10/2013 13:36, Noel Butler wrote:
I can't recall if we previously discussed it, but, why the fascination with imaps, why not use TLS on 143, or wont that connect either? tried pop3 TLS ? pop3s? and when you test, use -CAfile /path/to/(startssl's)CA.pem I see no auth mech statement, so using hte default is limited, IIRC, login is re auth_mechanisms = plain login
bugger...... stupid webmail... as I was trying to say, IIRC type login is required for ssl ,at least with winblow sclients, try adding the above and see what goes. plain is preferred, but that's because TLS is preferred.
To be clear, I am using this now:
auth_mechanisms = plain login
use the local - int- ca > cert.pem
I have all three in there.
and remove the ssl_ca option
Removed.
Restarted dovecot.
Mail on the Macbook reports:
"There may be a problem with the mail server or network. Verify the settings for account “Langille” or try again.
The server returned the error: Mail was unable to connect to server “test1.langille.org” using SSL on port 993. Verify that this server supports SSL and that your account settings are correct."
/var/log/maillog shows:
Oct 10 18:25:19 imaps dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=98.111.147.220, lip=199.233.228.197, session=<5fLNH2foGABib5Pc> Oct 10 18:25:19 imaps dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=98.111.147.220, lip=199.233.228.197, session=<5gDPH2fokABib5Pc>
I should have four separate IMAP instances ready later today.
-- Dan Langille - http://langille.org
On Oct 10, 2013, at 2:26 PM, Dan Langille wrote:
On Oct 9, 2013, at 11:43 PM, Noel Butler wrote:
On 10/10/2013 13:36, Noel Butler wrote:
I can't recall if we previously discussed it, but, why the fascination with imaps, why not use TLS on 143, or wont that connect either? tried pop3 TLS ? pop3s? and when you test, use -CAfile /path/to/(startssl's)CA.pem I see no auth mech statement, so using hte default is limited, IIRC, login is re auth_mechanisms = plain login
bugger...... stupid webmail... as I was trying to say, IIRC type login is required for ssl ,at least with winblow sclients, try adding the above and see what goes. plain is preferred, but that's because TLS is preferred.
To be clear, I am using this now:
auth_mechanisms = plain login
use the local - int- ca > cert.pem
I have all three in there.
and remove the ssl_ca option
Removed.
Restarted dovecot.
Mail on the Macbook reports:
"There may be a problem with the mail server or network. Verify the settings for account “Langille” or try again.
The server returned the error: Mail was unable to connect to server “test1.langille.org” using SSL on port 993. Verify that this server supports SSL and that your account settings are correct."
/var/log/maillog shows:
Oct 10 18:25:19 imaps dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=98.111.147.220, lip=199.233.228.197, session=<5fLNH2foGABib5Pc> Oct 10 18:25:19 imaps dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=98.111.147.220, lip=199.233.228.197, session=<5gDPH2fokABib5Pc>
I should have four separate IMAP instances ready later today.
I created those instances. But the new StartCOM 4096-bit cert I created works just fine. So why did the original problem cert fail? I tried it on the new server. It failed there two. Exact same configuration. One cert works. The other cert fails.
So what's different?
The anomaly has been found.
First, the cause of the problem is something I did.
The problem cert is 4098-bits.
Two more than the usual 4096-bits.
DOH.
I must give credit to StartCOM. They pointed out this difference just now. And you can see yourself here: http://dan.langille.org/2013/10/10/one-startcom-cert-works-the-other-does-no...
I'll be raising a bug with Apple.
My thanks for the help. My apologies for the noise.
-- Dan Langille - http://langille.org
On Oct 9, 2013, at 11:36 PM, Noel Butler wrote:
I can't recall if we previously discussed it, but, why the fascination with imaps, why not use TLS on 143, or wont that connect either?
Yes, neither TLS nor IMAPS will connect.
tried pop3 TLS ? pop3s?
I have not.
My next step will be setting up a non-dovecot IMAP server and test the same certificates there.
and when you test, use -CAfile /path/to/(startssl's)CA.pem
When I do that, I get:
$ openssl s_client -t -CAfile /usr/local/share/certs/ca-root-nss.crt -connect imaps.unixathome.org:993 CONNECTED(00000003) depth=2 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority verify return:1 depth=1 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA verify return:1 depth=0 /description=VwhdJi0sLHP3BDtQ/C=US/ST=Pennsylvania/L=Media/O=Daniel Langille/CN=imaps.unixathome.org/emailAddress=postmaster@unixathome.org verify return:1
…. lots snipped
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 4098 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: C9D4AF8FA11CF6EF00E367BC1B45BA465668AEAE595BF3925FC679C7816CE023 Session-ID-ctx: Master-Key: AA0B04AB1C93688C089349A0137D99B5E65303F58A322397509284AE224B37149F76C8C1CD2A7BAC12BEA8E190468598 Key-Arg : None Start Time: 1381428914 Timeout : 300 (sec) Verify return code: 0 (ok)
All looks good?
I see no auth mech statement, so using hte default is limited, IIRC, login is re
auth_mechanisms = plain login
But that's OK, right?
On 10/10/2013 10:51, Dan Langille wrote:
On Oct 9, 2013, at 6:33 PM, Noel Butler wrote:
On 10/10/2013 06:09, Eliezer Croitoru wrote:
I would imaging that 4k bits certificate handshake and validation can take more then 1 sec.. Am I right about it? hardly and the size is not his problem. he was given a test account on my network when I last saw this thread (few weeks back?), that uses startssl, and 4096 certs, his mail.app connected fine. I would like to investigate that more if you like. Others have experienced problem connected to my test server. I can't believe I've created a non-functional Dovecot configuration. One avenue I will purse: if I swap from 4096 to 2048, why does it work? Here is a connection with a 4096 cert: $ openssl s_ s_client -connect imaps.unixathome.org:993 CONNECTED(00000003) depth=2 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0
Certificate chain 0 s:/description=VwhdJi0sLHP3BDtQ/C=US/ST=Pennsylvania/L=Media/O=Daniel Langille/CN=imaps.unixathome.org/emailAddress=postmaster@unixathome.org i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority 2 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
Here is it with a 2048 cert: $ openssl s_client -connect imaps.unixathome.org:993 CONNECTED(00000003) depth=2 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0
Certificate chain 0 s:/description=3Hs89se3p9RsmJBG/C=US/ST=Pennsylvania/L=Media/O=Daniel Langille/CN=test1.langille.org/emailAddress=postmaster@langille.org i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority 2 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority The only thing I change in the configuration is: # MY KEYS #ssl_cert =
-- Dan Langille - http://langille.org
participants (10)
-
Bruno Tréguier
-
Dan Langille
-
Daniel Reinhardt
-
Eliezer Croitoru
-
Jerry
-
Johan Huldtgren
-
LuKreme
-
Noel Butler
-
Oscar del Rio
-
Reindl Harald