Skip to main content

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

What

Starting with version 27.0 of iOS, iPadOS, macOS, watchOS, tvOS, and visionOS, Apple applies stricter network-security requirements to connections used by system processes. Non-compliant connections in the affected management and installation workflows can be blocked. Audit the endpoints your devices actually contact rather than treating this as a future beta-only change.

Prepare your network environment for stricter security requirements

FileWave servers have been successfully tested using Apple's provided methods

Apple's requirements cover the affected system-process connections used for device management and installation. On version 27 or later, non-compliant connections are blocked and diagnostic log entries appear as errors rather than the warnings used for pre-enforcement auditing.

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.

Exceptions: Apple excludes connections to SCEP servers while installing a configuration profile or resolving a DDM asset, and connections to content-caching servers, from these additional requirements. These exceptions do not exempt the other FileWave-related endpoints in the same workflow.

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 ECDHE key exchange for Perfect Forward Secrecy, AEAD ciphersuites based on AES-GCM with SHA-256, SHA-384, or SHA-512, and the extended master secret (EMS) 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.

1.1 Audit the connections made by real device workflows

A successful test of one Server URL does not prove that every endpoint used during enrollment or deployment is compliant. Use Apple's network-security audit procedure to discover the connections made by representative devices, then validate each affected server with the endpoint checks below.

  1. Plan representative coverage. Include the production and test environments, device types, user or kiosk roles, enrollment methods, and network paths used by your organization.
  2. Choose test devices. Apple's logging audit requires iOS, iPadOS, macOS, tvOS, or visionOS 26.4 or later. If a version-27 connection failure prevents the workflow from reaching later endpoints, repeat the audit on a device running 26.4 or later but earlier than 27 to discover the remaining non-compliant connections. This is an audit technique, not a recommendation to downgrade production devices.
  3. Enable the diagnostic logging first. Install Apple's Network Diagnostics Logging Profile from Profiles and Logs, then restart the test device before testing. For iPhone or iPad ADE testing, Apple directs administrators to use Apple Configurator for Mac to install the profile before the device reaches the Device Management pane in Setup Assistant.
  4. Exercise the real workflows. Test enrollment, check-in, profile installation, app installation, and software updates that apply to the device. Include customer-managed Boosters and any proxy, load balancer, or custom domain along those paths.
  5. Collect and examine a sysdiagnose. Follow Apple's linked procedure to collect the diagnostic archive, expand it on a Mac, and run the supplied log show filter against system_logs.logarchive. Review the domain, process, and violation for ATS violation and ATS FCPv2.1 violation entries. On version 27 or later, violations appear as errors; the precise error can differ from the earlier warning text.
  6. Remediate and repeat. Give the affected endpoint owner the exact violation, fix that endpoint, and repeat the workflow to confirm that subsequent connections also succeed. Apple notes that most watchOS networking runs out of process, so its log command does not work there; testing the corresponding iOS workflow likely provides sufficient Apple Watch coverage.

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