[SOLVED] Zimbra 8.7 and letsencrypt ssl

[jorgedlcruz]

Thank you for the tip, the hostname should be a valid fqdn, even if not same domain, you can always use the -d option to create a server.domain.com for example, it will need an A DNS record of course.

Best regards

[headhunter_u23]

Hmm same problem,

switched between users while following your how to https://wiki.zimbra.com/wiki/Installing ... ertificate

all good up to

zmcontrol restart

that failed

used the external fqdn of the server during the cert request process which is resolvable and has a reverse lookup zone PTR.

but no service could start after that and as v1rtu4l I reverted to a previous snapshot taken right before the beginning of your how to.

Even if I won't offer my users a web mail login because they all use mail clients, outlook will probably throw an error message if I go the self-signed certificate route.

This has something to do with /etc/hosts and split dns, at least I think this is the culprit.

dnsmasq was installed prior to zimbra and is working correctly even if the web admin interface throws me an error about dnsmasq not able to start. This is probably the built-in dnsmasq that comes with zimbra that cannot start because the port is already in use but the install process was successful.

Jorge, would you mind showing me a proper example of /etc/hosts for a NAT zimbra server? All how-to's I found were imprecise when it was about the /etc/hosts part.

None of them was indicating at the beginning what IP was external or internal making it difficult to understand what IP or hostname was expected during the setup process.

here's mine except the real hostnames and ips have been modified:
---------------------------------
127.0.0.1 localhost.localdomain localhost
192.168.xx.10 mail.internal.domain mail
192.168.xx.10 hostname.external.domain hostname
# externalIP hostname.external.domain hostname
-------------------------------------
I commented the externalIP because during the initial zimbra setup the system was complaining that no hostname was resolving to this server.

It's not like having that cert installed was essential for my setup but having a clean install even before I start adding any domain and putting the server in production would probably avoid odd problems in the future.

If you tell me I need to reinstall the whole zimbra because the /etc/hosts was incorrect, no worries.

thanks for your help

[headhunter_u23]

ok problem solved

it was indeed the /etc/hosts

that was creating problems

reinstalled the server with a /etc/hosts like that

127.0.0.1 localhost.localdomain localhost
192.168.xx.10 mail.internal.domain mail

then durring the initial configuration of zimbra I used only my internal domain for every single reference to the domain I found in the how to.

Installed zimbra without a glitch this time, I gave up the letsencrypt thing because all it wanted was to generate a certificate using my internal host name, that's not what I want so I used the self signed certificates generated by zimbra and the result is the same but at least my certificate will last longer.

Added a domain, added a user account and tested to see if emails flow. They do.

As the initial problems I had were related to me not following exactly the how to https://blog.zimbra.com/2016/05/install ... 14-04-lts/ that Jorge wrote, I suggest a moderator erases this post and my previous post as it contains no useful information for other users except maybe READ THE F****NG MANUAL FIRST and do exactly what it tells you to do.

Sorry for the annoyance guys,

Thanks a lot

[v1rtu4l]

since re-installing zimbra just because some hosts file was not proper at the time of install is not really an option, wouldn't it be better to have a documentation about the configuration values that should be in place when using the common split dns scenario ?

so basically what the output of zmlocalconfig should look like. where external and internal ip addresses and host names should be set.

when researching some of those issues last week and the week before i often got a google search result link to some wiki.zimbra.com/wiki-site that did not exist anymore (even worse it got me a 404). Some of the helpfull forum postings one finds also reference other forum posts in an older forum format and so if you click on the link in the forum post it will just redirect you to the admin forum instead of the actual post that was linked back in the day.

[phoenix]

since re-installing zimbra just because some hosts file was not proper at the time of install is not really an option, wouldn't it be better to have a documentation about the configuration values that should be in place when using the common split dns scenario ?

There's a wiki article that describes exactly what's needed for a Split DNS and dozens of threads in the forums on the subject.

when researching some of those issues last week and the week before i often got a google search result link to some wiki.zimbra.com/wiki-site that did not exist anymore (even worse it got me a 404). Some of the helpfull forum postings one finds also reference other forum posts in an older forum format and so if you click on the link in the forum post it will just redirect you to the admin forum instead of the actual post that was linked back in the day.

If people insist on doing a 'google search' then they're quite likely to get old, outdated or non-existent results. Instead of doing a google search first, wouldn't it be better to read the product documentation and installation guide and do some research on the resources that Zimbra has provided and to which many forum members have contributed?

[v1rtu4l]

the thing with the documentation like https://wiki.zimbra.com/wiki/Split_DNS for example is, that you there is no notion of internal domain names and it seems as if you expect the server host name and FQDN to be the same as the public FQDN host name that will be used to access zimbra externally. one could of course do it like that but in 99% of the companies i know this is against best practice, one does not simple call an internal server like the external accessible resource. it is quite madness, because this would mean that (without load balancing and virtual hosts) our internal webserver should have be called exactly like the external ressource i.e. web.mycompany.com. Internal domains usually do not have the public top level domains of the public internet, but rather ".local", ".lan" or whatever just to distinguish the access methods. i guess the forum software does not run on a server that has the host name "forms.zimbra.org" or does it ?

it is just very hard to translate these instructions that go hard against many best practices common in many companies to something that still works but does not break company compliance.

another point is that none of the important wiki articles are updated to at least indicate that the instruction is still valid for 8.7, then the mentioned official documentation does not even exist, since there is no admin guide 8.7 for OSE yet.

i know it can be bothersome to read the same questions over and over again in the forum but there are two things you can derive from that: either many people are really stupid and do not know how to read a manual / admin guide (which seems what you seem to have derived from the many posts here) or you could realize that the documentation is either too hard to find, badly worded or not working at all on the customers systems. one of those points you can remediate (the quality of the documentation), one you can't ("stupidity of the people").

iirc the first time i tried to install zimbra like a year ago or so i tried it step by step following the installation guide on a system based on centos 7 with a minimal install and even then things did not work ( i do not mean missing dependencies, but rather ports already being used, rpcbind having problems and so on), things that will even get worse if you do not use a minimal install but a regular linux install. back then i had to use another walkthrough installation guide that i found by using google and that actually worked by for instance installing dnsmasq before zimbras installation with a few other things that are simply not working out of the box with a minimal centos install + zimbra install guide.

i would have guessed that the centos minimal installation is the easiest way to validate if your software does run how you advertise, but obviously your QA does think differently.

[jorgedlcruz]

Thank you v1rtu4l,
This is really great feedback, one thing I am not agree with, is the don't follow best practices in DNS, it's like IPv4, you can use 80.80.80.0/24 with your internal range, yeah you can do it, but is that correct? No it's not, I can write multiple other examples of things you can do internally, but you shouldn't at Corporate level, if you don't trust me, maybe some links can help, as 90% of Companies uses for internal AD and DNS:

• http://www.mdmarra.com/2012/11/why-you- ... -your.html
• https://en.wikipedia.org/wiki/.local
• http://serverfault.com/questions/47087/ ... l-websites

Yes, I know, Microsoft recommends it, once in 2003!!

• https://technet.microsoft.com/en-us/lib ... s.10).aspx

But this not 2003 anymore, and we have more and more applications which requires valid FQDN, like for example if you go for an Exchange Server, you want your Computers or Smartphones connects outside without need to change the server.domain.local to server.domain.com, same for so many other applications, and same for Zimbra, even the SSL Providers stop the .local or non TLD domains:

• http://www.symantec.com/connect/blogs/i ... -need-know

We have wrote on of our first Blog posts about how to install Zimbra, step by step:

• https://blog.zimbra.com/2016/05/install ... 14-04-lts/

But again, this is amazing feedback ad we are going to create a series of videos to help people in how to install Zimbra, and of course the first step, which is DNS configuration, without forget about SSL, etc.

I will keep you updated

Best regards

[v1rtu4l]

thank you jorge for your feedback.
the topic internal fqdn/domain names vs external is usually solved by using application delivery controllers/load balancers like netscaler, kemp loadmaster, bigip f5 and so on which do rewrite the client requests target name to the proper internal domain. The issues you raise if i understand it correct are mainly for the situation when you actually call the domain itself only local, like "hostname.local" and not ".local" as top level domain which is even specified as a link-local domain that will by default not processed by public dns-servers, but is specially reserved (in RFC 6762 from 2013) for this internal use case with the added benefit that those addresses would even be resolved by using internal DNS servers via multicast when the regular DNS servers are not found. But let's just say that i was often enough in german companies bigger than 1000 employees and i have seen the .local tld often enough to not dismiss it, because you have to live with it. i can not tell if it is just old bagagge that those companies keep dragging into the future, but the use case is real and i never heard any of those even moan about problems. personally after reading 3 of your links sadly i do not see any valid reason i could give a customer to not use the .local-tld anymore. the conflict with apple products should by marginable since honestly if you are a big enterprise and rely on anything apple-like protocol like bonjour you are doing it wrong (imho) and the collision of namespaces for zeroconf / apipa setups fall under the same premise for me. who really does use zeroconf in a server environment. the collision with multicast-DNS solutions is negligable as well, since you really do not want to rely on (ipv4) multicast on a larger scale. i always here the network guys moan about the state of multicast implementations on different network hardware vendors. all that remains is the possibility to test the "external" access path by having an external.com way of accessing and testing my server (http://server.external.com) and an internal way of testing the access to the server (http://server,internal.local) which comes in handy when a customer calls and tells us he can't access the server. another reason to stick with two domains (one for external/web-use and one for internal) is that you have it way easier to separate what dns names you will publish on the public DNS servers and which ones will only by resolved internally. Do not get me wrong, i do not want to change your mind about it, but right of now i do not see a very urgent reason to change the current naming schemes i see at customer sites that would actually result in a real world benefit that would justify the effort. thank you though, for pointing me to those links.

the documentation always seems to rely on the hostname "mail.domain.tld" to be resolvable. is it recommended to actually have the hostname be "mail" or is it just as internal alias because many components rely on calling that hostname ?

another heads up: on the main website http://www.zimbra.com there is a menu called resouces, if you choose "tech center" there you expect to be forwarded to the wiki (which would be a better name for tech center anyways, but that does not matter now) and it throws an http error 500 (server error): it links to "https://wiki.zimbra.com/wiki". I actually found out that chrome will throw this error, when trying to access this link on your main site. Edge will open the tech center in the same tab without problems and firefox will open a new tab with the tech center. what i can derive from that is that there is not the same behaviour with 3 commonly used browsers (one might argue about edge here).


i really like zimbra and even though there are not that many people in here responding to posts i like that you always try to stay professional.

[Bashar]

i 'm facing this issue when starting zimbra although slapd seems having the new cert:

Code: Select all

Unable to start TLS: hostname verification failed when connecting to ldap master.

[downtheroad]

i 'm facing this issue when starting zimbra although slapd seems having the new cert:

Code: Select all

Unable to start TLS: hostname verification failed when connecting to ldap master.

is your server's FQDN the same than the FQDN issued for in certificate?

We faced same problem because our LDAP server's FQDN wasn't the same than the FQDN issued for in our *_commercial_* certificate, so finally we decided to change LDAP server's FQDN:

Centos 7
example: zimbra.domain.tld

/etc/hostname
zimbra

/etc/hosts
<internal-ip> zimbra.domain.tld zimbra
and proper DNS record

as *zimbra user*:
/opt/zimbra/libexec/zmsetservername -n zimbra.domain.tld

And since we have mutiserver deploy on each other node we did as zimbra user:
zmlocalconfig -e ldap_host=zimbra.domain.tld
zmlocalconfig -e ldap_master_url=ldap://zimbra.domain.tld:389
zmlocalconfig -e ldap_url=ldap://zimbra.domain.tld:389

Then you can check those records with:
zmlocalconfig -s ldap_host
...
...

With above commands our LDAP service was able to start again using our *_commercal_* certificate