Sophos Mobile: SCEP-Zertifikate und Verbindungswege sicher prüfen

SCEP kann in Sophos Mobile (MDM) Zertifikate installieren und erneuern. Dieser Ablauf behandelt die tenantseitige SCEP-Anbindung und die dafür zu unterscheidenden Verbindungen – nicht die vollständige Einrichtung einer Windows-CA, einer WLAN-/VPN-Infrastruktur oder sämtlicher Android-, Apple- und Windows-Policy-Payloads. SCEP-Installation und -Erneuerung nach diesem Ablauf unterstützen keine Chromebooks.

Vor produktiver Änderung: CA-/PKI-, Netzwerk- und MDM-Verantwortliche sowie gegebenenfalls der Betreiber des WLAN-/VPN-Authentifizierungsdienstes legen gemeinsam fest, welche Geräte und Enrollment-Modi betroffen sind, ob und wie ein konkreter Dienst das SCEP-Zertifikat verwenden kann und wie die Geräte bei Netzverlust noch erreicht werden. Weder Save noch eine verteilte Policy beweist, dass ein Clientzertifikat ausgestellt, erneuert oder einem WLAN-/VPN-Profil zugeordnet wurde.

Drei Verbindungen statt einer pauschalen Portfreigabe

Sophos Fusion verbindet sich zur eigenen SCEP-fähigen CA; das verwaltete Gerät kommuniziert separat mit Sophos Mobile. Eine spätere Authentifizierung am WLAN-/VPN-Dienst mit genau dem SCEP-Zertifikat ist nicht automatisch gegeben und muss je Plattform und Profil nachgewiesen werden. Tenant meint hier die eigene Sophos-Mobile-Umgebung, MDM deren Geräteverwaltung.

Tenant-Region bestimmen: In Sophos Fusion unter My Products > Mobile die URL in der Adressleiste des Browsers prüfen. Die Region steht im ersten Bestandteil des Hostnamens, also vor dem ersten Punkt, direkt nach smc-user-if-cloudstation-. Im Beispiel smc-user-if-cloudstation-eu-west-1 ist die Region eu-west-1. Für die Freigaben die Region aus der eigenen Browser-URL verwenden, nicht den Beispielwert oder einen gleichlautenden Text im URL-Pfad oder in den Abfrageparametern. Die Hosting-Region wird beim Anlegen des Sophos-Fusion-Kontos gewählt; für bestehende Konten wird sie hier aus der tatsächlichen Browser-URL ermittelt. Dieser Admin-Host ist weder Geräte-Endpunkt noch SCEP-Server. Die Regionsbestimmung gilt auch für Mobile Threat Defense, sagt aber nichts über eine eigenständige MTD-SCEP-Funktion aus.
Fusion zu eigenen Servern (eingehend): Für SCEP nennt die aktuelle regionale Quell-IP-Liste für die konkrete Inbound-Freigabe TCP 443, für die davon getrennte LDAP-/AD-Verbindung TCP 636. Nur die dort aktuell für die tatsächliche Tenant-Region veröffentlichten Mobile-Quell-IPs zum jeweils vorgesehenen eigenen SCEP- beziehungsweise AD-Ziel freigeben. Nicht die Beispielregion übernehmen, keine globale oder unbeschränkte Inbound-Regel erstellen. Die LDAP-/AD-Verbindung dient der Benutzerauthentifizierung mit AD-Anmeldeinformationen bei der Geräteregistrierung über Apple Business (vormals Apple Business Manager), Google Zero-touch oder Samsung KME. Diese Authentifizierung ist weder die erste SCEP-Clientzertifikatsausstellung an ein verwaltetes Gerät noch dessen spätere Zertifikatserneuerung.
Gerät zu Sophos Mobile (ausgehend): Verwaltete Geräte benötigen HTTPS 443 zum regionalen smc-device-if-cloudstation--Host. Die vollständigen Geräteziele sind smc-device-if-cloudstation-eu-central-1.prod.hydra.sophos.com für eu-central-1, smc-device-if-cloudstation-eu-west-1.prod.hydra.sophos.com für eu-west-1, smc-device-if-cloudstation-us-west-2.prod.hydra.sophos.com für us-west-2 und smc-device-if-cloudstation-us-east-2.prod.hydra.sophos.com für us-east-2, jeweils über HTTPS 443. Nur das Ziel der zuvor ermittelten tatsächlichen Tenant-Region verwenden; diese Geräteziele sind nicht der Admin-Host und nicht die eigenen SCEP-Ziele. Zusätzlich sind Push-, Enrollment- und weitere Plattformverbindungen erforderlich. Die folgenden getrennten Prüfwege und internen Plattformleitfäden ordnen diese nach Gerätetyp und tatsächlich genutzter Funktion ein; die vier regionalen Gerätehosts sind keine vollständige Egress-Liste. Diese zusätzlichen Ziele sind weder SCEP-Inbound-Quell-IPs noch eine pauschale SCEP-Portliste.

Weitere Geräte-Egress-Abhängigkeiten getrennt halten:

Windows-Push: Für Windows-Computer sind für Windows Notification Service (WNS) und Microsoft Push Notification Service (MPNS) die Ziele *.notify.windows.com, *.wns.windows.com und *.notify.live.net dokumentiert, jeweils über HTTPS 443. Das sind Windows-Push-Verbindungen, keine SCEP-Inbound-Ports.
Android-Enrollment und Provisioning: Für Android den Android-Enterprise-Leitfaden und für QR-/Zero-touch-/KME-Voraussetzungen den Provisioning-Leitfaden heranziehen; dort bleibt die Freigabe nach konkretem Gerät und Modus zu prüfen.
Apple-Management-Push: Für die Verwaltung von iPhones, iPads und Macs den Apple-Push-Pfad separat prüfen; Zertifikatsidentität, Erneuerung und die auf iPhone/iPad verfügbare Erreichbarkeitsprüfung beschreibt der APNs-Leitfaden.
Apple-Updateinformationen und Compliance: Davon getrennt benötigt Sophos Mobile Informationen über verfügbare Apple-Updates: Ist der dafür vorgesehene Apple-Dienst nicht erreichbar, fehlen diese Informationen und Compliance-Regeln zu verpflichtenden Updates haben keine Wirkung. Den eigenen Netzpfad und die Plattform-, OS- und Enrollment-Grenzen im Compliance-Leitfaden prüfen. Apple-Management-Push und Updateinformationen sind Geräte-Egress-Anforderungen, keine SCEP-Inbound- oder Zertifikatsausstellungs-Endpunkte.
IXM-App-Verkehr: Für iPhone/iPad mit Sophos Intercept X for Mobile (IXM) die separaten App-Verbindungen im IXM-Netzwerkleitfaden prüfen; dort sind Dienst-/Portzuordnung und Grenzen nach App-Version, Edition, Verwaltungsart und tatsächlich genutzter Funktion beschrieben. Das sind keine SCEP-Inbound-Verbindungen; aus der Apple-Überschrift einer Netzwerkliste folgt keine IXM-Anwendbarkeit auf Macs.

Eine dokumentierte Zieladresse ist noch kein Nachweis der Erreichbarkeit im eigenen Netz.

Für eine Störung daher getrennt protokollieren, ob (a) Fusion den eigenen SCEP-Endpunkt erreicht, (b) das Gerät Sophos Mobile erreicht und seine Policy erhält und (c) der WLAN-/VPN-Dienst das ausgestellte Zertifikat akzeptiert. Ein Erfolg auf einem Pfad ersetzt die beiden anderen Prüfungen nicht.

Vertrauen und Zuständigkeiten vorab festlegen

Begriffe für die Entscheidung: PKI bezeichnet die Zertifikatsinfrastruktur, CA deren ausstellende Stelle. SCEP fordert das Clientzertifikat an; Subject und SAN (Subject Alternative Name), gegebenenfalls UPN (Benutzerkennung), bestimmen die zu prüfende Identität. EAP ist das Authentifizierungsverfahren eines WLAN-Dienstes. Ein PKCS-#12-Import (.pfx) ist eine andere Bereitstellung als SCEP; sein Zertifikat wird durch das SCEP-Erneuerungsintervall nicht automatisch erneuert.

Die drei Vertrauensfragen getrennt entscheiden, auch wenn dieselbe CA in der eigenen PKI mehrere Rollen übernimmt:

Verbindung zum SCEP-Server: Das MDM-Team stellt vor SCEP eine Root certificate-Konfiguration mit dem CA-Zertifikat des SCEP-Servers in der passenden Policy bereit. Bei Android-Enterprise-Gerätepolicies das Zertifikat zusätzlich im SCEP-Feld Root certificate aus den Zertifikaten derselben Policy auswählen. Das ist nicht das ausgestellte Clientzertifikat und beweist keine Clientidentität.
Ausgestellte Clientidentität: Bei Android Enterprise und iOS muss der Subject nach Ersetzung aller Platzhalter ein gültiger X.500-Name der vorgesehenen Person oder des Geräts sein. Den SAN-Typ und -Wert gesondert festlegen; AD user logon name bezeichnet in den Geräte-SCEP-Feldern den AD-UPN des Benutzers, nicht eine beliebige Gerätekennung. Das iOS-Feld CA name ist ein von der CA verstandener Name, etwa zur Unterscheidung ihrer Instanzen – kein Nachweis für den Issuer oder einen Vertrauensanker. Das PKI-/CA-Team prüft daher am tatsächlich ausgestellten Zertifikat ausstellende CA und Kette, erlaubte Subject-/SAN-/UPN-Werte, Schlüsselverwendung und Zugriff auf den privaten Schlüssel. Das MDM-/Dienstteam stimmt den tatsächlichen Identitätsabgleich mit dem verwendenden Dienst ab; keine Beispielplatzhalter übernehmen.
Vertrauen des Dienstes: Wenn WLAN/VPN das Clientzertifikat verwenden soll, muss der verwendende Dienst dessen CA-Kette vertrauen. Bei EAP ist zusätzlich das Vertrauen des Geräts in das WLAN-Serverzertifikat zu prüfen. Keiner dieser Nachweise folgt allein aus dem SCEP-Server-Trust.

Verantwortliche vor Freigabe:

PKI-/CA-Team: SCEP-fähige Windows-CA, Erreichbarkeit von /CertSrv/MSCEP_ADMIN und /CertSrv/MSCEP sowie Berechtigung für Challenge-Erstellung und Zertifikats-Enrollment prüfen. Challenge-Kennwörter, Dienstzugang und private Schlüssel nicht in Tickets oder Screenshots ablegen. Der historische Windows-2003-Hinweis in der Sophos-Hilfe ist keine aktuelle Server-Supportzusage.
Netzwerkteam: Ziel-FQDN, TLS-/HTTP-Proxy-Weg und eng begrenzte regionale Quell-IP-Freigabe gegen die reale Topologie prüfen; separat Geräte-Egress, Push und unabhängigen Management-/Netzpfad für den Notfall prüfen. Keine Prüfung durch generelles Abschalten der Filter ersetzen.
MDM-/Dienstteam: Plattform, Geräte- oder Benutzer-Policy-Typ und Enrollment-Modus vor der Konfiguration festlegen. Für den hier beschriebenen Android-Enterprise-Gerätepfad eine Android Enterprise device policy verwenden; eine Work-Profile-Policy ist ein anderer Verwaltungsbereich. Der Android-Enterprise-Leitfaden erklärt diese Modusentscheidung. Den iOS-Geräte-SCEP-Payload separat behandeln und nicht als Nachweis für iOS-Benutzerpolicies verwenden. Die gemeinsamen und plattformspezifischen SCEP-Felder werden im Pilotablauf unten getrennt geprüft. Ohne bestätigten Policy-Typ und unterstützten Enrollment-Modus stoppen.

Stopp, wenn die vorgesehene Identität oder CA-Vertrauenskette ungeklärt ist, der Gerätetyp/Modus nicht zur geprüften Policy passt oder das Gerät nur über genau das zu wechselnde WLAN/VPN verwaltbar wäre und kein unabhängiger Rückweg besteht.

Zertifikatsausstellung ist noch keine WLAN-/VPN-Zuordnung

Die SCEP-Konfiguration fordert ein Zertifikat bei der CA an. Vor einer WLAN-/VPN-Änderung getrennt prüfen:

WLAN-Auswahlfeld: Bei Android-Enterprise-Gerätepolicies und iOS-Gerätepolicies wählt Identity certificate ein Zertifikat aus einer Client certificate-Konfiguration derselben Policy. Diese Konfiguration importiert eine PKCS-#12-Datei (.pfx); sie ist eine andere Bereitstellungsart als SCEP. Damit ist nicht belegt, dass im WLAN-Auswahlfeld ein per SCEP ausgestelltes Zertifikat auswählbar ist. Ein EAP-WLAN für Android Enterprise darf nicht versteckt sein: Die SSID muss ausgestrahlt werden.
Erneuerung und Serververtrauen: Import, Gültigkeit und Austausch von PKCS-#12-Zertifikaten separat planen; SCEP renewal interval erneuert diese nicht automatisch. Das Root-Zertifikat für den EAP-Server in der WLAN-Policy ist nicht pauschal mit dem SCEP-Server-Trust gleichzusetzen.

Auch VPN ist kein einheitlicher Anschluss an SCEP: Bei Android Enterprise wählt die Policy eine bereits installierte verwaltete Google-Play-VPN-App; die Verbindungsparameter liegen in deren Managed Configuration. Bei iOS hängen Zertifikatsauthentifizierung und Zertifikatsauswahl vom Verbindungstyp ab. Diese Auswahl allein belegt nicht, dass ein SCEP-Zertifikat verwendet werden kann. Vor einem WLAN-/VPN-Pilot die unterstützte Zertifikatszuordnung und das Verhalten nach Erneuerung für Plattform, Policy-Typ, Authentifizierungsart und gegebenenfalls VPN-Client anhand passender Herstellerbelege oder im abgegrenzten Pilot bestätigen. Fehlt dieser Nachweis, den Pilot auf SCEP-Ausstellung und -Erneuerung begrenzen; keine WLAN-/VPN-Migration oder Entziehung der bisherigen Vertrauenskette auslösen.

SCEP nur im begrenzten Pilot einrichten

Unter Setup > Sophos setup > SCEP die SCEP-Server-URL https://<server>/CertSrv/MSCEP und Challenge-URL https://<server>/CertSrv/MSCEP_ADMIN mit der PKI abstimmen. Einen dazu berechtigten Benutzer im Format username@domain und sein Passwort verwenden; zugelassene Challenge-Zeichentypen und Berechtigungen mit der PKI prüfen. Die abgestimmten Zeichentypen im Feld Challenge characters für das Challenge-Kennwort auswählen, bevor Save ausgeführt wird; die von Sophos voreingestellte Challenge-Länge beibehalten. Eine abweichende PKI-Vorgabe nur als gesondert dokumentierte, genehmigte und getestete Ausnahme übernehmen. Ist ein HTTP-Proxy aktiviert, gilt Use HTTP proxy für diese Verbindung zunächst; die Option nur deaktivieren, wenn Sophos Mobile den SCEP-Server bewusst am Proxy vorbei erreichen soll.
Save ausführen und den Verbindungstest zum SCEP-Server dokumentieren. Bei Fehler URL, Zertifikatsvertrauen, Proxy, Berechtigungen und erlaubte Quell-IPs mit den Zuständigen prüfen – nicht sofort breitflächig Policies ändern.
Zuerst eine zum Pilotmodus passende Policy erstellen oder eine bestehende Policy bearbeiten. Für Erstellung, Konfigurationsbearbeitung, Speichern und anschliessende Pilotzuweisung den Richtlinienleitfaden heranziehen; Plattform und unterstützten Policy-Typ vorab abgleichen. In dieser Policy zuerst Root certificate mit dem CA-Zertifikat des SCEP-Servers, danach SCEP und SCEP renewal interval konfigurieren. Für die SCEP-Felder URL und Challenge beschreiben die Android-Enterprise- und iOS-Geräte-Policyhilfen die Platzhalter %_SCEPPROXYURL_% beziehungsweise %_CACHALLENGE_% für die zuvor eingerichtete SCEP-Server- beziehungsweise Challenge-URL; Subject, SAN/UPN, Schlüsselgrösse und Verwendungszweck mit PKI und Ziel-Dienst für die konkrete Plattform abstimmen. Nur der abgegrenzten Pilotgruppe zuweisen. PKI und MDM legen vorab für genau diese Plattform und diesen Policy-Modus fest, wo Policy-Zustellung, Gerätezertifikat und PKI-Ausstellung/Erneuerung beobachtbar sind; bei zusätzlich belegter WLAN-/VPN-Zuordnung auch das Dienst-Log festlegen. Keine einheitlichen Statusfelder oder Lognamen für alle Geräte voraussetzen. SCEP renewal interval bestimmt die Anforderung durch das Gerät, nicht den Erfolg.
Plattformspezifische SCEP-Felder: Bei Android-Enterprise-Gerätepolicies einen erkennbaren Alias name für Auswahldialoge festlegen und im Feld Root certificate das CA-Zertifikat des SCEP-Servers aus derselben Policy auswählen. Bei iOS-Gerätepolicies CA name mit der CA abstimmen; Retries zählt Wiederholungen nach einer Serverantwort pending, und Retry delay legt den Abstand in Sekunden fest. Diese iOS-Felder nicht als Android-Felder darstellen. Key size muss zur SCEP-Serverkonfiguration passen. Bei Certificate usage die beabsichtigte Verwendung getrennt als Use as digital signature oder Use for encryption mit PKI und Dienst abstimmen; keine Standardgrösse oder Standardauswahl erfinden.
Für Type of Subject Alternative Name und Value of Subject Alternative Name den dokumentierten Typ und Wert getrennt abgleichen: RFC 822 name für eine gültige E-Mail-Adresse, DNS name für den DNS-Namen des CA-Servers oder Uniform resource identifier für dessen vollständige URL. AD user logon name bleibt der AD-UPN des Benutzers. Die Feldbeschreibung ersetzt nicht den Identitätsabgleich am tatsächlich ausgestellten Zertifikat.
Erstausstellung nach Policy-Zustellung: Am Pilotgerät Issuer/Kette, Subject und SAN/UPN, Seriennummer, Gültigkeitsbeginn/-ende und Schlüsselverwendung mit den genehmigten PKI-Vorgaben abgleichen. Eine AD-Geräteregistrierung zählt nicht als SCEP-Clientzertifikatsausstellung. Ohne beobachtete Ausstellung: Stopp, keine Rotation freigeben.
Spätere Erneuerung: PKI und MDM legen aus Intervall und Zertifikatsgültigkeit einen Beobachtungszeitraum fest. Darin am Gerät ein neues gültiges Zertifikat mit neuer Seriennummer und passenden Identitäts-/Issuer-Werten sowie den bestätigten PKI-Vorgang prüfen. Nicht beobachtbar oder im Pilotzeitraum nicht eingetreten: Rotation nicht als validiert freigeben.
Nur bei belegter WLAN-/VPN-Zuordnung im Pilot: Im Log des verwendenden Dienstes die erfolgreiche Authentifizierung vor und nach der Erneuerung genau diesem Pilotgerät und Zertifikat zuordnen. Ohne Dienst-Log oder bestätigte Zuordnung: kein WLAN-/VPN-Wechsel.

Rotation und Rückweg

Vor einem Wechsel von SCEP-URL, Challenge-Zugang oder CA sowie einem gesondert belegten WLAN-/VPN-Profilwechsel je Geräteklasse alte und neue Policy-Zuweisung, Trust-Anker und betroffene Gruppen im Pilotprotokoll festhalten. PKI, Netzwerk und MDM legen den tatsächlich erreichbaren, vom zu wechselnden Zertifikatsnetz unabhängigen Managementpfad, den zuständigen lokalen Recovery-Verantwortlichen und das Stop-Kriterium fest. Die konkrete Methode zum erneuten Zuweisen oder Entfernen einer Policy und ihre Wirkung auf die Geräte müssen für Plattform und Enrollment-Modus im Pilot validiert sein; hier wird kein universeller Rücksetzweg behauptet. Laut Sophos ist Uninstall policy nur für Android-Geräte-, Knox-Container- und iOS-Gerätepolicies vorgesehen; bei anderen Typen, darunter Android-Enterprise-Gerätepolicies, stattdessen die Policy aktualisieren oder eine andere zuweisen. Ob das eine bereits installierte CA oder ein Clientzertifikat entfernt beziehungsweise wiederherstellt, ist damit nicht nachgewiesen.

Entscheidung vor Rollout: Neue Vertrauenskette nur dann zuerst im Pilot bereitstellen, wenn der konkrete Modus die parallele Verteilung unterstützt. Neue Ausstellung und echte spätere Erneuerung prüfen. Bei geplantem WLAN-/VPN-Wechsel zusätzlich belegte Profil-Zuordnung und Dienst-Authentifizierung vor und nach Erneuerung prüfen. Erst nach kontrollierter Abnahme und geplantem Rollout alte Profile/Trust-Anker entfernen. Die alte CA nicht vorzeitig entziehen, wenn sie noch für bestehende Verbindungen gebraucht wird.

Bei Fehlschlag nach Erreichbarkeit entscheiden:

Alle weiteren Zuweisungen und Entziehungen stoppen. Bisherige CA, Profile und Trust-Anker erhalten; PKI-, Netzwerk- und MDM-Verantwortliche anhand des Pilotprotokolls einbeziehen.
Gerät über den geprüften unabhängigen Pfad erreichbar: Das MDM-Team stellt mit der zuvor für diesen Modus validierten Zuweisungs-/Entfernungsmethode die dokumentierte bisherige Policy-/Netz-/CA-Zuordnung wieder her; PKI und Netzwerk prüfen ihren Teil. Bei geändertem WLAN/VPN die Authentifizierung erneut im Dienst-Log testen.
Gerät offline oder ohne unabhängigen Pfad: Der vorher benannte lokale Recovery-Verantwortliche nutzt ausschliesslich den vorher geplanten und getesteten lokalen Wiederherstellungsweg; danach Erreichbarkeit und, falls betroffen, die Dienst-Authentifizierung nachtesten. Das blosse Rücksetzen einer Cloud-Einstellung ist kein nachgewiesener Rollback für offline gewordene Geräte. Ist der lokale Weg nicht nachgewiesen, keine sichere Fernwiederherstellung behaupten oder den Wechsel ausweiten.

Ohne beobachtete Erstausstellung, Erneuerung und geprüften Rückweg bleibt der produktive SCEP-Wechsel gesperrt; ein WLAN-/VPN-Wechsel erfordert zusätzlich belegte Zertifikatszuordnung und erfolgreiche Nutzung vor und nach Erneuerung.

Nachweisgrenze: Dies ist ein quellenbasierter, nicht im Tenant oder auf Geräten getesteter Entwurf. Unterstützte OS-/Serverversionen, Client-Verhalten bei Offline-Erneuerung und konkreter EAP-/VPN-Identitätsabgleich müssen in der eigenen Umgebung separat bestätigt werden.