Understanding macOS Server Part 2: Serving a Small Business

This is the second in a series of Rocket Yard articles in which we take you through the setup of macOS Server. macOS Server is an app that runs on macOS Sierra, providing services such as mail, web hosting, calendar hosting, and more to users in a workgroup.

In Part 1 of this series, we discussed what macOS Server is, how a Mac mini makes a very workable “headless server”, and how to purchase and install macOS Server. This week, we’re going to set up our server for a small business called “Astounding Photos”.

Most companies want their servers to be accessible from outside of the confines of an office. This gives employees the ability to work securely with the network through a virtual private network (VPN) and send/receive email, lets customers visit a website hosted on the server, and more.

As mentioned in Part 1 of this series, Apple provides an excellent set of built-in tutorials for macOS Server that are accessible from the Help menu of the server app. In the next few episodes, I’ll be following the lessons outlined under “Set up for small business” in the tutorials. (Related: Get the best performance from your Mac mini server with MacSales.com.)

Getting an Internet Identity
The first step in making our server available to customers and employees is to set up an identity that will be accessible from anywhere on the Internet. The tutorial points out the things that we must do to set up our identity:

1) Get a static IP address

2) Give your server a host name

3) Get a domain name

4) Set up DNS and reverse-DNS resolution

5) Get a signed SSL certificate

6) Get a company Apple ID

Getting a static IP address
There are two ways to get an unchanging IP address that’s associated with your location. First, and probably the easiest, is to work with your internet service provider (ISP) to have a static IP address assigned to you. Note that for home internet service users, many ISPs do not allow static IP addresses; you may need to switch to a business account or use a dynamic DNS (Domain Name System) service.

Home internet services use DHCP (Dynamic Host Configuration Protocol) to assign an IP address from a group owned by the ISP to your cable or DSL modem. Since the address can change each time the cable or DSL modem is rebooted, the IP address is not static.

A dynamic DNS service watches the IP address that is assigned to a home internet service and if it changes, it reroutes requests to the new IP address automatically.

One of the most well-known providers of dynamic DNS service is Dyn.com. Their least expensive dynamic DNS service runs $40 per year, but that cost allows you to run up to 30 hosts — a bit of overkill if you’re setting up one host name. There are also free dynamic DNS services like No-ip.com that are perfect for just one host name, but they require verification once a month via email or have other quirks.

If you do have a static IP address but don’t know what it is, you can visit whatsmyip.org or look at the home screen for macOS Server and look at “Internet”. It will show that your server is available at a specific IP address. For security reasons, I’ve blanked out part of the IP address for my server in the image below:

The "home screen" of macOS Server showing internet reachability

(The “home screen” of macOS Server showing internet reachability)

Give your server a host name
A host name is the name that your server has on the local network. When your server is accessed over the internet, it will need to have a fully-qualified domain name that includes the host name (say “server”) and the complete domain name (astoundingphotos.com in this example).

The host name is required even if you aren’t accessing the server over the internet in order for the server to be uniquely identified on your local network.

Make sure you’re happy with the host name, as it can be difficult to change later on.

Get a domain name
Domain names are the “written addresses” where a server resides (uniquename.tld, where tld is a “top-level domain” such as .com, .org, .info, etc… DNS is used to translate a written address — astoundingphotos.com — into a numeric address (your static IP address) when someone tries to access your server.

Domain names aren’t purchased; you’re actually leasing them from a domain registry for a period of time. It’s drop-dead easy to register a domain name so the process won’t be covered here. Some domain registrars you may want to consider are GoDaddy.com and Dreamhost.com. The annual cost of your domain name will depend a lot on the top-level domain used.

Whatever domain registrar you select, make sure that you familiarize yourself with their DNS tools as at one point you’ll need to let them know the static IP at which your server resides.

Set up DNS and reverse-DNS resolution
It’s now time to set up DNS and reverse-DNS resolution. As noted before, this is the link between the domain name you’ve leased and the static IP address of your server.

The domain registrar will almost always set up an SOA (Start of Authority) record for you, which is part of your DNS Zone file. This usually points to the DNS servers operated by the domain registrar. You can use the nslookup command in Terminal on your Mac to see the link between your domain name and the DNS host (see image below):

The results of nslookup for our domain name

(The results of nslookup for our domain name)

Note that the IP address listed here isn’t the static IP address of my server; since I’m doing an nslookup from my local network, it’s showing the local IP address of my router. To make sure that my domain name is properly pointed to the static IP address, I needed to perform the nslookup over a cellular connection on my iPhone using a free app called (oddly enough) nslookup.

The next two records you’ll need to set up are an “A” record linking your fully qualified domain name — in this example it will be astoundingphotos.com — to the static IP address and the reverse DNS entry. In Dreamhost’s domain management tools, the A record is set up as follows (see image below, IP address obscured for security reasons):

Adding a custom DNS record pointing the domain name to the static IP address

(Adding a custom DNS record pointing the domain name to the static IP address)

Since I’m thinking about hosting mail, calendars, contacts, messages, a web server, a VPN, and a Wiki on this server — all for access inside and outside of my local network — I also added A records for:

  • mail.astoundingphotos.com
  • calendar.astoundingphotos.com
  • contact.astoundingphotos.com
  • messages.astoundingphotos.com
  • www.astoundingphotos.com
  • vpn.astoundingphotos.com
  • wiki.astoundingphotos.com

These are subdomains of astoundingphotos.com. I may not need these subdomains, as each service uses specific TCP or UDP ports to address the server, but I have set them up anyway…just in case.

Finally, let’s add the reverse DNS entry. This can be done by adding a pointer record (AKA “PTR”) for your site. Apple demonstrates reverse DNS entries by showing that you’d have entries that would not only link your domain name to a numeric IP address (i.e., astoundingphotos.com = but also linking your numeric IP address to the domain name ( = astoundingphotos.com).

You will most likely need to have your DNS provider (probably your domain registrar) set up the reverse DNS entry for you. Most can do this quickly, although it can take up to 4 hours or so for the entries to percolate through the internet.

Get a signed SSL certificate
One of the most important things you can do when setting up your server is to ensure the security of your users and data. One of the best ways to do this is to get a signed SSL certificate from a Certificate Authority (CA).

A Certificate Authority is a trusted third party that verifies the identity of an SSL certificate. They do this by making sure that you are who you say you are, and then charging you to digitally sign the cryptographic keys that are used to encrypt communications to and from your server.

Having the signed SSL certificate installed on your macOS Server means that any users accessing that server for email, web services, and so on can rest easy knowing that their data is encrypted en route.

There are a couple of ways you can get a signed SSL certificate. First, you can act as your own Certificate Authority and digitally sign your own keys as long as you have control over all of the machines that will access your website. That’s unlikely, so we won’t cover that eventuality.

The next way is to use a popular and trusted CA. Several of these are Comodo, Geotrust, and Digicert. Most of these services provide a free 90-day trial if you’re just setting things up to learn about servers and SSL, but you’ll find that certificates can be a bit expensive.

If you’re a business, you most likely want to get what’s called an “Extended Validation SSL” certificate. When someone visits your website, they can tell just how secure the site is immediately — in both Safari and Chrome, the address shows a “lock” icon and the site owner information appears in green in the address bar.

SSL certificate files (obscured for security)

SSL certificate files (obscured for security)

The time to get an SSL validated depends on just how much validation you wish to get. If you just want domain validation (i.e., your site or server is owned by XYZ), that can be done by sending domain ownership information via email in five minutes or so. The requirements for business and extended validation are more stringent, where business documents showing your company’s location and ownership need to be sent to the CA.

You can also get a free domain validated SSL certificate from Let’s Encrypt. This is a free, automated, and open CA that is run for the public’s benefit by the Internet Security Research Group. Some major domain registries can provide you with a Let’s Encrypt certificate through their domain management tools; that’s how I grabbed a Let’s Encrypt SSL certificate for this example.

What does your SSL certificate look like? In many cases, you’ll received four sets of alphanumeric keys. One is called a CSR or Certificate Signing Request, the next is the Certificate itself, the third is the Private Key, and the final is an Intermediate Certificate (see image at right for an example).

You’ll need to have these keys close by and be able to copy and paste them into the appropriate space in your macOS Server configuration. We’ll cover how to install the certificate in a future article in this series.

Get a company Apple ID
This is the final step in building your internet identity. The Apple ID is used to enable push notification for services, and a personal Apple ID isn’t recommended. You can use a personal Apple ID if you’re an individual setting up a personal server; for businesses, it’s highly recommended to get a company Apple ID since an individual might leave the business or delete their personal Apple ID.

To create an Apple ID, go to this web page. You’ll need to have an email address that is not associated with any personal Apple ID. Of course, since we haven’t yet set up our mail server, you can’t use an email address on your server…yet.

The Next Step
So, we have a running server…but we’re nowhere close to actually being able to access or use any of the services running on it. In the next article, we’ll set up the local infrastructure — configuring our local router to pass requests to various services on our server, turning on Open Directory to begin adding users to our server, and providing and checking service access over the Internet.

Stay tuned for the upcoming Part 3 of the macOS server series, with Part 4 appearing in March. I want to make sure that our readers are able to set up their own macOS Servers successfully, so it will take a bit of time and effort for testing.

Related: Understanding macOS Server Part 1: Background and Setup


  • I am using Server 5.3 on a MiniServer. I installed a certificate from RapidSSL (GeoTrust) using the Certificates panel in Server, and though it looks OK when viewed under the “lock” icon in Safari, the GeoTrust CryptoReport tool says that there are “multiple certificates” and a “self-signed root”.

    Have you heard of, or dealt with this in the Rocket Yard?

    The tool: https://cryptoreport.rapidssl.com/checker/

    The domain to check: lab.troymeyers.com

    Thanks for any comments!

    • Troy –

      Yeah, that’s a bit odd… The CryptoReport is showing that it’s a valid certificate, but then shows that there’s a self-signed root certificate with the same name. Does the Certificates panel show a self-signed certificate AND the RapidSSL certificate as well?

      • Steve,

        Thank you for the reply! No, the certificate panel indicates just one. In the mean time I noticed an article elsewhere that described the problem dating back to the Mavericks version, and I wrote to him and he confirmed that it continues to be an issue. He said that there is a problem with the way Server sets up some pem files, so actually Apache ends up sending 4 certificates: the Intermediate, 2 copies of the RapidSSL cert for my common name, AND a self-signed root. He described to me how to edit and repair the files so that only the two needed ones will be sent. This is supposed to not only fix the problem, but also improve performance since each page load is weighted down with the extra certs.

        BUT, once fixed, if you configure something in Server, Server un-does the repairs you’ve done. This author also described a script that I will try that will easily re-do the repairs (for multiple certs if you have that many) instead of hand-editing again.

        BTW, it’s not just certs from RapidSSL.

        I haven’t had a chance to try the hand-edit-fix or the script yet, but I will report back.

        Have you tried the CryptoReport on any of your Server setups?


  • Given that you created A records for about eight different domain names, perhaps you could discuss (or at least point to a discussion of) what is involved in obtaining a certificate that shows up as valid regardless of which of these names is being referenced at the moment (if possible), rather than a vanilla certificate that applies to one of these names but throws warnings to anyone referencing any of the other names.

  • This is a really great series. Thanks so much for putting it together. I would love to set up an internal server, one that would be accessible from the computers within my office only. It would be nice to see the instructions for how to set this up as I’m sure a lot of the steps outlined in this tutorial would not be necessary.

  • Hmmm, many of the links in the article go to a “Not Found” page at blog.macsales.com

  • The dyn.com link doesn’t work.

  • You mention DDNS services but didn’t give any examples of configuration.

    If you’re going to host an email server, getting DNS and rDNS correct are “crucial.” Get those wrong and when you try to send an email, it’ll fail.

  • It’s -really important- to get DNS set up correctly before trying to configure other OS X Server items. It’s worth paying someone to do this if you have trouble with DNS configuration. (I’ve had to do this a couple of times, often when something got scrambled in the DNS entries either through my mistake, or through some gremlin that somehow scrambled things.)