Prüfen Sie Ihre MDM-Server auf macOS 26.4, nicht auf 27

In Apples Anleitung zur Prüfung der TLS-Änderungen in OS 27 steht ein Satz, den die meisten Administratoren überlesen werden: Wenn Ihre Testgeräte unter Version 27 oder neuer laufen und Verbindungsfehler auftreten, sollten Sie erneut auf einem Gerät testen, das unter 26.4 oder neuer, aber vor 27 läuft — denn „nicht konforme Verbindungen werden blockiert, und diese fehlgeschlagenen Verbindungen können das Testen nachfolgender Verbindungen im Arbeitsablauf verhindern”.²

Wer auf dem neuen OS testet, findet einen defekten Server und übersieht alle übrigen. Unter 27 schlägt eine nicht konforme Verbindung fehl, und der Arbeitsablauf, der auf ihr aufbaute, bricht ab. Alles Nachgelagerte läuft nie an und wird deshalb auch nie geprüft. Unter 26.4 bis 26.x tauchen dieselben Probleme als Warnungen auf — ein einziger Durchlauf bringt damit jeden nicht konformen Server zum Vorschein, den Sie betreiben.

Zwei Dinge sagt Apple ausdrücklich: Ab Version 27 werden „nicht konforme Verbindungen blockiert, und die Protokollmeldungen erscheinen als Fehler statt als Warnungen”, und getestet werden sollte unter 26.4 oder neuer, aber vor 27, „um alle betroffenen Server zu identifizieren”.² Dass die Verbindungen unter diesen älteren Versionen tatsächlich zustande kommen, ist eine Auslegung und keine wörtliche Aussage — sinnvoll ist die Empfehlung allerdings nur dann, wenn es so ist. Eine blockierte Verbindung unter 26.4 würde den Arbeitsablauf genauso abschneiden wie unter 27.

Der Reflex ist, auf der Version zu testen, die die Änderung einführt. Hier führt dieser Reflex zu einer unvollständigen Liste — den Rest finden Sie dann einzeln im Produktivbetrieb.

TL;DR

Ab Version 27.0 von iOS, iPadOS, macOS, watchOS, tvOS und visionOS erzwingen ausgewählte Systemprozesse strengere TLS-Anforderungen für Verbindungen, die an MDM, Deklarativer Geräteverwaltung, Automatischer Geräteregistrierung, der Installation von Konfigurationsprofilen, der App-Installation einschließlich unternehmensinterner Verteilung sowie an Softwareupdates beteiligt sind.¹ Server müssen mindestens TLS 1.2 mit ATS-konformen Cipher Suites und Zertifikaten unterstützen.¹ SCEP- und Content-Caching-Server sind ausgenommen.² Der Netzwerkverkehr Ihrer eigenen App ist nicht betroffen. Prüfen Sie unter 26.4 bis 26.x, wo Verstöße als Warnungen protokolliert werden statt zu blockieren — mit dem Network Diagnostics Logging Profile und einer sysdiagnose.²

Was tatsächlich betroffen ist

Die Änderung gilt für eine konkrete Liste von Systemaktivitäten, nicht für den Netzwerkverkehr im Allgemeinen.¹

• Mobile Device Management (MDM)
• Deklarative Geräteverwaltung (DDM)
• Automatische Geräteregistrierung (Automated Device Enrollment)
• Installation von Konfigurationsprofilen
• App-Installation, einschließlich unternehmensinterner App-Verteilung
• Softwareupdates

Zwei Ausnahmen sind wichtig, weil beide genau die Art von Server betreffen, an der man sonst einen ganzen Tag verliert: Verbindungen zu einem SCEP-Server während der Installation eines Konfigurationsprofils oder beim Auflösen eines DDM-Assets sowie Verbindungen zu Content-Caching-Servern, selbst wenn Assets für App-Installationen oder Softwareupdates angefordert werden.²

Für Entwickler, die über eine Schlagzeile hierherkommen, sei es klar gesagt: Der URLSession-Verkehr Ihrer App ist nicht gemeint. Es geht um die Infrastruktur der Geräteverwaltung. App Transport Security regelt den Netzwerkverkehr von Apps schon, seit Apps gegen die SDKs von iOS 9.0 und macOS 10.11 gelinkt werden.³ Neu in 27 ist, dass eine Reihe von Systemprozessen vergleichbare Anforderungen nun auch auf den Verwaltungsdatenverkehr anwendet.

Die Plattformliste ist breiter, als „Mac-Flotte im Unternehmen” vermuten lässt. Apple nennt iOS, iPadOS, macOS, watchOS, tvOS und visionOS.² Ein Apple TV im Konferenzraum und eine Vision Pro im Designstudio registrieren sich über dieselbe Infrastruktur.

Die Anforderungen, aus der maßgeblichen Quelle

Laut Apples Support-Artikel müssen Server mindestens TLS 1.2 unterstützen, ATS-konforme Cipher Suites verwenden und gültige Zertifikate vorweisen, die den ATS-Vorgaben entsprechen.² Die Einzelheiten stehen in der ATS-Dokumentation — das ist die Seite, mit der Sie arbeiten sollten.³

Die standardmäßige Vertrauensprüfung des Servers muss bestehen: unversehrte Signatur, kein abgelaufenes Zertifikat, ein Name, der zum DNS-Namen des Servers passt, und eine Kette bis hinauf zu einem Ankerzertifikat, das von einer Zertifizierungsstelle ausgestellt wurde, die entweder Teil des Client-Betriebssystems ist oder von einem Benutzer oder Administrator installiert wurde.³

Darüber hinaus verlangt ATS:³

• Ein Zertifikat, signiert mit einem RSA-Schlüssel von mindestens 2048 Bit oder einem ECC-Schlüssel von mindestens 256 Bit
• Ein Zertifikat, das SHA-2 mit einem Digest von mindestens 256 Bit verwendet
• TLS 1.2 oder neuer
• Datenaustausch mit AES-128 oder AES-256
• Perfect Forward Secrecy über einen ECDHE-Schlüsselaustausch

Die letzten beiden Punkte tauchen in Zusammenfassungen dieser Änderung selten auf — auch nicht in der Verstoßtabelle, die Apple für die Prüfung veröffentlicht. Wer nur das behebt, was die Protokolle benennen, kann bei der Wahl der Cipher Suite weiterhin nicht konform sein.

Prüfen, bevor es Sie einholt

Das von Apple dokumentierte Vorgehen ist präzise, und jeder Schritt hat seinen Grund.²

Verwenden Sie Testgeräte mit 26.4 oder neuer, aber vor 27. Das ist der eigentliche Kniff. Verstöße werden als Warnungen protokolliert, die Verbindungen kommen zustande, und der Arbeitsablauf läuft weiter zum nächsten Server.

Installieren Sie das Network Diagnostics Logging Profile und starten Sie das Gerät anschließend neu. Es muss vor jedem Test installiert sein, sonst enthalten die Protokollereignisse nicht die Details, die zur Identifizierung nicht konformer Verbindungen nötig sind.

Für die Automatische Geräteregistrierung auf iPhone oder iPad verwenden Sie Apple Configurator für Mac, um das Profil zu installieren, bevor das Gerät im Konfigurationsassistenten den Bereich für die Geräteverwaltung erreicht. Der Registrierungsdatenverkehr fällt früh an; ein später installiertes Profil bekommt ihn nicht mehr mit.

Durchlaufen Sie Ihre normalen Arbeitsabläufe. Registrieren Sie das Gerät, installieren Sie Apps und Profile und stoßen Sie alles an, was mit Ihren Servern kommuniziert. Ziel ist es, Datenverkehr zu jedem Server zu erzeugen, der betroffen sein könnte.

Erstellen Sie eine sysdiagnose, übertragen Sie sie auf einen Mac, entpacken Sie das Archiv und filtern Sie in dessen oberstem Verzeichnis das Protokoll:

log show --archive system_logs.logarchive --info \
  -P "p=appstoreagent|appstored|managedappdistributionagent|managedappdistributiond|ManagedClient|ManagedClientAgent|mdmclient|mdmd|mdmuserd|MuseBuddyApp|NanoSettings|Preferences|profiled|profiles|RemoteManagementAgent|remotemanagementd|Setup|'Setup Assistant'|'System Settings'|teslad|TVSettings|TVSetup|XPCAcmeService AND s=com.apple.network AND m:'ATS Violation'|'ATS FCPv2.1 violation'"

Jedes Ereignis enthält eine Domain, den Prozess, der die Verbindung aufgebaut hat, und eine Warnung, die die verletzte Anforderung benennt. Eine einzelne Verbindung kann mehrere Warnungen auslösen, wenn der Server an mehreren Anforderungen scheitert.²

Decken Sie Ihre Konfigurationen ab, nicht nur Ihre Geräte. Apples Dimensionen lassen sich unverändert übernehmen: Umgebung (Produktion, Staging, Test), Gerätetyp, Rolle (Benutzergruppe, Kiosk, gemeinsam genutztes Gerät) und Registrierungsart (Automatische Geräteregistrierung, accountbasiert, profilbasiert, Shared iPad).² Unterschiedliche Konfigurationen erreichen unterschiedliche Server; eine saubere Prüfung der einen sagt nichts über die andere aus.

watchOS lässt sich auf diesem Weg nicht prüfen. Der Netzwerkverkehr läuft dort größtenteils außerhalb des Prozesses ab, und der Befehl log funktioniert nicht. Apples Empfehlung: Tests unter iOS dürften die Verbindungen der Apple Watch ausreichend abdecken.²

Die Verstöße richtig lesen

Apple unterteilt die Fehler in zwei Klassen — und in der zweiten scheitern Server, die auf den ersten Blick konform aussehen.

Allgemeine Verstöße gegen die ATS-Richtlinie, protokolliert als Warning [ATS violation]:²

In dieser Tabelle steckt eine nützliche Ausnahme: Gehört das Zertifikat, das die Vertrauensprüfung nicht besteht, zu den Ankerzertifikaten des Profils für die automatische Registrierung, ist keine Behebung erforderlich.²

Verstöße gegen FCP v2.1, protokolliert als Warning [ATS FCPv2.1 violation]:²

Die letzte Zeile ist die, die für Überraschungen sorgen wird. Ein Server kann die vielzitierte Hauptanforderung erfüllen — TLS 1.2 mit moderner Cipher Suite und gültigem Zertifikat aushandeln — und trotzdem durchfallen, weil das Functional Package for TLS zusätzlich die Erweiterung „extended master secret” verlangt. Apples Abhilfe: auf TLS 1.3 wechseln oder TLS 1.2 zumindest so konfigurieren, dass EMS ausgehandelt wird.²

Eine Feinheit sollte man dabei auseinanderhalten. Der FCP-v2.1-Konformitätsmodus von ATS muss von Apps ausdrücklich aktiviert werden, über NSRequiresNIAPTLSPackageVersion; er existiert für regulierte Umgebungen.³ Diese Aktivierung steuert das Client-Verhalten Ihrer eigenen App. Auf die Systemprozesse von OS 27 hat sie keinen Einfluss — die prüfen Ihre Server nach FCP v2.1, ganz gleich, ob eine Ihrer Apps sich jemals für irgendetwas entschieden hat.

Was sich unter 27 ändert

Ab Version 27 werden nicht konforme Verbindungen blockiert, und die Protokollmeldungen erscheinen als Fehler statt als Warnungen.²

Apple weist darauf hin, dass es für mehrere Warnungen kein direktes Fehleräquivalent gibt und dass bei Problemen mit Cipher Suite, TLS-Version und Signaturalgorithmus der genaue clientseitige Fehler „davon abhängen kann, wie der Server diesen Zustand behandelt”.² Erwarten Sie also keine saubere Zuordnung von Warnung zu Fehler.

Der einzige konkrete Fehler, den Apple dokumentiert, betrifft blockiertes unverschlüsseltes HTTP — auch dann, wenn eine Weiterleitung auf einer http://-URL landet:²

Task . finished with error [-1022] Error Domain=NSURLErrorDomain Code=-1022
"The resource could not be loaded because the App Transport Security policy
requires the use of a secure connection."

Um einen einzelnen Server nach der Behebung zu überprüfen, verbindet sich nscurl mit verschiedenen Kombinationen von ATS-Ausnahmen und grenzt so ein, welche Anforderung noch scheitert — ohne einen vollständigen sysdiagnose-Durchlauf.³

Wie die Behebung aussieht

Die Prüfung liefert eine Liste von Domains und Verstößen. Der Weg von dort zu konkreten Serveränderungen zerfällt in drei Fälle.

Wechseln Sie auf TLS 1.3, wo immer es geht. Damit erledigen Sie mehrere Verstoßklassen auf einmal statt einzeln. Jede TLS-1.3-Cipher-Suite bietet Perfect Forward Secrecy, die Warnung über eine Suite ohne PFS kann also gar nicht mehr auftreten. Die Anforderung „extended master secret” ist spezifisch für TLS 1.2 und entfällt damit. Die Aushandlung der Signaturalgorithmen ist von vornherein strenger. Auch Apples eigene Spalte zur Abhilfe empfiehlt, Server nach Möglichkeit auf TLS 1.3 umzustellen, mit TLS 1.2 als Untergrenze.²

Wenn Sie auf TLS 1.2 festgelegt sind, tragen drei Einstellungen die Hauptlast. Aktivieren Sie die Erweiterung „extended master secret” — das ist der Verstoß, der eine ansonsten moderne Konfiguration am ehesten überrascht. Beschränken Sie die Liste der Cipher Suites auf ECDHE-Schlüsselaustausch mit AES-128 oder AES-256; damit erfüllen Sie die PFS-Anforderung und die Anforderung an die symmetrische Verschlüsselung in einem Zug.³ Und entfernen Sie jeden rsa_pkcs15_sha1-Signaturalgorithmus aus der Präferenzreihenfolge des Servers.

Festgelegt zu sein, kommt häufiger vor, als es klingt. Ein Load Balancer, der TLS terminiert, eine Hardware-Appliance mit Wartungsvertrag oder ein eingebetteter Management-Controller — jedes davon kann der Grund sein, warum eine modern wirkende Umgebung etwas Altes aushandelt.

Zertifikatsprobleme brauchen eigene Vorlaufzeit. RSA unter 2048 Bit, ECDSA unter 256 Bit und Blattzertifikate, die mit etwas Schwächerem als SHA-256 gehasht sind, erfordern eine Neuausstellung statt einer Umkonfiguration. Das bedeutet: eine Anfrage bei der Zertifizierungsstelle, ein Wartungsfenster und Abstimmung mit denjenigen, denen die Kette gehört. Prüfen Sie auch die Zwischenzertifikate, denn die standardmäßige Vertrauensprüfung durchläuft die gesamte Kette bis zum Anker.³

Eine Ausnahme spart Arbeit: Gehört das Zertifikat, das die Vertrauensprüfung nicht besteht, zu den Ankerzertifikaten des Profils für die automatische Registrierung, ist laut Apple keine Behebung nötig.² Prüfen Sie das, bevor Sie ein Ticket eröffnen.

Überprüfen Sie jede Korrektur einzeln, statt die gesamte Prüfung erneut zu fahren. nscurl verbindet sich mit einem einzelnen Server über verschiedene Kombinationen von ATS-Ausnahmen und grenzt damit genau ein, welche Anforderung noch scheitert.³ Ein vollständiger sysdiagnose-Durchlauf pro Iteration ist eine zähe Schleife, wenn Sie ohnehin darauf warten, dass ein Anbieter neu ausrollt.

Warum die Vorlaufzeit entscheidend ist

Apple schreibt unmissverständlich, dass die Aktualisierung von Serverkonfigurationen „erhebliche Zeit in Anspruch nehmen kann, insbesondere bei Servern, die von externen Anbietern betreut werden”.²

Dieser Satz ist der Grund, die Prüfung jetzt durchzuführen und nicht erst, wenn 27 breit ausgeliefert wird. Die betroffenen Server gehören häufig gar nicht Ihnen: die Endpunkte eines MDM-Anbieters, ein Partner für die Softwareverteilung, ein Identitätsanbieter, der der Registrierung vorgelagert ist. Im Oktober zu erfahren, dass ein Anbieter ein ganzes Quartal braucht, um EMS auf seinen TLS-1.2-Endpunkten zu aktivieren, ist ein anderes Problem, als es im August zu erfahren.

Die Prüfung liefert eine Liste von Domains und den Prozessen, die sie erreicht haben. Genau diese Liste schicken Sie an Ihre Anbieter, und ihre Konkretheit ist es, die für Priorität sorgt. „Ihr Server erfüllt Apples neue Anforderungen nicht” lässt sich leicht nach hinten schieben. „Ihr Endpunkt unter dieser Domain hat TLS 1.2 ohne extended master secret ausgehandelt, was OS 27 für Registrierungsverkehr blockiert” dagegen nicht.

Das ist dasselbe Muster wie bei anderen Änderungen in dieser Version. macOS 27 fragt nicht mehr nach, bevor es den teamübergreifenden Container-Zugriff verweigert, und Bilder in Menüeinträgen hängen jetzt davon ab, gegen welches SDK Sie gelinkt haben. In beiden Fällen hat die Plattform ein Signal entfernt oder eine Voreinstellung verschärft — und der Fehler tritt in Gestalt von etwas ganz anderem auf. Hier ist dieses andere eine Registrierung, die hängen bleibt.

Die wichtigsten Erkenntnisse

Für IT-Administratoren: - Prüfen Sie unter 26.4 bis 26.x. Ein Test unter 27 blockiert beim ersten Fehler und verbirgt alles Nachgelagerte im selben Arbeitsablauf. - Installieren Sie das Network Diagnostics Logging Profile vor dem Test und starten Sie das Gerät neu — sonst benennen die Protokolle die Server nicht. - Decken Sie Konfigurationen ab statt Geräte: Umgebung, Gerätetyp, Rolle und Registrierungsart erreichen jeweils unterschiedliche Server. - Schicken Sie Ihren Anbietern die Domain, den Prozess und den konkreten Verstoß. Die Vorlaufzeit bei externen Servern ist der begrenzende Faktor.

Für Entwickler von MDM- und Geräteverwaltungslösungen: - SCEP- und Content-Caching-Server sind ausgenommen. Verschwenden Sie keine Prüfzeit auf sie. - Die ATS FCPv2.1-Verstöße sind von den allgemeinen ATS-Richtlinienverstößen getrennt, und TLS 1.2 ohne EMS wird am ehesten übersehen. - Unter watchOS funktioniert der Log-Befehl nicht. Decken Sie die Verbindungen der Watch über Tests unter iOS ab.

Für alle, die dazu nur eine Schlagzeile gelesen haben: - Der URLSession-Verkehr Ihrer eigenen App ist nicht das, was sich geändert hat. Betroffen sind Systemprozesse, die Verwaltungs-, Registrierungs-, Installations- und Update-Verbindungen abwickeln.

FAQ

Betrifft das die Netzwerkanfragen meiner App?

Nein. Die Änderung gilt für Systemprozesse, die an MDM, DDM, der Automatischen Geräteregistrierung, der Installation von Konfigurationsprofilen, der App-Installation und Softwareupdates beteiligt sind.¹ App Transport Security regelt den Netzwerkverkehr von Apps separat, seit Apps gegen die SDKs von iOS 9.0 und macOS 10.11 gelinkt werden.³

Warum auf einer älteren OS-Version prüfen?

Weil die Fehler unter 27 blockieren. Apple stellt fest, dass nicht konforme Verbindungen blockiert werden und „diese fehlgeschlagenen Verbindungen das Testen nachfolgender Verbindungen im Arbeitsablauf verhindern können”, und empfiehlt Tests unter 26.4 oder neuer, aber vor 27, um alle betroffenen Server zu identifizieren.² Unter diesen Versionen werden die Verstöße als Warnungen protokolliert, während die Verbindungen weiterhin zustande kommen.

Welche Server sind ausgenommen?

SCEP-Server während der Installation eines Konfigurationsprofils oder beim Auflösen eines DDM-Assets sowie Content-Caching-Server, selbst wenn Assets im Zusammenhang mit App-Installationen oder Softwareupdates angefordert werden.²

Mein Server nutzt TLS 1.2 mit gültigem Zertifikat. Kann er trotzdem scheitern?

Ja. Zu den FCP-v2.1-Prüfungen gehören TLS 1.2 ohne die Erweiterung „extended master secret”, ein Zertifikat, das mit einem im ClientHello nicht angekündigten Algorithmus signiert wurde, sowie rsa_pkcs15_sha1-Signaturalgorithmen.² ATS verlangt zudem AES-128 oder AES-256 sowie Perfect Forward Secrecy über ECDHE.³

Ändert sich daran etwas, wenn ich in meiner App die NIAP-Konformität aktiviere?

Nein — und die beiden Dinge werden leicht verwechselt. NSRequiresNIAPTLSPackageVersion schaltet das Client-Verhalten Ihrer eigenen App in den strengeren FCP-Modus für regulierte Umgebungen.³ Die Systemprozesse von OS 27 wenden ihre eigenen Anforderungen unabhängig davon auf den Verwaltungsdatenverkehr an.

Quellen