macOS High Sierra, Server 5.6.3 and Letsencrypt

@John Lockwood

Thanks for your answert!

Your points seem correct, but I'm stuck at point two of your list, I cannot get the certificate from LetsEncrypt because Webservice of the Server does refuse to show stuff outside my home network, ignoring the fact that it has a valid DNS entry and is otherwise reachable by the outside world. LetsEncrypt needs to see a File i put on display but as long as the Webservice does not show anything to the world, that File is not shown and therefore i cannot proof to LetsEncrypt that the domain is mine...

Yes I had a similar issue with LetsEncrypt and JAMF.

There are two main ways to have LetsEncrypt verify a request, the normal way is to have a special page on your webserver which the LetsEncrypt service can check exists to verify you own the domain - this clearly is not going to work for you. (Or me.) The second way is to temporarily add a special TXT record to your domain - this is known as a DNS Challenge which only the owner of the domain is able to do and then LetsEncrypt can verify the presence of this record, this is way I did it.

See - https://letsencrypt.readthedocs.io/en/latest/challenges.html

You will need a different script for each DNS provider, who is the DNS provider for your Internet domain?

Full network access to the web server works, prior to the transition to an MDM server at 5.7.1.

The NAT’d network, DNS and the firewall/gateway/router all have to be configured correctly for external access into the web server, but that’s nothing new. That’s always been the case.

You’re going to be fighting with Server with 5.7.1 and later, and while running two parallel web servers is possible, you’ll likely have to remap the ports for your secondary server. The NAT’d and forwarded port might go from 80 externally to 8080 on the second web servee, for instance. External access will see what it expects. Internal references will see 8080. (I think there’s also a way to remap the Server default ports for web access so that your secondary server can “have” the primary ports, but I’ll have to look up the details for that. That port remapping has been discussed before.)

If this configuration is strictly local on a NAT’d network, then there’s no reason not to use private certs. They can be just as secure as commercial certs if not more so, as long as the root private key is kept private. Same requirement as with the purchased commercial certs, that. Set up your own certificate authority, load the root public cert into each client, generate and sign the CSRs from other clients, load the signed cert, and off you go... This is the same process that commercial certs provide.

Loading the signature file for LetsEncrypt is possible, as is—probably—getting the ACME client going with Server, but I ceased to pay attention to these parts of server because of 5.71.

There’s likely an ACME client for macOS without Server, and that’d be the path here if you really want to server web content from macOS. This unless you want and need an MDM server. What Server was, is, well, dead.

Alternatives include hosting the web content or hosting both the content and hosting your own server remotely, or using BSD or Linux servers to host content locally, or using a NAS box with web server capabilities.

I have not tried using LetsEncrypt with macOS Server but I believe the following would apply.

• You would obviously install the LetsEncrypt software
• You would use it to request an initial certificate and later renew it
• LetsEncrypt would produce a certificate and a private key
• You would I believe need to convert these to a password protected .p12 file
• You would then need to script the importing of the .p12 in to the System keychain

I believe the Apple software then automatically copies the results in to /etc/certificates

At least for the first time you then need to tell Server.app to use this cert for Profile Manager, after the first time when it renews the renewed certificate and key will still have the same common names and subject alternative names and therefore should simply overwrite the previous expiring versions. I am hopeful this would mean you do not need to do anythin in Server.app to recognise this and would merely import the new/renewed .p12.