Prepare FileWave Server and Booster for Apple's stricter TLS requirements

What

Apple is tightening network security requirements for managed-device traffic. Starting as early as the next major Apple operating system release, Apple devices may refuse HTTPS connections to servers with outdated TLS settings or certificates that do not meet Apple's App Transport Security (ATS) requirements.

For FileWave environments, this can include a customer-managed FileWave Server, FileWave Booster, reverse proxy, load balancer, custom hosted domain, or other HTTPS endpoint that Apple devices reach during MDM, Declarative Device Management (DDM), Automated Device Enrollment, profile installation, app installation, enterprise app distribution, or software updates.

Apple says affected servers need to:

Support TLS 1.2 or later
Use ATS-compliant ciphersuites
Present valid certificates that meet ATS standards

TLS 1.3 is preferred. For TLS 1.2, Apple calls out Perfect Forward Secrecy ciphersuites and the extended master secret extension. Apple's article lists exceptions for SCEP server connections used during profile installation or DDM asset resolution, and for content caching servers.

When/Why

Use this article when preparing a FileWave environment for the next Apple operating system release, especially when Apple devices use customer-owned FileWave infrastructure.

Check the environment if:

FileWave Server or Booster is running on macOS, especially an older macOS version.
FileWave Server is on-premise or behind a customer-managed reverse proxy, load balancer, firewall, or TLS termination point.
A FileWave Booster is reachable by Apple devices for content or fileset delivery.
The environment uses a custom FileWave hostname or custom hosted domain.
The environment uses self-signed, private CA, expired, older-chain, or manually managed certificates.

For FileWave-hosted services using FileWave-managed standard hostnames, FileWave manages the public TLS endpoint. Customers should still check custom domains, customer-owned reverse proxies, customer-owned Boosters, firewall TLS inspection paths, and anything else Apple devices contact directly.

How

1. Inventory the HTTPS endpoints Apple devices use

List the FileWave-related hostnames Apple devices may contact. Common endpoints include:

The FileWave Server URL used by clients and enrolled devices
Any externally reachable FileWave Booster URLs
Reverse proxy or load balancer hostnames in front of FileWave Server or Boosters
Custom FileWave hosted domains
Kiosk, App Portal, enterprise app distribution, or manifest URLs
Staging, test, or disaster recovery FileWave environments

Do not test only the main FileWave Server if devices also use Boosters, proxy hostnames, or custom domains. Apple notes that different device configurations may connect to different servers.

2. Test each endpoint from macOS

Apple's diagnostic tool, nscurl, is included with macOS. The helper script attached to this article is therefore a macOS script, not a Linux or Windows script.

You can run the test from:

The FileWave Server Mac itself, if FileWave Server is running on macOS
The FileWave Booster Mac itself, if the Booster is running on macOS
Any other Mac that can reach the FileWave Server, Booster, reverse proxy, load balancer, or custom domain being tested

The test does not have to run on the FileWave Server or Booster. It checks the HTTPS endpoint from the Mac and network path where the command is run. If devices reach FileWave through different paths, such as internal DNS, external DNS, VPN, a reverse proxy, a load balancer, or a different Booster, test each path separately.

From a Mac, run Apple's nscurl diagnostic against each HTTPS endpoint:

/usr/bin/nscurl --ats-diagnostics https://fw.example.org/

In the output, look for the FCP v2.1 result:

Configuring NIAP TLS package version requirements

---
FCP_v2.1
Result : PASS
---

If this result is PASS, Apple says the server meets the stricter requirements checked by that diagnostic.

You can also use the attached helper script to summarize the Apple diagnostic and add a quick OpenSSL check for the negotiated TLS protocol, cipher, certificate verification result, and certificate signature algorithm.

Download the helper script: validate-apple-network-security.sh

After downloading the attachment:

chmod +x validate-apple-network-security.sh
./validate-apple-network-security.sh https://fw.example.org
./validate-apple-network-security.sh fw.example.org:443

The helper script exits with:

0 when Standard ATS and FCP_v2.1 both pass
2 when Standard ATS or FCP_v2.1 fails
1 or 3 when the script could not complete or parse the result

The nscurl result is the primary result. The OpenSSL section is extra context to help identify obvious protocol, cipher, certificate trust, or certificate signature problems.

3. Interpret the result

If Standard ATS and FCP_v2.1 both pass, the endpoint passes Apple's diagnostic. If Standard ATS passes but FCP_v2.1 fails, the endpoint may work today but should be remediated before Apple enforces the stricter requirement.

If either result is unknown, run the raw nscurl command manually and review the full output. Test from a current macOS version where possible.

4. Remediate non-compliant endpoints

The fix depends on where TLS is terminated. Check the FileWave Server, FileWave Booster, reverse proxy, load balancer, firewall, or hosted custom domain configuration that presents the certificate to Apple devices.

Common remediation items include:

Update the server, proxy, load balancer, or TLS termination point so it supports TLS 1.2 or later.
Prefer TLS 1.3 where possible.
Disable TLS 1.0 and TLS 1.1.
For TLS 1.2, use ciphersuites that provide Perfect Forward Secrecy and support the extended master secret extension.
Replace certificates that are expired, self-signed for production use, missing a Subject Alternative Name, signed with SHA-1, using weak key sizes, or missing required intermediate certificates.
Make sure the certificate chain is trusted by Apple devices and matches the hostname being used.
If Apple reports an ATS certificate trust warning for a certificate that is intentionally included as an auto-enrollment profile anchor certificate, Apple's article says remediation may not be required for that specific trust warning. Still validate the full workflow on representative devices.
Review any SSL/TLS inspection, HTTPS decryption, or deep packet inspection product between the device and the FileWave endpoint. Inspection can replace the certificate that Apple devices see and may cause ATS failures.

If the FileWave Server or Booster runs on an older macOS version, confirm that the operating system and FileWave version can present modern TLS settings and certificates. Some environments may need an OS upgrade, FileWave upgrade, certificate replacement, or modern reverse proxy.

5. Retest the FileWave workflows

After remediation, rerun the nscurl diagnostic or helper script for each endpoint. Then test the FileWave workflows that depend on those endpoints, such as ADE, MDM enrollment and check-in, profile installation, app installation, Kiosk or App Portal installation, software updates, and Booster content delivery.

If a workflow still fails, collect the tested URL, nscurl output, helper script output if used, FileWave Server/Booster version, server operating system version, network path details, affected Apple OS version, and relevant FileWave or Apple device logs.