Upgrading to Zimbra Collaboration 8.6.0 from 8.5.0 : Error: Unable to create a successful TLS connection to the ldap masters

[maurizio.marini.sancostanzo]

This is the old ca, replaced this night (I am GMT+1)

As you can see, it was regenerated 1 years ago and (I can't understand why) expiring after 1 year:

Not Before: Feb 17 18:07:59 2014 GMT

Not After : Feb 17 18:07:59 2015 GMT



/usr/bin/openssl x509 -noout -text -in ca.pem



Certificate:

Data:

Version: 1 (0x0)

Serial Number: 17765305579206629319 (0xf68b0b4cb6e057c7)

Signature Algorithm: sha1WithRSAEncryption

Issuer: C=US, ST=N/A, L=N/A, O=Zimbra Collaboration Suite, OU=Zimbra Collaboration Suite, CN=mailz.e-mid.it

Validity

Not Before: Feb 17 18:07:59 2014 GMT

Not After : Feb 17 18:07:59 2015 GMT

Subject: C=US, ST=N/A, L=N/A, O=Zimbra Collaboration Suite, OU=Zimbra Collaboration Suite, CN=mailz.e-mid.it

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (1024 bit)

Modulus:

00:e5:da:3a:2c:99:d1:28:ed:8c:9c:95:2a:8e:fc:

aa:5f:13:d7:e8:56:6260:21:90:b8:b9:c4:53:

20:c1:b7:04:2c:6d:20:20:1a:3e:b1:51:54:0a:e9:

10:ea:06:6e:fc:2b:9e:5a:e6:73:0b:ef:c2:80:cf:

14:6b:da:56:5c:37:e9:96:41:21:03:c0:bc:cf:78:

55:98:75:f1:77:7f:7c:4a:85:99:88:93:5e:1e:ac:

de:ff:c9:87:4f:3d:43:90:d8:e2:49:3a:79:a0:9c:

ac:dd:b9:18:77:32:16:b7:cf:fb:49:9150:b0:

fb:02:1d:db:7a:c2:e8:f4:c9

Exponent: 65537 (0x10001)

Signature Algorithm: sha1WithRSAEncryption

2d0f:c5:07:dd:94:54:06:3a:29:8e:5c:d9:f9:d6:38:56:

f9:32:39:8e:48:af:cc:d1:e0:4a:4f:83:6b:be:10:da:ff:dd:

ba:87:3f:c3:7a:2a:c3:47:f2:ef:4d:9d:67:f1:cc:eb:d6:1a:

82:30:34:9f:9e:24:1c:ec:55:c5:90:5b:42:1c:55:68:97:44:

21:47:76:d9:82:d1:be:67:3c:32:46:c5:ee:e2:10:11:68:51:

67:dc:dc:b4:e6:e7:4f:82:8f:e1:7c:4d:97:d9:9b:db:16:c2:

34:6f:e1:ec:44:0f:3e:6d:47:57:88:ba:1a:ac:aa:30:fc:8a:

b9:3b

[jorgedlcruz]

Hi Maurizio,

Maybe the command /opt/zimbra/bin/zmcertmgr createca creates a valid CA for only 1 year, even if the SSL certificate is for more years, strange. Is your new CA valid only for 1 year? Maybe we should fill a bug. CA and SSL certificate needs to have the same years expiration, I think makes more sense.



Best regards

[maurizio.marini.sancostanzo]

The new one, instead, expires on 2020 and is 2048 bits

Public-Key: (2048 bit)



maybe it was an issue a 1024 Public-key?



/usr/bin/openssl x509 -noout -text -in /opt/zimbra/conf/ca/ca.pem

Certificate:

Data:

Version: 3 (0x2)

Serial Number: 14301086933727681613 (0xc677aacbbad19c4d)

Signature Algorithm: sha256WithRSAEncryption

Issuer: C=US, ST=N/A, L=N/A, O=Zimbra Collaboration Server, OU=Zimbra Collaboration Server, CN=mailz.e-mid.it

Validity

Not Before: Feb 3 01:09:30 2015 GMT

Not After : Feb 2 01:09:30 2020 GMT

Subject: C=US, ST=N/A, L=N/A, O=Zimbra Collaboration Server, OU=Zimbra Collaboration Server, CN=mailz.e-mid.it

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (2048 bit)

Modulus:

00:d5:ef:7f:74:7b:8d:5c:6a:a3:a2:ee:94:2d:eb:

e8:e8:4a:e2:05:9c:66:21:6f:b2:53:98:e2:51:cf:

8e:43:95:54:08:92:20:cf:16:71:47:38:e1:dd:5e:

18:b1:03:ed:28:90:cc:16:d2:01:55:a6:61:62:24:

94:8a:f6:29:4e:18:22:42:0f:57:93:bc:27:f0:fb:

fe:94:17:d0:90:48:32:48:15:47:8d:51:5f:c7:33:

14:5f:36:55:a2:19:4f:1a:e1:19:12:a8:a1:0f:29:

cf:fa:28a5:69:6e:bf:f4:1a:90:26:83:7c:97:

12:66:1c:b7:71:ff:2b:fb:c6:43:87:4c:e7:7a:74:

a7:f7:b9:83:c1:56:f3:11:65:62:0a:98:92:21:26:

38:f1:2b:92:60:4a:ba:88:9c:b0:e3:01:62:e5:97:

3b:83:72:c5:4f:8e:74:ed:4f:46:e5:c7:84:8b:75:

71:d0:e2:96:3d:e3:1a:03:e9:e8:4a:4e:06:60:a7:

ca:a8:d5:14:95:69:be:64:9f:ec:63:25:fb:96:6d:

3a:50:3d:7e:9d:a0:9d:74:45:96:38:72:71:c7:a2:

d8:2c:75:8a:c4:9c:e4:d842:63:68:ad:be:01:

c8:51:eb:7a:a8:a3:22:25:94:97:9c:c0:e9:c5:aa:

fc:c1

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Subject Key Identifier:

3C:C7:EB:03:EB:73:13:EA:28:C4:D0:50:09:FF:69:C0:D8:E3:5C:98

X509v3 Authority Key Identifier:

keyid:3C:C7:EB:03:EB:73:13:EA:28:C4:D0:50:09:FF:69:C0:D8:E3:5C:98

DirName:/C=US/ST=N/A/L=N/A/O=Zimbra Collaboration Server/OU=Zimbra Collaboration Server/CN=mailz.e-mid.it

serial:C6:77:AA:CB:BA:D1:9C:4D



X509v3 Basic Constraints:

CA:TRUE

Signature Algorithm: sha256WithRSAEncryption

bc:63:16:34:13:b8:39:ca:75d1:01:67:c187:cf:e5:

90:fe:a8:f6:01:3f:79:50:1b:e2:a0:d1:9c:ad:3c:5b:87:f3:

11:94:ce:32:b1:6a:ac:01:fb:a8:fe:4b:b6:d8:2e:20:b3:e9:

1e:e1:4f:8b:0c:43:0e:35:47:40:e5:73:27:c9:3e:d8:51:2b:

6a:19:8d:bf:6d:20:96:17:4d:6c:ac:12:bb:77:96:49:fb:4e:

94:2b:35:be:8d:04:4d:6a:df:60:b8:71:75:56:52:3a:e2:c0:

22:28:20:4f:b3:2b:95:8f:34:2f:14:12:dd:df:ea:e8:64:c9:

53:b2:70:9b:a4:67:8b:9e:70:5c:d1:f7:47:2e:19:95:1c:af:

9d:b2:62:ef:fa:9f:d8:7b:a8:2c:51:3e:3a:da:7a:9c:19:bf:

3c:4f:fc:fe:d2:e3:55:97:90:0d:f4:54:f8:0e:15:9e:5d:ee:

71:4f:a5:23:45:47:9b:2d:e2:8d:d4:bb:0e:54:82:05:04:c0:

51:25:35:d9:41:72:cc:22:ca:09:37:eb:0d:9e:c1:ae:7e:5e:

19:d5:ed:d4:c4:1d:2f:3c:73:36:5f:3a:83:f8:13:d0:0f:fb:

24:9b:c1:3e:84:1e:1d:75:eb:fb:a7:bc:7f:5d:08:cb:1b:13:

4c:96:c9:ed

[jorgedlcruz]

I think that it was both, a problem with a 1024key and also the expiration date.

[maurizio.marini.sancostanzo]

bug was 60880

but 5 years isn't enough



http://zimbradoc.intalio.pl/uploads/ima ... _8.0.0.pdf

60880 Changed the CA time period from 365d to 1825d (5 years).

[jdp459]

Any solution to this?
We support multiple email domains. The main domain is ours but the client has commercial certs for their domain - which do not match the hostname.

I am in the process of splitting these domains, but the primary domain with the cert is NOT the hostname today. I'd planned to complete the upgrade, then migrate all the non-cert domain accounts to a freshly built 8.6.0 (already up). Then on the older machine, remove the non-cert accounts.  I hadn't planned to rename the hostname - both will be at different facilities when I'm done, but suppose that can be done.  We use email gateways, so the MX records point to the correct front-ends - NOT directly to Zimbra.

[Travis Kensil]

JDP,

I as well would like a better answer than re-generation of certs. or bypassing install checks. I also noticed Zimbra never documented this change except for a random bugzilla post, nothing official though from what I can see.



Jorge,

Can we get an update from Zimbra as to why the change and what can be done in a production environment to resolve this or revert previous behavior?



We have a commercially-signed certificate that is valid and has survived multiple updates until now.



Thanks!

[jorgedlcruz]

Hi Travis,

How is your DNS environment? I mean what is the hostname of your server and the FQDN of the SSL?



Best regards

[Travis Kensil]

Jorge,



We have an internal server name for our Zimbra server but the cert is using our public facing FQDN. We have been running this way for multiple versions of Zimbra so I guess I am curious why the change and more importantly why no clear documentation this was the case besides a basic bugzilla bug filing? https://bugzilla.zimbra.com/show_bug.cgi?id=95420



My other concern is I have seen examples on the forum/bugzilla site of folks reporting even after re-issuing their cert. it wasn't working correctly.



I think it is a bit crazy that Zimbra would expect us to re-issue certs just to perform an upgrade?



I am just wondering if there has been any progress on this issue and what the rational is?



Thanks!

[liverpoolfcfan]

We had exactly the same issue, and as with you we have had this configuration for many zimbra releases (since 6.0.4). As it is an independent server I ended up giving up on this and just changing the internal name of the server to match the external one and using split DNS so the cert is valid for both. I would really have preferred not to have to resort to this and would love to understand why this change was forced upon us.