[Dovecot] SSL issues on separate IPs
Hi Timo,
I have set up 2.07 to answer on several different IP's with different SSL certs, like the following :
local 209.132.xx.4 { ssl_cert = *.xxxxx.com.crt-pem-298 ssl_key = .xxxxx.com.key-298 }
I have several of these, and there appears to be a problem with one in particular that is dropping connections, and I'm not sure why.
In this case it is a wildcard cert issued from godaddy, and I have the cert file in pem format with the chain on it. I have another completely separate local IP setup with a different cert on it that works without any problems.
This particular one drops the connection when I try to connect to IMAP using TLS on port 143, or using the IMAP SSL port of 993. When I try it using Thunderbird, I am using the default settings for both tests.
The Thunderbird error I get is "The server has disconnected. The server may have gone down or there may be a network problem." I don't see any errors in the dovecot error log or the system error log, and when using doveadm who to view the current connections, it does not show a connection. I tried enabling the logs for SSL errors, but nothing appears for my IP when attempting to connect.
FreeBSD 8.1 with openssl 0.9.8n. The IP's are on the box and are on the loopback interface if that makes any difference for a direct server return load balancing system.
But, I don't know how that would make a difference since one of the separated IP's works with its cert, and the other one disconnects.
Thanks,
Tim.
Here is my dovecot -n output :
# 2.0.7: /usr/local/etc/dovecot/dovecot.conf # OS: FreeBSD 8.1-STABLE i386 auth_username_format = %Lu auth_username_translation = %@ auth_verbose = yes disable_plaintext_auth = no dotlock_use_excl = yes first_valid_uid = 100 listen = * lock_method = dotlock log_path = /local/logs/dovecot.errors mail_fsync = always mail_gid = 100 mail_location = maildir:%h/Maildir mail_nfs_index = yes mail_nfs_storage = yes mail_plugins = " quota" mail_uid = 100 managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date imapflags notify mmap_disable = yes passdb { args = /bin/checkpassword_dovecot_auth driver = checkpassword } plugin { quota = maildir:User quota quota_rule = Trash:storage=+100M sieve = ~/.dovecot.sieve sieve_after = /home/mailboxes/sieve/to_spam_folder.sieve sieve_dir = ~/Maildir/sieve sieve_extensions = +notify +imapflags } protocols = imap pop3 sieve service auth { unix_listener auth-userdb { group = sn mode = 0600 user = sn } } ssl_cert = *.xxxxx.com.crt-pem-298 ssl_key = .xxxxx.com.key-298 } local 209.132.79.1 { ssl_cert = *.ssl.xxxxx.com.crt-278 ssl_key = .ssl.xxxxx.com.key-278 }
On 3.12.2010, at 2.15, Tim Traver wrote:
local 209.132.xx.4 { ssl_cert = *.xxxxx.com.crt-pem-298 ssl_key = .xxxxx.com.key-298 }
I have several of these, and there appears to be a problem with one in particular that is dropping connections, and I'm not sure why.
Your doveconf output has two and here you say several. So are there multiple ones that work or only one?
This particular one drops the connection when I try to connect to IMAP using TLS on port 143, or using the IMAP SSL port of 993. When I try it using Thunderbird, I am using the default settings for both tests.
Test with openssl s_client -connect localhost:993
The Thunderbird error I get is "The server has disconnected. The server may have gone down or there may be a network problem." I don't see any errors in the dovecot error log or the system error log, and when using doveadm who to view the current connections, it does not show a connection. I tried enabling the logs for SSL errors, but nothing appears for my IP when attempting to connect.
Set verbose_ssl=yes to log more stuff about SSL.
But, I don't know how that would make a difference since one of the separated IP's works with its cert, and the other one disconnects.
Would be easiest if you could test with a simple setup where there is only a single SSL cert. Then it would be clear if the problem has to do with SSL cert itself or about the per-IP settings.
If it has to do with SSL cert, you could also try if you can connect with s_client to openssl s_server running with that cert.
Timo,
ok, I have more info from your suggestion to use the openssl test client connect.
I do have about a dozen more configs on different IP's, and they seem to work. I just didn't include them.
I get the following error when trying to connect to that IP :
[root@mta2]# openssl s_client -connect 209.132.xx.4:993 CONNECTED(00000003) 28579:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_lib.c:188:
which basically says its an SSL handshake error. I did have the verbose_ssl log directive on, and didn't see anything in the dovecot log about the handshake failing. The strange thing is that this cert is used for apache https as well, and there are no issues with the handshake in apache...
I guess I will go and make sure the chain and CA certs are the proper ones from godaddy. I hate chain certs...
So, I guess I'm not sure if it is dovecot or not yet, although it is kind of strange that nothing is written in the logs about the handshake failing.
Tim.
On 12/2/2010 8:47 PM, Timo Sirainen wrote:
On 3.12.2010, at 2.15, Tim Traver wrote:
local 209.132.xx.4 { ssl_cert = *.xxxxx.com.crt-pem-298 ssl_key = .xxxxx.com.key-298 }
I have several of these, and there appears to be a problem with one in particular that is dropping connections, and I'm not sure why. Your doveconf output has two and here you say several. So are there multiple ones that work or only one?
This particular one drops the connection when I try to connect to IMAP using TLS on port 143, or using the IMAP SSL port of 993. When I try it using Thunderbird, I am using the default settings for both tests. Test with openssl s_client -connect localhost:993
The Thunderbird error I get is "The server has disconnected. The server may have gone down or there may be a network problem." I don't see any errors in the dovecot error log or the system error log, and when using doveadm who to view the current connections, it does not show a connection. I tried enabling the logs for SSL errors, but nothing appears for my IP when attempting to connect. Set verbose_ssl=yes to log more stuff about SSL.
But, I don't know how that would make a difference since one of the separated IP's works with its cert, and the other one disconnects. Would be easiest if you could test with a simple setup where there is only a single SSL cert. Then it would be clear if the problem has to do with SSL cert itself or about the per-IP settings.
If it has to do with SSL cert, you could also try if you can connect with s_client to openssl s_server running with that cert.
On 3.12.2010, at 5.46, Tim Traver wrote:
So, I guess I'm not sure if it is dovecot or not yet, although it is kind of strange that nothing is written in the logs about the handshake failing.
Dovecot should log something in the disconnect message. For example:
Dec 03 07:51:09 imap-login: Disconnected (no auth attempts): rip=81.193.158.104, lip=80.83.4.5, TLS handshaking: Disconnected Dec 03 07:51:19 imap-login: Disconnected (no auth attempts): rip=81.193.158.104, lip=80.83.4.5, TLS handshaking: SSL_accept() failed: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
On 12/2/2010 9:52 PM, Timo Sirainen wrote:
On 3.12.2010, at 5.46, Tim Traver wrote:
So, I guess I'm not sure if it is dovecot or not yet, although it is kind of strange that nothing is written in the logs about the handshake failing. Dovecot should log something in the disconnect message. For example:
Dec 03 07:51:09 imap-login: Disconnected (no auth attempts): rip=81.193.158.104, lip=80.83.4.5, TLS handshaking: Disconnected Dec 03 07:51:19 imap-login: Disconnected (no auth attempts): rip=81.193.158.104, lip=80.83.4.5, TLS handshaking: SSL_accept() failed: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
I just checked, and none of those messages were in the dovecot.errors file while I was attempting to make those connections locally with that openssl connect command line option.
It must crash the login process before it gets a chance to write to the log or something...
On 3.12.2010, at 5.55, Tim Traver wrote:
Dec 03 07:51:09 imap-login: Disconnected (no auth attempts): rip=81.193.158.104, lip=80.83.4.5, TLS handshaking: Disconnected Dec 03 07:51:19 imap-login: Disconnected (no auth attempts): rip=81.193.158.104, lip=80.83.4.5, TLS handshaking: SSL_accept() failed: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
I just checked, and none of those messages were in the dovecot.errors file while I was attempting to make those connections locally with that openssl connect command line option.
Those aren't errors (user-generated "errors" won't end up in errors log, because there's nothing sysadmin can do about them anyway). They're the regular disconnect messages in the info log.
It must crash the login process before it gets a chance to write to the log or something...
If login process crashes, master logs an error about it.
On 12/3/2010 12:46 AM, Tim Traver wrote:
Timo,
ok, I have more info from your suggestion to use the openssl test client connect.
I do have about a dozen more configs on different IP's, and they seem to work. I just didn't include them.
I get the following error when trying to connect to that IP :
[root@mta2]# openssl s_client -connect 209.132.xx.4:993 CONNECTED(00000003) 28579:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_lib.c:188:
which basically says its an SSL handshake error. I did have the verbose_ssl log directive on, and didn't see anything in the dovecot log about the handshake failing. The strange thing is that this cert is used for apache https as well, and there are no issues with the handshake in apache...
I guess I will go and make sure the chain and CA certs are the proper ones from godaddy. I hate chain certs...
Good plan. I had a similar problem getting fetchmail to connect to godaddy-cert'ed servers when the certificate chain verification failed because the CA root cert was not present on my client.
To find it, I had to export from the Windows default certstore to get a copy. It did not identify itself very well, the OU was "ValiCert Class 2 Policy Validation Authority" but it appeared in the certmgr gui only as "http://www.valicert.com" (under 3rd party root certs). I believe the same one is in the Firefox certstore though, you can probably find it there.
So, I guess I'm not sure if it is dovecot or not yet, although it is kind of strange that nothing is written in the logs about the handshake failing.
Tim.
On 12/2/2010 8:47 PM, Timo Sirainen wrote:
On 3.12.2010, at 2.15, Tim Traver wrote:
local 209.132.xx.4 { ssl_cert =*.xxxxx.com.crt-pem-298 ssl_key =.xxxxx.com.key-298 }
I have several of these, and there appears to be a problem with one in particular that is dropping connections, and I'm not sure why. Your doveconf output has two and here you say several. So are there multiple ones that work or only one?
This particular one drops the connection when I try to connect to IMAP using TLS on port 143, or using the IMAP SSL port of 993. When I try it using Thunderbird, I am using the default settings for both tests. Test with openssl s_client -connect localhost:993
The Thunderbird error I get is "The server has disconnected. The server may have gone down or there may be a network problem." I don't see any errors in the dovecot error log or the system error log, and when using doveadm who to view the current connections, it does not show a connection. I tried enabling the logs for SSL errors, but nothing appears for my IP when attempting to connect. Set verbose_ssl=yes to log more stuff about SSL.
But, I don't know how that would make a difference since one of the separated IP's works with its cert, and the other one disconnects. Would be easiest if you could test with a simple setup where there is only a single SSL cert. Then it would be clear if the problem has to do with SSL cert itself or about the per-IP settings.
If it has to do with SSL cert, you could also try if you can connect with s_client to openssl s_server running with that cert.
Timo (and others),
It turns out that we had a different set of chain and root ca certs from godaddy than was required for the proper chain. It seemed to work for apache, but failed for dovecot...
I really dislike godaddy...
thanks for the help,
Tim.
I guess I will go and make sure the chain and CA certs are the proper ones from godaddy. I hate chain certs...
Good plan. I had a similar problem getting fetchmail to connect to godaddy-cert'ed servers when the certificate chain verification failed because the CA root cert was not present on my client.
To find it, I had to export from the Windows default certstore to get a copy. It did not identify itself very well, the OU was "ValiCert Class 2 Policy Validation Authority" but it appeared in the certmgr gui only as "http://www.valicert.com" (under 3rd party root certs). I believe the same one is in the Firefox certstore though, you can probably find it there.
So, I guess I'm not sure if it is dovecot or not yet, although it is kind of strange that nothing is written in the logs about the handshake failing.
Tim.
participants (3)
-
Tim Traver
-
Timo Sirainen
-
Tom Talpey