Skip to main content

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

What

Apple is tightening network securityTLS 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 FileWaveFileWave, environments,check this can include aany customer-managed FileWave Server, FileWave Booster, reverse proxy, load balancer, custom hosted domain, or other HTTPS endpoint that Apple devices reachcontact duringfor 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 need to:must:

  • 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 also 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 useconnect to customer-owned FileWave infrastructure.

infrastructure,

Checksuch theas environmentan if:

on-premise
    FileWave FileWaveServer, a macOS Server or Booster is running on macOS, especially an older macOS version. FileWave Server is on-premise or behindBooster, a customer-managed Booster, a reverse proxy, a 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,domain, or a manually managed certificates. certificate.

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

    How

    1. InventoryList the HTTPS endpoints Appleto devices usetest

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

    • The FileWave Server URL used by clients and enrolled devices
    • Any externallyExternally 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:

    on
      Thethe FileWave Server Mac itself, if FileWave Server is runningMac, on macOS The FileWavea Booster MacMac, itself,or iffrom the Booster is running on macOS Anyany other Mac that can reach the FileWave Server, Booster, reverse proxy, load balancer, or custom domainendpoint being testedtested.

      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 throughuse different paths, such as internal DNS, external DNS, VPN, a reverse proxy, a load balancer, or a different Booster,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 for the negotiated TLS protocol, cipher, certificate verification result, and certificate signature algorithm.check:

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

      After downloading the attachment: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

      TheA nscurlfailed result does not automatically mean that macOS is unsupported. It means the primarytested 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, theHTTPS endpoint passesdid not meet Apple's diagnostic. If Standard ATS passes but ATS/FCP_v2.1 fails,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, update FileWave if needed, replace or fix the endpointcertificate, mayand workupgrade todaymacOS but should be remediated before Apple enforcesif the strictercurrent requirement.OS

        cannot provide compliant TLS.

        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, orother TLS termination point sois itin supportsfront of FileWave, fix the TLS 1.2configuration there. If the failure is certificate-related, replace the certificate or later.chain. PreferCheck 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 aexpiration, Subject Alternative Name, signedweak withsignature SHA-1, usingalgorithms, weak key sizes, orand missing required intermediate certificates. MakeIf sureSSL/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.

          When possible, use TLS 1.3. At minimum, use TLS 1.2 with modern ciphersuites and a valid 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.4. Retest the FileWave workflows

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

          Back to top