This Server Does Not Provide A Secure (SSL) While adding Mac to network???

It appears you didn't obtain a signed certificate for your server from a certificate signing authority. The server has generated a self-signed certificate which is fine for a local network. To trust this cert on the client, you need to click ok to trust this server's certificate.

Your DNS is incorrectly configured. It's in .local, to start with. That is an RFC-reserved domain, and not available for use with in a (unicast, tradition) DNS server configuration. It's reserved for Bonjour/mulitcast DNS/mDNS usage.

To verify local DNS services, launch Terminal.app from Applications > Utilities and issue the following harmless diagnostic command:

sudo changeip -checkhostname

That'll require an administrative password, might show a one-time informational message around the use of sudo, and will then display some network information and then an indication that no changes are required, or that there are DNS or network problems.

Again, do not use .local nor .arpa as your domain.

Unfortunate, if DNS is incorrectly configured, then various services including the mail server and Open Directory also tend to have problems, and all SSL-based security is dependent on proper DNS configurations.

Dmanlive wrote:

Thanks for the input. Considering this network is only for internal LAN activity I was under the impression .local was ok.

That would be an incorrect assumption.

Certficates and distributed authentication and network encryption — used even locally — are tied to DNS.

Without valid DNS (running somewhere) on a NAT'd network, things tend to go weird.

Here is how to set up DNS on OS X Server.

I'd recommend using a real domain you've registered, or a subdomain of a domain you've registered, but it is technically possible to use a made-up and completely bogus top-level domain.

You could potentially use the currently-bogus top-level domain .dmanlive here and for free, but with the rate that ICANN has been adding new and real top-level domains, pick carefully as this approach is not without risk.

If your "public" registered domain is example.com for instance, I might see if you could reserve example.net or example.org or one of the other gazillion new ICANN extensions, and use name that internally. (This way you also don't need to rebuild the internal network, if you should ever want or need to expose these domain names to the wild, too.)

PS and FWIW, if you want or need to obfuscate, please consider using one of the RFC-reserved example.com, example.org or example.net domains for that purpose. Why? Since it was first registered back on 23-Jul-1997, that "domainname.com" domain is a real and registered domain. The example domains are reserved for this use, and which means you're not referencing somebody's domain. This usage makes it clear it's an intentional reference or an intentional obfuscation.

Dmanlive wrote:

Thanks, I've been working on getting DNS working correctly. I don't know if Apple's disign is buggy or not as I've perfomed a number of reconciling tests with dig, sudo checkip, nslookup, etc. All come back correct however things are not functioning with binding clients etc. I'm using a registered domain name and have the FQDN server.example.com.

If you're on a NAT'd network and if your OS X Server is the sole DNS server (it's these sorts of permutations that make this whole process more complex), then I'd guess that your DNS server is probably not referencing itself as the DNS server; you have not entered 127.0.0.1 as the only DNS server host in the OS X Server System Preferences > Network setting. Make no references to any off-NAT'd-network DNS servers.

I've reviewed the DNS information from Hoffman Labs, and have reviewed many DNS videos on Lynda.com. There still doesn't seem to be a step by step reference for OS X Server 3.1.2 with Mavericks Clients. All the outdated tutorials and information on the internet prove to have a disconnect with the manner in which to setup the new OS X server version.

Do you have specific questions?

The UI has changed a few times over the years, but the basic DNS setup and the requirements are — from as far back as 10.4 and probably further back, and right up to 10.9 — the same. It's all ISC BIND, after all. The UI is how you get the A or AAAA record into the underlying data file. (OS X Server uses ISC BIND DNS server "behind" the Server.app GUI or the older Server Admin.app GUI, and ISC BIND is one of the most widely-deployed DNS servers on the Internet.)

I wish Apple would spell out the correct step by step explenation for their design.

If you're looking for a turn-key setup, and (having done networking and DNS for a while now), I just don't know of a one-size-fits-all or step-by-step for the local network and DNS. Not sure anybody knows how to do that, really. Not without a whole lot more integration with the other devices on the network, or short of giving you a box of parts and a map to connect them together, that is.

This is all part of the difference with running a server as compared with running a client — servers provide the services that the client devices expect, so there's inherently more setup involved. There's no server for a newly-arrived server to go ask for, for instance, the local network configuration details.

There are usually variations in each network I've connected to, whether it's the internal setup or the ISP setup, or the particular variety of hardware. The local network here is wildly different than what you're running, for instance, as are the local requirements here.

Apple has been slimming down their OS X Server manuals for years, and going from a more complex (and far more flexible and configurable) user interface to a far simpler and more restrictive UI. Going from 10.6 to 10.7 was a real problem for a number of folks, because a whole lot of the flexibility was removed, as was a whole lot of the documentation. OS X Server 10.6 has far more and far more detailed documentation available, and featured a far more flexible user interface with Server Admin.app and related tools. (All that detail aside, it was and is still common to "bottom out" in the far more inclusive OS X Server 10.6 documentation, and to have to go read the Postfix docs or some other service-specific documentation for the particular service within OS X Server.)

When you install Server there's the tutorials that come with the server, but they are no where near descriptive enough for the DNS portion. Although I'm new to setting up an OS X Server I've in past fully configured Microsoft servers with exchange & IIS and it seems far more clear as to the order in which things need to be for a functioning DNS.

The basic order of installation and configuration is the same, irrespective of the operating system platform. Install the OS bits. Set up IP networking. Then set up DNS services, if the local network does not already have DNS services — most small networks already have DNS, unless this is the first server being installed. Then Open Directory and related pieces, or Active Directory and its environment, or whatever you're using for distributed authentication services. Then everything else that's locally necessary gets configured and started.

With DNS itself, you set up the A or AAAA record for the host, aim the clients at the server (manually or via DHCP), and you're off and running. If the DNS server is a client of itself for DNS services, then aim the server at the 127.0.0.1 "loopback" IP address for its DNS server reference.

If you have specific DNS questions or suggestions about how the HoffmanLabs DNS info can be improved, I can try to address those, too.

*Given you'll probably eventually be using a VPN, avoid using both the 192.168.0.0/24 and 192.168.1.0/24 subnets, as those subnets are used in many coffee shops and hotels and home networks. This because VPN services are based on IP routing, and as IP routing does not work well when the same subnet is used on both ends of the connection. When establishing a new network, it's better to use an obscure subnet somewhere else in a far more obscure part of one of the private IP address blocks 192.168.0.0/16 or 172.16.0.0/12 or 10.0.0.0/8.