Skip to main content

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

What

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

For FileWave, check any customer-managed HTTPS endpoint that Apple devices contact for MDM, Declarative Device Management (DDM), Automated Device Enrollment, profile installation, app installation, enterprise app distribution, or software updates. This may include a FileWave Server, FileWave Booster, reverse proxy, load balancer, or custom hosted domain.

Apple says affected servers must:

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

FileWave Server and Booster have supported compliant TLS 1.2 for many years. Apple's requirement is TLS 1.2 or later with ATS-compliant ciphersuites and certificates, so a supported FileWave Server or Booster is not non-compliant just because it does not yet offer TLS 1.3. TLS 1.3 is preferred by Apple when available and is planned for a future FileWave release, but TLS 1.3 is not required for Apple's validation. For TLS 1.2, Apple calls out Perfect Forward Secrecy ciphersuites and the extended master secret extension.

When/Why

Use this article when Apple devices connect to customer-owned FileWave infrastructure, such as an on-premise FileWave Server, a macOS Server or Booster, a customer-managed Booster, a reverse proxy, a load balancer, a custom hosted domain, or a manually managed certificate.

For FileWave-hosted services using FileWave-managed standard hostnames, FileWave manages the public TLS endpoint. Customers should still check any customer-controlled endpoint Apple devices contact directly. The customer action is to validate the actual HTTPS endpoint and fix the certificate, TLS configuration, or TLS termination path if the Apple test fails.

How

1. List the HTTPS endpoints to test

List the FileWave-related hostnames Apple devices may contact. Start with:

  • The FileWave Server URL
  • 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.

2. Test each endpoint from macOS

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

You can run the test on the FileWave Server Mac, on a Booster Mac, or from any other Mac that can reach the endpoint being tested. The test checks the endpoint from the Mac and network path where the command is run. If devices use different paths, such as internal DNS, external DNS, VPN, reverse proxy, load balancer, or different Boosters, 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:

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

After downloading it:

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

3. If the test fails

A failed result does not automatically mean that macOS is unsupported. It means the tested HTTPS endpoint did not meet Apple's ATS/FCP_v2.1 requirements from that Mac and network path.

First, identify what is presenting HTTPS to Apple devices:

  • If FileWave Server or Booster on macOS presents TLS directly, confirm it is a supported FileWave version, replace or fix the certificate if needed, and upgrade macOS if the current OS cannot provide compliant TLS 1.2.
  • If a reverse proxy, load balancer, firewall, or other TLS termination point is in front of FileWave, fix the TLS configuration there.
  • If the failure is certificate-related, replace the certificate or chain. Check expiration, Subject Alternative Name, weak signature algorithms, weak key sizes, and missing intermediate certificates.
  • If SSL/TLS inspection is involved, bypass inspection for the FileWave endpoint so Apple devices see the real server certificate.
  • If only one network path fails, fix that path. The FileWave Server itself may not be the problem.

For current FileWave Server and Booster versions, focus on a compliant TLS 1.2 configuration with modern ciphersuites and a valid certificate trusted by Apple devices. TLS 1.3 can be used where available, but a TLS 1.3 failure alone is not the issue Apple is asking administrators to remediate.

4. Retest

After remediation, rerun the nscurl diagnostic or helper script for each endpoint. Then test the FileWave workflow that depends on that endpoint, such as ADE, MDM enrollment and check-in, profile installation, app installation, Kiosk or App Portal installation, software updates, or 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.

Related Content

No comments to display

Back to top