Ubuntu 14.04 - 8.7.4 imapS issue after upgrade.

Discuss your pilot or production implementation with other Zimbra admins or our engineers.
Robstarusa
Posts: 14
Joined: Sat Sep 13, 2014 1:42 am

Ubuntu 14.04 - 8.7.4 imapS issue after upgrade.

Postby Robstarusa » Sun Mar 12, 2017 4:04 pm

When I was running 8.6.0 (OSS) I was certified A on the Qualsys SSL check. After upgrading, I had DH ciphers & other settings reverted to enabled & went back to a capped grade of B.

At this point Zimbra was working perfectly except for the weaker ciphers (eg: Tested in/outbound mail, web access, imaps via proxy) I then went to go & adjust settings via zmprov & I think I messed something up.

Everything works EXCEPT IMAP Proxy (nginx) with SSL.

If I try to connect to port 993, The IMAP client times out after sending the username. If I connect directly to port 7993, everything works great. I'm trying to find out what is wrong.

Some tests:
(server name/certificate replaced with variable)

Code: Select all

$ openssl s_client -connect ${myserverfqdn}:993
CONNECTED(00000003)
depth=3 /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=${myserverfqdn}
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
${lots_of_text}
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/OU=PositiveSSL/CN=${myserverfqdn}
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 6110 bytes and written 328 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES128-SHA
    Session-ID: 5FDDFCD5438C1CEBA958110DFEF936A483C3332DF7FE6D711A649E71FFEEE644
    Session-ID-ctx:
    Master-Key: DC422F02D7BBA87DC4081C7BC3F22A8BA318DACE102825CC33D183FDC3AC3A6A07CDC2A568D8CDFBC336353EAC214E0B
    Key-Arg   : None
    Start Time: 1489333158
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
* OK IMAP4rev1 proxy server ready


I don't know where the self signed cert is coming from since I use a COMODO signed cert..?

Logs form /opt/zimbra/log/nginx.log (username/domain edited)

Code: Select all

2017/03/12 10:47:00 [info] 27028#0: *282 client 192.168.75.62:34394 connected to 192.168.75.87:993
2017/03/12 10:47:00 [info] 27028#0: *282 peer closed connection in SSL handshake while SSL handshaking to lookup handler, client: 192.168.75.62:34394, server: 192.168.75.87:993, login: "${myusername}@${mydomain.net}"


Here are logs from a failing Thunderbird client (I use this on mac):

Code: Select all

65699840[123f163a0]: ImapThreadMainLoop entering [this=1c941c00]
-1233550400[1001260b0]: 1c941c00:${myserverfqdn}:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
65699840[123f163a0]: 1c941c00:${myserverfqdn}:NA:ProcessCurrentURL: entering
65699840[123f163a0]: 1c941c00:${myserverfqdn}:NA:ProcessCurrentURL:imap://${myusername}%40${mydomain.net}@${myserverfqdn}:993/select%3E/INBOX:  = currentUrl
65699840[123f163a0]: ReadNextLine [stream=23d89150 nb=35 needmore=0]
65699840[123f163a0]: 1c941c00:${myserverfqdn}:NA:CreateNewLineFromSocket: * OK IMAP4rev1 proxy server ready
65699840[123f163a0]: 1c941c00:${myserverfqdn}:NA:SendData: 1 capability
65699840[123f163a0]: ReadNextLine [stream=23d89150 nb=273 needmore=0]
65699840[123f163a0]: 1c941c00:${myserverfqdn}:NA:CreateNewLineFromSocket: * CAPABILITY ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE ESEARCH ESORT I18NLEVEL=1 ID IDLE IMAP4rev1 LIST-EXTENDED LITERAL+ MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN LIST-STATUS XLIST AUTH=PLAIN
65699840[123f163a0]: ReadNextLine [stream=23d89150 nb=16 needmore=0]
65699840[123f163a0]: 1c941c00:${myserverfqdn}:NA:CreateNewLineFromSocket: 1 OK completed
65699840[123f163a0]: try to log in
65699840[123f163a0]: IMAP auth: server caps 0x10e0c7725, pref 0x1006, failed 0x0, avail caps 0x1004
65699840[123f163a0]: (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN = 0x200000, PLAIN = 0x1000,
  LOGIN = 0x2, old-style IMAP login = 0x4, auth external IMAP login = 0x20000000, OAUTH2 = 0x800000000)
65699840[123f163a0]: trying auth method 0x1000
65699840[123f163a0]: got new password
65699840[123f163a0]: IMAP: trying auth method 0x1000
65699840[123f163a0]: PLAIN auth
65699840[123f163a0]: 1c941c00:${myserverfqdn}:NA:SendData: 2 authenticate plain
65699840[123f163a0]: ReadNextLine [stream=23d89150 nb=4 needmore=0]
65699840[123f163a0]: 1c941c00:${myserverfqdn}:NA:CreateNewLineFromSocket: +
65699840[123f163a0]: 1c941c00:${myserverfqdn}:NA:SendData: Logging suppressed for this command (it probably contained authentication information)
-1233550400[1001260b0]: proposed url = INBOX folder for connection  has To Wait = TRUE can run = FALSE
-1233550400[1001260b0]: queuing url:imap://${myusername}@${mydomain}@${myservefqdn}:993/select>/INBOX
-1233550400[1001260b0]: considering playing queued url:imap://${myusername}@${mydomain}@${myservefqdn}:993/select>/INBOX
-1233550400[1001260b0]: creating protocol instance to play queued url:imap://${myusername}@${mydomain}@${myservefqdn}:993/select>/INBOX
-1233550400[1001260b0]: proposed url = INBOX folder for connection  has To Wait = TRUE can run = FALSE
-1233550400[1001260b0]: failed creating protocol instance to play queued url:imap://${myusername}@${mydomain}@${myservefqdn}:993/select>/INBOX
-1233550400[1001260b0]: proposed url = INBOX folder for connection  has To Wait = TRUE can run = FALSE
-1233550400[1001260b0]: queuing url:imap://${myusername}@${mydomain}@${myservefqdn}:993/select>/INBOX
-1233550400[1001260b0]: considering playing queued url:imap://${myusername}@${mydomain}@${myservefqdn}:993/select>/INBOX
-1233550400[1001260b0]: creating protocol instance to play queued url:imap://${myusername}@${mydomain}@${myservefqdn}:993/select>/INBOX
-1233550400[1001260b0]: proposed url = INBOX folder for connection  has To Wait = TRUE can run = FALSE
-1233550400[1001260b0]: failed creating protocol instance to play queued url:imap://${myusername}@${mydomain}@${myservefqdn}:993/select>/INBOX
65699840[123f163a0]: ReadNextLine [stream=23d89150 nb=0 needmore=1]
65699840[123f163a0]: 1c941c00:${myserverfqdn}:NA:CreateNewLineFromSocket: clearing IMAP_CONNECTION_IS_OPEN - rv = 804b0010
65699840[123f163a0]: 1c941c00:${myserverfqdn}:NA:TellThreadToDie: close socket connection
65699840[123f163a0]: 1c941c00:${myserverfqdn}:NA:CreateNewLineFromSocket: (null)
65699840[123f163a0]: authlogin failed
65699840[123f163a0]: marking auth method 0x1000 failed
65699840[123f163a0]: IMAP auth: server caps 0x10e0c7725, pref 0x1006, failed 0x1000, avail caps 0x4
65699840[123f163a0]: (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN = 0x200000, PLAIN = 0x1000,
  LOGIN = 0x2, old-style IMAP login = 0x4, auth external IMAP login = 0x20000000, OAUTH2 = 0x800000000)
65699840[123f163a0]: trying auth method 0x4
65699840[123f163a0]: login failed entirely
65699840[123f163a0]: 1c941c00:${myserverfqdn}:NA:ProcessCurrentURL: aborting queued urls
65699840[123f163a0]: ImapThreadMainLoop leaving [this=1c941c00]


Any other logs you guys need? zmprov variables? It looks like auth is failing but the client never gets a message of "wrong password" or anything else, it just hangs forever (gmail client android 6 as well as thunderbird on mac show same symptoms)


User avatar
L. Mark Stone
Elite member
Elite member
Posts: 1893
Joined: Wed Oct 09, 2013 11:35 am
Location: Portland, Maine
ZCS/ZD Version: 8.8.10 Network Edition
Contact:

Re: Ubuntu 14.04 - 8.7.4 imapS issue after upgrade.

Postby L. Mark Stone » Sun Mar 12, 2017 5:12 pm

In our experience the self-signed error you quote is... erroneous and not the root cause.

We often see this when plain-text login is turned off, which is why mailboxd can handle the IMAP request but nginx cannot pass it through.

In the Admin Console: Configure > Global Settings > IMAP and make sure all three tick boxes are checked (Enable IMAP, Enable IMAP SSL, Enable IMAP Clear Text Login).

Keep us posted!

Mark
___________________________________
L. Mark Stone
Mission Critical Email - Zimbra VAR/BSP/Training Partner https://www.missioncriticalemail.com/
Zeta Alliance http://www.zetalliance.org/
Robstarusa
Posts: 14
Joined: Sat Sep 13, 2014 1:42 am

Re: Ubuntu 14.04 - 8.7.4 imapS issue after upgrade.

Postby Robstarusa » Sun Mar 12, 2017 7:39 pm

I checked and I think the global settings had imap disabled. I enabled it, and made sure it was enabled for the domain, clicked save (in the gui) and rebooted the server.

Same symptoms. Any other ideas?

After reboot, I checked the GUI & see all 3 boxes for IMAP ("Enable Imap", "Enable SSL for IMAP", and "Enable clear text login") are checked.

Updated logs from openssl testing...

Code: Select all

$ openssl s_client -connect ${myserverfqdn}:993
CONNECTED(00000003)
depth=3 /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=zim.hendelman.net
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
${long_text_deleted}
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/OU=PositiveSSL/CN=${myserverfqdn}
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 6110 bytes and written 328 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES128-SHA
    Session-ID: BC45CFCB17BE1992925F31325DA08C74A5131EDE5ED91316CA107D9E8886B5B7
    Session-ID-ctx:
    Master-Key: 012FDD7100023492FBCEE240572E4A7C3D6551C2A27149172E36710771020A80699B722944E57117566F0EAB8442E72A
    Key-Arg   : None
    Start Time: 1489348184
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
* OK IMAP4rev1 proxy server ready


Updated logs from /opt/zimbra/log/nginx.log

Code: Select all

2017/03/12 14:34:41 [info] 3212#0: *36 peer closed connection in SSL handshake while SSL handshaking to lookup handler, client: 192.168.75.36:56397, server: 192.168.75.87:993, login: "${myusername}@${mydomain}"
2017/03/12 14:34:46 [info] 3212#0: *38 client 192.168.75.36:56398 connected to 192.168.75.87:993


Updated Thunderbird logs (look the same to me):

Code: Select all

249573376[11e415b40]: ImapThreadMainLoop entering [this=7914e00]
-1233550400[10012df90]: 7914e00:${myserverfqdn}:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
249573376[11e415b40]: 7914e00:${myserverfqdn}:NA:ProcessCurrentURL: entering
249573376[11e415b40]: 7914e00:${myserverfqdn}:NA:ProcessCurrentURL:imap://${myusername}@${mydomain}@${myserverfqdn}:993/select%3E/INBOX:  = currentUrl
249573376[11e415b40]: ReadNextLine [stream=1e2cef30 nb=35 needmore=0]
249573376[11e415b40]: 7914e00:${myserverfqdn}:NA:CreateNewLineFromSocket: * OK IMAP4rev1 proxy server ready
249573376[11e415b40]: 7914e00:${myserverfqdn}:NA:SendData: 1 capability
249573376[11e415b40]: ReadNextLine [stream=1e2cef30 nb=273 needmore=0]
249573376[11e415b40]: 7914e00:${myserverfqdn}:NA:CreateNewLineFromSocket: * CAPABILITY ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE ESEARCH ESORT I18NLEVEL=1 ID IDLE IMAP4rev1 LIST-EXTENDED LITERAL+ MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN LIST-STATUS XLIST AUTH=PLAIN
249573376[11e415b40]: ReadNextLine [stream=1e2cef30 nb=16 needmore=0]
249573376[11e415b40]: 7914e00:${myserverfqdn}:NA:CreateNewLineFromSocket: 1 OK completed
249573376[11e415b40]: try to log in
249573376[11e415b40]: IMAP auth: server caps 0x10e0c7725, pref 0x1006, failed 0x0, avail caps 0x1004
249573376[11e415b40]: (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN = 0x200000, PLAIN = 0x1000,
  LOGIN = 0x2, old-style IMAP login = 0x4, auth external IMAP login = 0x20000000, OAUTH2 = 0x800000000)
249573376[11e415b40]: trying auth method 0x1000
249573376[11e415b40]: got new password
249573376[11e415b40]: IMAP: trying auth method 0x1000
249573376[11e415b40]: PLAIN auth
249573376[11e415b40]: 7914e00:${myserverfqdn}:NA:SendData: 2 authenticate plain
249573376[11e415b40]: ReadNextLine [stream=1e2cef30 nb=4 needmore=0]
249573376[11e415b40]: 7914e00:${myserverfqdn}:NA:CreateNewLineFromSocket: +
249573376[11e415b40]: 7914e00:${myserverfqdn}:NA:SendData: Logging suppressed for this command (it probably contained authentication information)


Is it possible that nginx imap proxy just isn't redirecting at all or doesn't have a destination (or incorrect destination) to redirect to?
User avatar
jorgedlcruz
Zimbra Alumni
Zimbra Alumni
Posts: 2769
Joined: Thu May 22, 2014 4:47 pm

Re: Ubuntu 14.04 - 8.7.4 imapS issue after upgrade.

Postby jorgedlcruz » Sun Mar 12, 2017 8:01 pm

Try this

Code: Select all

./libexec/zmproxyconfig -e -m -o -i 7143:143:7993:993 -p 7110:110:7995:995 -H `zmhostname`
zmcontrol restart


Best regards
Jorge de la Cruz https://jorgedelacruz.es
Technical Marketing Manager at Zimbra/Synacor https://www.zimbra.com/
Robstarusa
Posts: 14
Joined: Sat Sep 13, 2014 1:42 am

Re: Ubuntu 14.04 - 8.7.4 imapS issue after upgrade.

Postby Robstarusa » Sun Mar 12, 2017 8:14 pm

I ran the zmproxconfig (line above) as user "zimbra" and it returned me to the CLI. I then did a zmcontrol restart, but it did not fix the issue.

Symptoms seem to be the same.

I appreciate the suggestions guys. Keep them coming!

Thank you,

Robert
Robstarusa
Posts: 14
Joined: Sat Sep 13, 2014 1:42 am

Re: Ubuntu 14.04 - 8.7.4 imapS issue after upgrade.

Postby Robstarusa » Mon Mar 13, 2017 9:59 pm

Anyone have any ideas at what I should be looking at? Should I turn off the nginx proxy entirely since the redirected (imaps) 7993 port works?

Edit: It seems to work from my imap client, but not for me testing via openssl. Maybe imaps isn't running on 7993 but imap is?

I get this:

Code: Select all

$ openssl s_client -connect ${myserverfqdn}:7993
CONNECTED(00000003)
58645:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.30.2/src/ssl/s23_clnt.c:618:


Actually 7993 (openssl test) works from localhost to localhost, but not from off of the server. However I _do_ get a response on 7993 from an actual imap client to 7993 & I am able to pull e-mail. From reading https://wiki.zimbra.com/wiki/Ports, it looks like external clients aren't supposed to access 7993 directly, just 993.

I guess then, my questions are:

Is port 7993 supposed to be testable/listenable from remote hosts? It works with an imap client, although maybe that imap client is falling back to a non-ssl connection method.

Is the nginx proxy listening on 993 supposed to communicate with the actual imap daemon (internally? via localhost I assume?) via ssl or not? Maybe this got misconfigured when I was trying to change my security settings via zmprov.
Robstarusa
Posts: 14
Joined: Sat Sep 13, 2014 1:42 am

Re: Ubuntu 14.04 - 8.7.4 imapS issue after upgrade.

Postby Robstarusa » Mon Mar 13, 2017 11:30 pm

Well guys, I think I'm about 90% of the way there.

If I connect with openssl s_client on the localhost to 7993 & do a manual login it works as such:

This was executed locally on the zimbra server.

Code: Select all

$ openssl s_client -connect 192.168.75.87:7993 -crlf
CONNECTED(00000003)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=${myserverfqdn}
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
${snipped-out}
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/OU=PositiveSSL/CN=${myserverfqdn}
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5895 bytes and written 426 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: ${snipped_out}
    Session-ID-ctx:
    Master-Key: ${snipped_out}
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1489447360
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
* OK ${myserverfqdn} Zimbra IMAP4rev1 server ready
? LOGIN ${mylogin}@${mydomain} ${mypassword}
? OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+ LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN completed


However if I do the same thing to port 993 (also from localhost), after my login/password it just hangs & this is generated in the nginx log:

Code: Select all

2017/03/13 18:25:04 [info] 25715#0: *5 peer closed connection in SSL handshake while SSL handshaking to lookup handler, client: 192.168.75.36:60066, server: 192.168.75.87:993, login: "${mylogin}@${mydomain}"


It seems the issue is the "lookup handler" SSL handshake. Looking for information on the lookup handler, I found this: https://wiki.zimbra.com/wiki/Zimbra_Pro ... mbra_Proxy

Checking my lookup handler I get:

Code: Select all

$ grep zm_lookup_handlers /opt/zimbra/conf/nginx/includes/nginx.conf.zmlookup
    zm_lookup_handlers  https://192.168.75.87:7072/service/extension/nginx-lookup;


SSL certs AFAIK require names, not ip addresses, so I'm guessing the above lookup handler URL should be https://${myserverfqdn}:7072/service/extension/nginx-lookup;

Can one of you guys confirm this (from your working reverse-proxied IMAP server)? If this is the case, then I just need to figure out which zmprov variable I need to set to correct this. If your lookup handler is indeed an IP I think I need further info on how to troubleshoot the SSL handshake issue.
User avatar
jorgedlcruz
Zimbra Alumni
Zimbra Alumni
Posts: 2769
Joined: Thu May 22, 2014 4:47 pm

Re: Ubuntu 14.04 - 8.7.4 imapS issue after upgrade.

Postby jorgedlcruz » Tue Mar 14, 2017 12:52 am

Hi,
I just fixed that issue in a Customer:

Code: Select all

/opt/zimbra/libexec/zmproxyconfig -e -m -H yourzmhostname
zmcontrol restart

And that works
Jorge de la Cruz https://jorgedelacruz.es
Technical Marketing Manager at Zimbra/Synacor https://www.zimbra.com/
Robstarusa
Posts: 14
Joined: Sat Sep 13, 2014 1:42 am

Re: Ubuntu 14.04 - 8.7.4 imapS issue after upgrade.

Postby Robstarusa » Tue Mar 14, 2017 2:51 am

That didn't help either.

I've now got the same error for the web interface so that is broken as well.

I now have no way to retreve email unless I hit port 7993 (imaps) or 8443 (web).
Last edited by Robstarusa on Tue Mar 14, 2017 3:45 am, edited 1 time in total.
Robstarusa
Posts: 14
Joined: Sat Sep 13, 2014 1:42 am

Re: Ubuntu 14.04 - 8.7.4 imapS issue after upgrade.

Postby Robstarusa » Tue Mar 14, 2017 3:45 am

I've decided to give up for now and I've restored my pre-upgrade image from March 10th. I've lost 3 days of e-mail but at least I have a working server again.

Thanks for the help guys.

Return to “Administrators”

Who is online

Users browsing this forum: No registered users and 31 guests