Hosting a secure website - Diffie-Hellmann weak ephemeral error msg

The weak-DH warning is due to to the local Apache configuration. There are technical details of the issue available. There's also information on how to test for and how to address this; you'll be manually editing the Apache configuration files, pending an Apple update that eliminates the lower-grade crypto from the defaults. There are other discussions posted on this weak-DH "Logjam" error, as well as tools that can help generate the Apache configuration for you.

The OS X Server Apache configuration files are located under

/library/server/web/config/apache2

/library/server/web/config/apache2/sites

With the core httpd.conf analog file at

/library/server/web/config/apache2/httpd_server_app.conf

Hopefully, Apple will soon update the SSL/TLS security of Apache.

If not serving the web server data publicly, then I'd consider establishing a VPN into your network, and not serving pages openly. That'll cut down on the numbers of attempted server attacks and the rest of the dreck that will inevitably target any Internet-connected server; they'll have to get past the VPN authentication first.

Consider having your server separate from the other systems on your local network; configured into what is known as a DMZ. This is intended to contain any server breaches. With the DMZ, a server breach can be (and should be) prevented from further access into your network, meaning only the data on the server(s) in the DMZ is potentially exposed. Consider not having sensitive data on the server that's publicly accessible, as well. (If some part of a web site on your server is running php or Python or other such, and that becomes breached, then — depending on the severity of the breach, or the exposed access credentials, or such — the rest of the data on the server can potentially become exposed, and can be copied or deleted or otherwise corrupted. Best to isolate and separate, if you can.)

DMZ support is a feature of most mid-range and higher gateway-router-firewall-NAT devices; starting on the order of US$200 or so. Those firewalls can also have a VPN server, which means you have access to your entire network, once you've configured and established a VPN.

And FWIW, if you're running a local server for just your own clients and not for other folks on the Internet, there's no need for a purchased certificate. You can run your own CA and load your own root certificate into the clients that are using the site, or otherwise just mark the generated (local) certificate as being trusted by the client. Commercial certs provide no security advantages over that of a locally-managed CA, other than having the root certificate already loaded into the client; the trusted root certificate is securely pre-loaded. If you have control over the local clients, you can securely load your own root certificate. If you're serving ecommerce or serving potentially-sensitive data to random folks and particularly to client browsers that you do not control (and thus cannot securely load the root certificate or otherwise trust a generated certificate), then you do want a commercial certificate.

You're running a server now, which means some familiarity with Terminal.app and the command line will eventually be beneficial; whether that's for customizations or for troubleshooting.

Per this discussion, find the certificates you are using in the Sites subdirectory (referenced by SSLCertificateFile), and append the DH to the end of the certificate file.

Launch Terminal.app from Applications > Utilities.

The $ is the command prompt in the following. Don't type it.

First, set your default directory to the Sites subdirectory.

$ cd /Library/Server/Web/Config/apache2/sites/

Then search for the certificate file names:

$ grep -i SSLCertificateFile *

will return some hits, and which should look something like this:

/Library/Server/Web/Config/apache2/sites/0000_any_443_.conf: SSLCertificateFile "/etc/certificates/{yourhostname.example.net}.{hexadecimal string}.cert.pem"

To append your DH to the end of the certificate file, something akin to the following two commands, where the first creates a backup copy and the second appends the dhparam file (shown as /your/path/to/the/custom/dhparam) onto the end of the certificate PEM file.

$ cp /etc/certificates/{yourhostname.example.net}.{hexadecimal string}.cert.pem ~/backup_copy_of_cert.pem

$ cat /your/path/to/the/custom/dhparam >> /etc/certificates/{yourhostname.example.net}.{hexadecimal string}.cert.pem

If there are other certificate files, you'll need to cp to back up those, and then cat to append the dhparam.

I've not tested this sequence as I don't have a Server.app 5 configuration handy.

Internet accessibility has nothing to do with privately-generated certificates. Certificates are certificates, whether the most massively expensive and beautiful mathematics of a top-drawer certificate from the premier vendor of exclusive certificates, or a home-grown certificate. So long as they all track back to a trusted certificate or a trusted root certificate — the certificate authority root certificate, whether commercial or your own — they all work the same, for the same bit-length certificates. It's getting the root certificate loaded into the clients that matters; that is central to the discussion. If you have control over your devices and of those others that will be using and accessing your site, a private CA works just the same as a public one. And you have more control and more flexibility. If you don't have control over the other accessing devices, then do purchase a commercial cert if you want or need SSL/TLS. CAs are selling you the presence of their root certificate in the trusted-certificate stores of various devices, a promise that you've identified yourself to them and that they won't just generate a certificate for somebody else, and some math. The whole certificate system is pretty flimsy, when you understand it.

Enabling the root user is not usually something I'd recommend.

Out of curiosity:

sudo nano /Library/Server/Web/Config/apache2/httpd_server.conf

(or vim or emacs or whatever else you're using as an editor) doesn't work?

I probably can't help any further here; you're off into areas and changes beyond what I'm familiar with.

That OS X Server wants to rewrite or overwrite the file is typical. That's the way that Server.app works.

I'd suggest using the Sites-related files for changes via the XML-level configuration, or maybe enable local overrides and use the overrides (.htaccess) file in the web site directory.