With the Server 5.1 update providing TLS 1.2 support at last, courtesy of LibreSSL 2.2.6, it’s easy to score A+ on the Qualys SSL Server Test. Here’s a quick run-through of how to get the best performance from the new version.
The Big Deal: TLS 1.2
The situation for those of us using OS X Server to host HTTPS sites was until very recently beginning to look dire, with the Server app falling so far behind that even Apple’s own AppleBot and AppleNewsBot wouldn’t talk to it. As I mentioned in “Tune Cipher Suites and Support Forward Secrecy on OS X Server”, there was every indication that the new proxy architecture introduced in version 5 of the app was a first step toward either a planned overhaul of TLS support or the dropping of web services entirely. Fortunately, it turned out to be the former, and Server 5.1 finally brings TLS 1.2 and greatly improved cipher support. For this version, the new capabilities rest on LibreSSL, the OpenBSD-backed fork of OpenSSL, but Server 5.1’s configuration files are full of signs that Apple’s own Secure Transport may be undergoing testing for the job of handling TLS for the proxy — including conditional configuration blocks for
mod_secure_transport.c and an explicit warning not to enable both
secure_transport_module at the same time.
The big deal for webmasters managing HTTPS sites on OS X Server is that we can finally support something other than broken TLS 1.0 and offer solid, secure and generally much faster connections to modern web browsers; we can also nail Forward Secrecy across a much wider range of browsers than before. Out of the box, the new version will achieve an A- grade on the Qualys SSL Server Test, but by tuning the cipher suite as I described in the article mentioned above, it’s now easy to change that to an A+. (Note that the suggested cipher suite has changed slightly since that article was written, but the differences between the two suites are only apparent with a small number of browsers; either the newer or the older suite will still achieve an A+ and Forward Secrecy across all reference browsers.)
It will be interesting to see what else might change — for the better or for the worse — if Secure Transport does wind up taking over in the future and handling the proxy’s TLS interactions with the outside world.
Other Changes Under the Hood in Server 5.1
In addition to the headline feature of TLS 1.2 support, Server 5.1 improves the default logging definitions in
The new configuration also dispenses with extraneous environment variables, so we no longer need to jump through hoops to check two different environment variables in order to exclude bad bots from our logs. (See “Adjusting the Apache Log Format on Server 5 and Updating Bot Exclusions”.) Instead, the default
CustomLog directive can just be commented out and replaced with the
#CustomLog "/var/log/apache2/access_log" common CustomLog "/var/log/apache2/access_log" combinedvhost env=!donotlog
The check on the environment variable
donotlog is only necessary when using additional code to prevent certain visits from being logged, as I described in “Improve OS X Server Performance With a Server-Wide Ban List”
Other Changes Due to El Capitan
The minimum OS requirement for Server 5.1 is 10.11.4, which means that servers which have stuck with Yosemite won’t be able to take advantage of all the new TLS goodness. I outlined a general approach to updates in “Low Stress Server Upgrades on OS X”, but it’s worth being aware of a few extras that will arise during the update to El Capitan.
Most urgently in terms of getting sites up and running again is that major OS updates will remove the crucial MySQL log directory, without which MySQL won’t start. That can be fixed easily via:
sudo mkdir /var/log/mysql
sudo chown _mysql:staff /var/log/mysql
And fairly urgent in terms of keeping the server available will be an extra visit to System Preferences to verify your preferred power management settings: the update may knock some or all of your preferences back to their default values, which could result in the server going to sleep, failing to start again after a power outage, or failing to start up or wake up on a schedule. That last one might seem a little odd for a machine intended to be on all the time, but it should always be set as a fail-safe, just in case something goes badly wrong. (For example, a power outage followed by a second power outage occurring while the machine is restarting from the first may prevent it from restarting automatically following the second outage; a scheduled startup provides another chance.)
You’ll also find that — thanks to System Integrity Protection — high performance mode (see “Essential Performance Tweaks for Your New OS X Server”) can no longer be set without first using
csrutil from recovery mode to disable SIP. This seems utterly crazy to me, but I’m cautiously optimistic that it won’t prove to be as big a deal as it first seems: as far as I can tell, the performance mode no longer makes as much difference as it once did, and so far I haven’t noticed any significant performance issues, at least with the web service, when high performance mode is switched off. It’s early days, however, and of course your mileage may vary.
For the same reason, if you need Pear, it can no longer be installed in the usual location, which is now off limits due to SIP. Fortunately, it’s not difficult to install it in
/usr/local instead, like so:
curl -O http://pear.php.net/go-pear.phar
sudo php -d detect_unicode=0 go-pear.phar
At the prompt, you can configure the alternative location via option 1:
And configure the following via option 4:
The installer will offer to update your
php.ini file for you, but it will choose the wrong
ini file, so don’t bother; instead, add the extra path to your
php_custom.ini, which lives at:
If you’ve used the locations included above, the installer should confirm that the correct path to add is:
After restarting the Apache web service with the usual method, Pear should now be available to any scripts which require it:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/server-apachectl graceful
Finally, when updating to El Capitan, it will be necessary to re-apply any modifications to Apache log rotation along the lines of “Making Apache Log Rotation Usable Again on Server 5”, and if you’ve set up a custom SSH service somewhere other than port 22, you’ll need to restore the custom service lines to
/etc/services, then stop and start the launch agent again. See “Changing the Default SSH Port on Mac OS X Server” for full details of the procedure.
What Hasn’t Been Fixed in Server 5.1
Server 5.1 provides huge improvements for HTTPS sites, but not everything is firing on all cylinders.
Unfortunately, the certificate chain bloat that I described in “The Nuts and Bolts of Setting Up SHA-1 and SHA-2 Certificates on OS X Server” still hasn’t been fixed. Therefore, certificate chains still need to be cleaned up for best performance; I think it’s best to use a script for that job, but it can be done manually if necessary.
In addition, it appears that TLS connections with Internet Explorer, and with IE11 in particular, may have become slower, and it isn’t yet clear to me why that might be — especially when connections to all other major browsers have become significantly faster.
And bizarrely, the newly updated configuration files still include the obsolete
nokeepalive hack for Internet Explorer, which would make connections with any vaguely modern version of IE even worse and clearly should not be used. (See “Improve OS X Server Performance for IE Browsers”.) The hack should be commented out from both of the following files:
Notably, the hack is included in conditional blocks for both SSL and Secure Transport.
All material on this site is carefully reviewed, but its accuracy cannot be guaranteed, and some suggestions offered here might just be silly ideas. For best results, please do your own checking and verifying. This specific article was last reviewed or updated by Greg on .