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

Internal draft note: This is a review draft for FileWave KB. Proposed final placement is Apple General Info, with related links from the certificate and network troubleshooting pages. Proposed customer-facing title: Prepare FileWave Server and Booster for Apple's stricter TLS requirements.

What

Apple has announced stricter network security requirements for Apple operating systems. Starting as early as the next major Apple operating system release, Apple devices may refuse connections to servers that use outdated or non-compliant TLS settings.

This matters for FileWave environments because Apple devices may connect directly to a FileWave Server, FileWave Booster, reverse proxy, load balancer, custom hosted domain, or other customer-owned HTTPS endpoint during device management workflows.

Apple says the new requirements apply to network connections directly involved in:

Mobile device management (MDM)
Declarative Device Management (DDM)
Automated Device Enrollment
Configuration profile installation
App installation, including enterprise app distribution
Software updates

Apple lists two exceptions in its article: SCEP server connections used while installing a configuration profile or resolving a DDM asset, and content caching servers used for app installation or software updates.

Servers used for affected workflows must:

Support TLS 1.2 or later
Use App Transport Security (ATS) compliant ciphersuites
Present valid certificates that meet ATS standards

TLS 1.3 is preferred where possible. For TLS 1.2, Apple calls out support for modern Perfect Forward Secrecy ciphersuites and the extended master secret extension.

When/Why

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

Prioritize this review when:

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, firewall, load balancer, 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 a self-signed certificate, private CA certificate, expired certificate, older certificate chain, or manually managed certificate.
Apple enrollment, profile installation, app installation, enterprise app distribution, or software update workflows depend on customer-managed HTTPS endpoints.

For FileWave-hosted services using FileWave-managed standard hostnames, FileWave manages the public TLS endpoint. Customers should still audit any custom domains, customer-owned reverse proxies, customer-owned Boosters, firewall TLS inspection paths, or other infrastructure that Apple devices contact directly.

How

1. Inventory the HTTPS endpoints Apple devices use

List every FileWave-related hostname that Apple devices may contact during the affected workflows.

Common endpoints to check 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
Any third-party service that is directly part of MDM, DDM, enrollment, profile installation, app installation, or software update workflows

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 with Apple's diagnostics

On 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 same 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
3 when the script cannot parse a complete nscurl result
1 for script usage, tool, or connection errors

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 tested endpoint is ready for Apple's stricter TLS requirements based on 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. If possible, test from a current macOS version. Apple's audit article references test devices running iOS 26.4, iPadOS 26.4, macOS 26.4, watchOS 26.4, tvOS 26.4, or visionOS 26.4, or later, when collecting logs for affected workflows.

4. Remediate non-compliant endpoints

The exact 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, such as ECDHE-based suites.
For TLS 1.2, make sure the server supports 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 runs on an older macOS version, review whether the operating system and FileWave version can present modern TLS settings and certificates. Upgrading the server operating system or moving TLS termination to a modern reverse proxy may be required in some environments.

5. Retest the FileWave workflows

After remediation, rerun the nscurl diagnostic or helper script for each endpoint.

Then test the actual workflows that depend on those endpoints:

Automated Device Enrollment
MDM enrollment and check-in
Configuration profile installation
App installation, including enterprise app distribution
Kiosk or App Portal installation workflows
Software update workflows
Fileset or content download paths that use FileWave Boosters

Testing the hostname is necessary, but it is not the whole validation. Apple recommends using representative test devices and configurations because different device types, enrollment methods, user groups, and environments may contact different servers.

6. What to collect before escalating

If a FileWave workflow fails after TLS remediation, collect:

The affected FileWave Server or Booster hostname
The exact URL tested
The output from nscurl --ats-diagnostics
The helper script output, if used
FileWave Server and Booster versions
Server operating system and version
Whether a reverse proxy, load balancer, firewall, SSL inspection product, or custom domain is involved
The affected Apple operating system version and enrollment/workflow type
Relevant FileWave logs and Apple device logs from the same time window

For deeper Apple-side auditing, follow Apple's article to install the Network Diagnostics Logging Profile, reproduce the affected workflow on a representative test device, collect a sysdiagnose, and search for ATS Violation or ATS FCPv2.1 violation log entries.