PKI-Grundlagen für WiFi-Administratoren: Zertifikate, CAs und Vertrauensketten

Dieses technische Referenzhandbuch erklärt die grundlegenden Konzepte der Public-Key-Infrastruktur (PKI) für WiFi-Administratoren in Unternehmen und deckt Zertifizierungsstellen, Vertrauensketten sowie X.509-Zertifikate ab. Es beschreibt im Detail, wie PKI die gegenseitige EAP-TLS-Authentifizierung unterstützt, und bietet praktische Bereitstellungsrichtlinien für IT-Teams in den Bereichen Hotellerie, Einzelhandel und im öffentlichen Sektor. Das Verständnis von PKI ist eine zwingende Voraussetzung für die Bereitstellung der zertifikatsbasierten Mitarbeiter-WiFi-Authentifizierung mit Purple.

📖 8 Min. Lesezeit📝 1,896 Wörter🔧 2 ausgearbeitete Beispiele❓ 4 Übungsfragen📚 10 Schlüsseldefinitionen

Diesen Leitfaden anhören

Podcast-Transkript ansehen

[Einführung & Kontext — 1 Minute]

Willkommen zum technischen Briefing von Purple. Ich bin Ihr Gastgeber, und heute befassen wir uns mit einem grundlegenden Thema für jeden Architekten von Unternehmensnetzwerken: PKI-Grundlagen für WiFi-Administratoren. Wir betrachten ganz speziell Zertifikate, Zertifizierungsstellen und Vertrauensketten.

Wenn Sie IT-Manager, CTO oder Venue Operations Director in einem Hotel, einer Einzelhandelskette oder einem großen öffentlichen Veranstaltungsort sind, wissen Sie, dass es bei der Netzwerksicherheit nicht mehr nur um einen komplexen Pre-Shared Key geht. Um Mitarbeiter- und Unternehmensgeräte wirklich zu schützen, benötigen Sie eine zertifikatsbasierte Authentifizierung — insbesondere EAP-TLS. Aber um EAP-TLS oder sogar WPA3-Enterprise bereitzustellen, müssen Sie zunächst die zugrunde liegende Public-Key-Infrastruktur oder PKI verstehen.

Heute lassen wir die akademische Theorie beiseite. Wir schauen uns genau an, wie PKI in der Praxis der WiFi-Bereitstellung funktioniert, warum Sie sie benötigen und wie sie die von uns bei Purple entwickelten Lösungen für sicheren Zugang unterstützt.

[Technischer Deep-Dive — 5 Minuten]

Lassen wir uns tiefer in die Architektur eintauchen. Im Kern ist eine PKI ein Framework, das Kryptografie nutzt, um die Identität von Geräten und Servern in Ihrem Netzwerk zu überprüfen. Stellen Sie sich das wie ein digitales Passsystem vor.

Wenn ein Gerät versucht, eine Verbindung zu Ihrem Unternehmens-WiFi herzustellen, woher weiß das Netzwerk, dass es sich um einen legitimen Firmen-Laptop und nicht um ein fremdes Gerät handelt? Und umgekehrt, woher weiß der Laptop, dass er sich mit Ihrem tatsächlichen RADIUS-Server verbindet und nicht mit dem Honeypot eines Angreifers? Hier kommen X.509-Zertifikate ins Spiel.

Das gesamte System basiert auf einem Konzept namens Vertrauenskette (Trust Chain). An der Spitze dieser Kette steht die Root Certificate Authority, oder Root CA. Die Root CA ist die ultimative Quelle der Wahrheit. In einer ordnungsgemäßen Unternehmensumgebung wird diese Root CA aus Sicherheitsgründen oft offline und physisch isoliert (air-gapped) aufbewahrt. Ihre einzige Aufgabe besteht darin, die Zertifikate der darunter liegenden Ebene zu signieren.

Diese nächste Ebene ist die Intermediate CA. Die Intermediate CA ist online und übernimmt die eigentliche tägliche Arbeit der Ausstellung von Zertifikaten an Server und Client-Geräte. Indem Sie die Root CA offline halten und eine Intermediate CA verwenden, minimieren Sie ein massives Risiko. Wenn die Intermediate CA kompromittiert wird, können Sie sie widerrufen und mithilfe Ihrer sicheren Root CA eine neue erstellen.

Am Ende der Kette stehen die Leaf-Zertifikate. Dies sind die eigentlichen Zertifikate, die auf Ihrem RADIUS-Server installiert sind — das Server-Zertifikat — und auf den Geräten Ihrer Endbenutzer — die Client-Zertifikate.

Wie genau läuft das nun in der Praxis während einer EAP-TLS-Authentifizierung ab? Es handelt sich um einen Prozess der gegenseitigen Authentifizierung (Mutual Authentication). Wenn ein Gerät versucht, eine Verbindung zum WiFi Access Point — dem Authenticator — herzustellen, kommuniziert es mit dem RADIUS-Server. Der RADIUS-Server präsentiert sein Server-Zertifikat dem Gerät. Das Gerät gleicht dieses Zertifikat mit seinen vertrauenswürdigen Root CAs ab. Wenn die Validierung erfolgreich ist, weiß das Gerät, dass das Netzwerk legitim ist.

Dann präsentiert das Gerät sein eigenes Client-Zertifikat gegenüber dem RADIUS-Server. Der Server validiert das Zertifikat des Clients. Sobald beide Seiten die digitalen Pässe des jeweils anderen über die Vertrauenskette (Trust Chain) verifiziert haben, wird der TLS-Handshake abgeschlossen und der Zugriff gewährt. Keine Passwörter, die gestohlen werden können, keine gemeinsamen Schlüssel, die erraten werden können. Einfach nur kryptografisch sichere, gegenseitige Authentifizierung.

Lassen Sie uns nun darüber sprechen, wie sich dies auf den IEEE 802.1X-Standard übertragen lässt. EAP-TLS ist innerhalb von 802.1X definiert, dem portbasierten Framework für die Netzwerkzugriffskontrolle. In einer 802.1X-Bereitstellung gibt es drei Rollen. Erstens den Supplicant (Antragsteller) – das ist das Client-Gerät, das versucht, auf das Netzwerk zuzugreifen. Zweitens den Authenticator (Authentifizierer) – das ist Ihr WiFi-Zugangspunkt (Access Point) oder Netzwerk-Switch. Drittens den Authentication Server (Authentifizierungsserver) – das ist Ihr RADIUS-Server. Der Access Point fungiert als Gatekeeper und leitet Authentifizierungsnachrichten zwischen dem Client und dem RADIUS-Server weiter, ohne die tatsächlichen Anmeldeinformationen jemals zu sehen. Diese Architektur ist grundlegend, um zu verstehen, warum PKI in einem WiFi-Kontext so leistungsfähig ist.

Betrachten wir auch das X.509-Zertifikatsformat selbst. Jedes Zertifikat enthält mehrere kritische Felder. Den Subject (Betreff), der angibt, wem das Zertifikat gehört. Den Issuer (Aussteller), der die CA identifiziert, die es signiert hat. Den Public Key (öffentlichen Schlüssel), der der dem Betreff zugeordnete kryptografische Schlüssel ist. Den Validity Period (Gültigkeitszeitraum), der das Start- und Enddatum definiert. Und die Signature (Signatur), die das kryptografische Gütesiegel der CA ist. Wenn ein RADIUS-Server oder ein Client-Gerät ein Zertifikat validiert, überprüft es all diese Felder, einschließlich der Frage, ob das Zertifikat widerrufen wurde.

[Empfehlungen zur Implementierung & Fallstricke — 2 Minuten]

Bei der Planung dieser Bereitstellung ist eine der wichtigsten Entscheidungen, ob Sie eine öffentliche CA (Public CA) oder eine private CA (Private CA) verwenden.

Für Ihren RADIUS-Server können Sie eine Public CA nutzen – wie DigiCert oder Let's Encrypt. Der Vorteil hierbei ist, dass die meisten Client-Geräte diesen öffentlichen Root-Zertifikaten bereits standardmäßig vertrauen. Für die Ausstellung von Client-Zertifikaten an Tausende von Unternehmensgeräten benötigen Sie jedoch zwingend eine Private CA. Sie möchten schließlich nicht für jeden Mitarbeiter-Laptop und jeden Scanner an einen öffentlichen Anbieter zahlen, und Sie benötigen die vollständige Kontrolle über den Lebenszyklus von Ausstellung und Widerruf.

Ein häufiger Fallstrick, den wir bei großen Implementierungen im Gastgewerbe oder im Einzelhandel sehen, ist die mangelnde Planung für den Zertifikatswiderruf. Was passiert, wenn ein Mitarbeiter-Laptop gestohlen wird? Sie müssen eine robuste Certificate Revocation List (Zertifikatssperrliste) oder CRL vorhalten oder das Online Certificate Status Protocol (OCSP) nutzen, damit Ihr RADIUS-Server weiß, dass er dieses spezifische Zertifikat sofort ablehnen muss.

Ein weiteres wichtiges Implementierungsdetail: Lassen Sie Ihre Zertifikate nicht unbemerkt ablaufen. Ich habe schon erlebt, dass ganze Krankenhausflügel den WiFi-Zugang verloren haben, weil ein einziges Serverzertifikat abgelaufen war, wodurch die Vertrauenskette unterbrochen wurde. Richten Sie eine automatisierte Überwachung und Alarmierung weit vor dem Ablaufdatum ein. Eine gute Faustregel ist es, 90 Tage, 60 Tage und 30 Tage vor dem Ablauf zu warnen und die Verlängerung bei 60 Tagen zu automatisieren.

[Schnelle Fragerunde (Q&A) — 1 Minute]

Beantworten wir ein paar häufige Fragen, die uns von Netzwerkteams gestellt werden.

Frage eins: Können wir nicht einfach eine MAC-Adressfilterung anstelle von PKI verwenden?

Auf keinen Blick. MAC-Adressen lassen sich mit frei verfügbaren Tools kinderleicht fälschen. Die MAC-Filterung bietet keinerlei kryptografische Sicherheit und scheitert an grundlegenden Compliance-Audits wie PCI DSS. EAP-TLS mit PKI ist der Goldstandard, und das aus gutem Grund.

Frage zwei: Gilt das auch für das Gäste-WiFi?

Im Allgemeinen nein. PKI und EAP-TLS sind für den sicheren, internen Unternehmenszugriff gedacht – also für Mitarbeitergeräte, Point-of-Sale-Terminals und Firmen-Laptops. Für den Gästezugang ist eine nahtlose Captive Portal-Lösung gefragt, und genau hier glänzt die Guest WiFi-Plattform von Purple. Der Versuch, Zertifikate auf nicht verwalteten Gäste-Geräten zu installieren, ist betrieblich unpraktisch und führt zu einer schlechten User Experience.

Frage drei: Wie bekommen wir die Zertifikate auf die Geräte?

Sie benötigen eine Mobile Device Management- bzw. MDM-Lösung wie Microsoft Intune oder Jamf. Sie verteilen die Root CA, die Intermediate CA und die einzelnen Client-Zertifikate automatisch per Richtlinie auf die Geräte. Versuchen Sie nicht, diese manuell zu installieren – das ist schlichtweg nicht skalierbar.

[Zusammenfassung & Nächste Schritte — 1 Minute]

Zusammenfassend lässt sich sagen: PKI ist die grundlegende Vertrauensebene für sicheres Enterprise-WiFi. Sie benötigen eine klare Hierarchie mit einer Root CA, einer Intermediate CA und Leaf-Zertifikaten. EAP-TLS nutzt diese Hierarchie für eine gegenseitige Authentifizierung und eliminiert so die Risiken, die mit Passwörtern und gemeinsam genutzten Schlüsseln verbunden sind.

Für IT-Leiter ist das Verständnis dieser Architektur die Voraussetzung für die Bereitstellung eines robusten, konformen Netzwerkzugangs. Unabhängig davon, ob Sie Point-of-Sale-Systeme im Einzelhandel, Mitarbeiternetzwerke im Gastgewerbe oder klinische Geräte im Gesundheitswesen absichern – eine PKI ist unverzichtbar.

Die wichtigsten Erkenntnisse aus dem heutigen Briefing sind folgende: Erstens, nutzen Sie eine Public CA für Ihr RADIUS-Serverzertifikat und eine Private CA für Client-Geräte. Zweitens, halten Sie Ihre Root CA immer offline und physisch vom Netzwerk getrennt (air-gapped). Drittens, stellen Sie Zertifikate über ein MDM bereit – niemals manuell. Viertens, implementieren Sie OCSP für eine Echtzeit-Sperrprüfung. Und fünftens, automatisieren Sie die Zertifikatsverlängerung, um Ausfälle zu vermeiden.

Vielen Dank, dass Sie an diesem technischen Briefing teilgenommen haben. Für detailliertere Bereitstellungshandbücher und um zu sehen, wie Purple sich in Ihre sichere Netzwerkarchitektur integrieren lässt, besuchen Sie purple.ai.

Wichtigste Erkenntnisse

✓PKI ist das kryptografische Vertrauensmodell, das vorhanden sein muss, bevor eine zertifikatsbasierte WiFi-Authentifizierung mit EAP-TLS oder WPA3-Enterprise implementiert wird.
✓Die Vertrauenskette besteht aus drei Ebenen: einer Offline-Root-CA (der Vertrauensanker), einer Online-Intermediate-CA (der operative Aussteller) und Leaf-Zertifikaten, die auf Servern und Client-Geräten installiert sind.
✓EAP-TLS bietet eine gegenseitige Authentifizierung — der Client überprüft das Netzwerk und das Netzwerk überprüft den Client — wodurch die passwortbasierte Angriffsfläche vollständig eliminiert wird.
✓Nutzen Sie eine Public CA für Ihr RADIUS-Serverzertifikat (für eine breite Gerätekompatibilität) und eine Private CA für Client-Zertifikate (für Kostenkontrolle und Lifecycle-Management im großen Stil).
✓Halten Sie die Root-CA immer offline und physisch vom Netzwerk getrennt (Air-Gap); wird diese kompromittiert, muss die gesamte PKI-Infrastruktur von Grund auf neu aufgebaut werden.
✓Implementieren Sie OCSP für die Echtzeit-Überprüfung von Zertifikatswiderrufen — CRL-basierte Widerrufe führen in Hochsicherheitsumgebungen zu inakzeptablen Verzögerungen.
✓Automatisieren Sie das Zertifikats-Lifecycle-Management über MDM- und Monitoring-Tools; abgelaufene Zertifikate sind die Hauptursache für Netzwerkausfälle bei EAP-TLS.

Executive Summary

Für IT-Manager, Netzwerkarchitekten und Betriebsleiter von Veranstaltungsorten ist die Absicherung von Unternehmens- und Mitarbeiter-WiFi-Netzwerken eine kritische Compliance- und Betriebsanforderung. Veraltete Authentifizierungsmethoden wie Pre-Shared Keys (PSKs) oder MAC-Adressen-Filterung reichen für moderne Unternehmensumgebungen nicht mehr aus und machen Netzwerke anfällig für Zugangsdaten-Diebstahl und Geräte-Spoofing. Um eine robuste, auditierbare Sicherheit zu gewährleisten, müssen Unternehmen auf zertifikatsbasierte Authentifizierung umsteigen – insbesondere auf EAP-TLS (Extensible Authentication Protocol-Transport Layer Security).

Die Bereitstellung von EAP-TLS erfordert ein solides Verständnis der Public Key Infrastructure (PKI). Dieser Leitfaden entmystifiziert PKI für WiFi-Administratoren und erklärt die Rollen von Zertifizierungsstellen (Certificate Authorities, CAs), die Funktionsweise der Vertrauenskette (Trust Chain) und die praktischen Unterschiede zwischen Server- und Client-Zertifikaten. Durch das Beherrschen dieser Grundlagen können IT-Teams sichere, skalierbare Netzwerkzugangslösungen für Hospitality , Retail und Veranstaltungsorte des öffentlichen Sektors selbstbewusst entwerfen und implementieren. Dies stellt die Einhaltung von Standards wie PCI DSS und GDPR sicher und bietet gleichzeitig eine nahtlose, passwortfreie Konnektivität für verwaltete Geräte. Das Verständnis von PKI ist zudem die grundlegende Voraussetzung für die Bereitstellung der zertifikatsbasierten WiFi-Mitarbeiterauthentifizierung mit Purple.

Technischer Deep-Dive

Die Architektur des Vertrauens: Was ist eine Public Key Infrastructure?

Die Public Key Infrastructure (PKI) ist ein kryptografisches Framework, das sichere Kommunikation und gegenseitige Authentifizierung über ein nicht vertrauenswürdiges Netzwerk ermöglicht. Im Kontext von Enterprise-WiFi fungiert die PKI als digitales Passsystem, das die Identität sowohl des Client-Geräts (des Supplicants) als auch des Netzwerk-Authentifizierungsservers (des RADIUS-Servers) verifiziert, bevor Daten ausgetauscht werden.

Dieses System stützt sich auf X.509-Zertifikate, die einen öffentlichen Schlüssel an eine verifizierte Identität binden – wie einen Server-Hostnamen oder die E-Mail-Adresse eines Benutzers – und von einer vertrauenswürdigen dritten Partei, der Certificate Authority (CA), digital signiert sind. Die Signatur der CA ist die kryptografische Garantie dafür, dass der Identitätsanspruch legitim ist.

Die Zertifikatshierarchie und Vertrauenskette (Trust Chain)

Die Stärke einer PKI liegt in ihrer hierarchischen Struktur, der sogenannten Vertrauenskette (Trust Chain). Diese Hierarchie stellt sicher, dass jedes von einem Gerät oder Server präsentierte Zertifikat kryptografisch auf eine universell vertrauenswürdige Quelle zurückgeführt werden kann. Die drei Ebenen sind wie folgt aufgebaut.

Root Certificate Authority (Root CA): Die Root CA ist der kryptografische Anker des gesamten PKI-Ökosystems. Sie stellt ein selbstsigniertes Zertifikat aus und genießt von Client-Geräten und Servern standardmäßig absolutes Vertrauen. In einer sicheren Unternehmensumgebung wird die Root CA offline und in einem Air-Gap-System betrieben, um ihren privaten Schlüssel vor netzwerkbasierten Angriffen zu schützen. Ihr einziger operativer Zweck besteht darin, die Zertifikate von Intermediate CAs zu signieren.

Intermediate Certificate Authority (Intermediate CA): Die Intermediate CA fungiert als Puffer zwischen der hochsicheren Root CA und der Betriebsumgebung. Sie ist online und wickelt die tägliche Ausstellung und den Widerruf von Leaf-Zertifikaten ab. Diese Trennung ist eine entscheidende Strategie zur Risikominderung: Wenn eine Intermediate CA kompromittiert wird, kann sie von der Root CA widerrufen werden, ohne dass die gesamte PKI-Infrastruktur ungültig wird oder jedes einzelne Client-Gerät neu konfiguriert werden muss.

Leaf Certificates (End-Entity Certificates): Dies sind die Zertifikate, die auf einzelnen Servern und Client-Geräten installiert sind. Sie befinden sich am Ende der Vertrauenskette und können selbst keine anderen Zertifikate signieren. Für die Bereitstellung von WiFi sind zwei Haupttypen relevant. Das Server-Zertifikat wird auf dem RADIUS-Server installiert, sodass Client-Geräte überprüfen können, ob sie sich mit dem legitimen Unternehmensnetzwerk verbinden. Das Client-Zertifikat wird auf den Laptops der Mitarbeiter, mobilen Geräten oder Point-of-Sale-Terminals installiert, sodass der RADIUS-Server die Identität jedes einzelnen Geräts oder Benutzers überprüfen kann.

Wie PKI die EAP-TLS-Authentifizierung unterstützt

EAP-TLS ist der Goldstandard für die sichere WiFi-Authentifizierung, da es eine gegenseitige zertifikatsbasierte Authentifizierung vorschreibt. Dies bedeutet, dass sowohl das Client-Gerät als auch der RADIUS-Server ihre Identität mithilfe von Zertifikaten nachweisen müssen, die anhand der PKI-Vertrauenskette validiert wurden – wodurch die mit passwortbasierten Ansätzen verbundenen Risiken eliminiert werden.

Während des EAP-TLS-Handshakes, der innerhalb des IEEE 802.1X-Frameworks abläuft, präsentiert der RADIUS-Server dem Client-Gerät zunächst sein Server-Zertifikat. Das Gerät validiert die Signatur des Zertifikats anhand seines Speichers für vertrauenswürdige Root CAs. Ist diese gültig, verfügt das Gerät über den kryptografischen Beweis, dass es sich mit dem legitimen Unternehmensnetzwerk verbindet – und nicht mit einem gefälschten Access Point oder Evil Twin. Das Client-Gerät präsentiert dann sein eigenes Client-Zertifikat dem RADIUS-Server, der es mit der CA validiert. Sobald beide Parteien authentifiziert sind, wird ein sicherer TLS-Tunnel aufgebaut und der Netzwerkzugriff gewährt. Es werden keine Passwörter übertragen und es existieren keine gemeinsamen Geheimnisse, die gestohlen werden könnten.

Diese Architektur ist auch das Fundament von WPA3-Enterprise, das den 192-Bit-Sicherheitsmodus vorschreibt und auf denselben PKI- und 802.1X-Grundlagen basiert. Für Organisationen, die Wireless Access Points in Hochsicherheitsumgebungen bereitstellen, stellt WPA3-Enterprise mit EAP-TLS die derzeitige Best Practice dar.

Öffentliche CA vs. Private CA: Die Bereitstellungsentscheidung

Eine der weitreichendsten architektonischen Entscheidungen bei einer PKI-Bereitstellung ist die Wahl zwischen einer öffentlichen CA und einer privaten CA. Die folgende Tabelle fasst die Vor- und Nachteile zusammen.

Kriterium	Öffentliche CA	Private CA
Kosten	Gebühr pro Zertifikat (sinnvoll für eine geringe Anzahl von Servern)	Infrastrukturkosten, aber keine Gebühr pro Zertifikat bei Skalierung
Geräte-Vertrauen	Standardmäßig auf den meisten Betriebssystemen und Geräten vertrauenswürdig	Erfordert die Verteilung der Root-CA auf alle Geräte via MDM
Kontrolle	Eingeschränkt; CA kontrolliert die Ausstellungsrichtlinien	Volle Kontrolle über Ausstellung, Sperrung und Lebenszyklus
Bester Anwendungsfall	RADIUS-Server-Zertifikat	Client-Zertifikate für verwaltete Unternehmensgeräte
Compliance	Überprüfbar durch öffentliche CT-Protokolle	Erfordert interne Audit-Prozesse

Der empfohlene Ansatz für die meisten Enterprise WiFi-Bereitstellungen ist ein Hybrid-Modell: Verwenden Sie eine öffentliche CA für das RADIUS-Server-Zertifikat, um eine breite Kompatibilität zu gewährleisten, und implementieren Sie eine private CA (wie Microsoft Active Directory Certificate Services oder einen cloudbasierten PKI-Anbieter) für die skalierte Ausstellung von Client-Zertifikaten an verwaltete Geräte.

Implementierungsleitfaden

Schritt 1: Design der CA-Architektur

Beginnen Sie mit der Erfassung Ihrer Zertifikatsanforderungen. Ermitteln Sie die Anzahl der verwalteten Geräte, die verwendeten Betriebssysteme und die verfügbare MDM-Plattform. Bestimmen Sie, ob eine zweistufige (Root-CA + Intermediate-CA) oder dreistufige Hierarchie für die Größe und das Risikoprofil Ihres Unternehmens angemessen ist.

Schritt 2: Bereitstellung und Absicherung der Root- und Intermediate-CAs

Richten Sie die Offline-Root-CA auf einem dedizierten, vom Netzwerk getrennten (Air-Gapped) System ein. Verwenden Sie die Root-CA, um das Zertifikat der Intermediate-CA zu signieren. Stellen Sie sicher, dass die Intermediate-CA sicher in Ihrem Rechenzentrum oder Ihrer Cloud-Umgebung bereitgestellt und in Ihren Identity Provider (IdP) oder Ihre MDM-Lösung integriert ist. Speichern Sie den privaten Schlüssel der Root-CA in einem Hardware-Sicherheitsmodul (HSM), sofern das Budget dies zulässt.

Schritt 3: Konfiguration des RADIUS-Servers

Installieren Sie das Server-Zertifikat auf Ihrem RADIUS-Server. Konfigurieren Sie den Server so, dass er EAP-TLS für die sichere Unternehmens-SSID vorschreibt. Stellen Sie sicher, dass der RADIUS-Server der Intermediate-CA vertraut, die die Client-Zertifikate ausgestellt hat, und konfigurieren Sie ihn so, dass er eine Sperrprüfung via OCSP durchführt.

Schritt 4: Verteilung der Zertifikate via MDM

Versuchen Sie niemals eine manuelle Zertifikatsinstallation im großen Stil. Nutzen Sie eine MDM-Plattform wie Microsoft Intune oder Jamf, um das Root-CA-Zertifikat, das Intermediate-CA-Zertifikat und die individuellen Client-Zertifikate über automatisierte Richtlinien an alle verwalteten Geräte zu verteilen. Dies gewährleistet eine konsistente Bereitstellung und ermöglicht eine automatisierte Erneuerung.

Schritt 5: Implementierung und Test von Sperrmechanismen

Konfigurieren Sie Zertifikatssperrlisten (CRLs) oder das Online Certificate Status Protocol (OCSP). Testen Sie den Sperr-Workflow durchgängig, indem Sie ein Testzertifikat sperren und bestätigen, dass der RADIUS-Server den Zugriff innerhalb des erwarteten Zeitrahmens verweigert. Für Umgebungen, die eine nahezu sofortige Sperrung erfordern — wie POS-Netzwerke im Einzelhandel —, ist OCSP zwingend erforderlich.

Schritt 6: Lebenszyklus-Management überwachen und automatisieren

Implementieren Sie eine automatisierte Überwachung auf Ablauf von Zertifikaten über alle Ebenen der Hierarchie hinweg. Konfigurieren Sie Warnmeldungen 90, 60 und 30 Tage vor dem Ablauf. Automatisieren Sie die Verlängerung bei 60 Tagen. Dies ist der wirksamste operative Schritt, um Netzwerkausfälle zu verhindern.

Best Practices

Gegenseitige Authentifizierung ausnahmslos erzwingen: Stellen Sie sicher, dass Client-Geräte so konfiguriert sind, dass sie das Zertifikat des RADIUS-Servers streng validieren. Die Deaktivierung der Serverzertifikatsvalidierung — eine häufige Abkürzung bei der Erstbereitstellung — macht Geräte anfällig für Man-in-the-Middle-Angriffe sowie den Diebstahl von Zugangsdaten und verstößt gegen die PCI-DSS-Anforderungen.

Netzwerke nach Authentifizierungsmethode segmentieren: Verwenden Sie EAP-TLS für Unternehmens- und Mitarbeitergeräte auf einer dedizierten SSID. Für den öffentlichen Besucherzugang implementieren Sie eine robuste Captive Portal-Lösung wie Guest WiFi in einem vollständig isolierten Netzwerk. Versuchen Sie nicht, eine PKI auf nicht verwalteten Gastgeräten bereitzustellen.

Die PKI-Infrastruktur regelmäßig auditieren: Führen Sie vierteljährliche Audits der CA-Zugriffskontrollen, Sperrlisten und Zertifikatausstellungsprotokolle durch. Im Gesundheitswesen und im Einzelhandel ist dies eine Compliance-Anforderung gemäß HIPAA beziehungsweise PCI DSS.

Integration mit Netzwerkanalysen: Sobald eine sichere Authentifizierung eingerichtet ist, nutzen Sie zusätzlich WiFi Analytics , um Einblick in das Geräteverhalten, Verbindungsmuster und potenzielle Anomalien zu erhalten. Ein sicheres Netzwerk ist das Fundament für vertrauenswürdige Daten.

SD-WAN-Integration in Betracht ziehen: Bei Bereitstellungen an mehreren Standorten, wie bei Hotelketten oder Filialen im Einzelhandel, lässt sich eine PKI naturgemäß in SD-WAN-Architekturen integrieren. Hintergrundinformationen dazu, wie sich diese Technologien ergänzen, finden Sie unter The Core SD-WAN Benefits for Modern Businesses .

Fehlerbehebung & Risikominderung

Die folgende Tabelle ordnet häufige Fehlerszenarien ihren Ursachen und den empfohlenen Gegenmaßnahmen zu.

Symptom	Ursache	Gegenmaßnahme
Geräte können keine Verbindung herstellen; RADIUS-Protokolle zeigen 'Unknown CA'	Das Client-Gerät vertraut der CA nicht, die das RADIUS-Serverzertifikat ausgestellt hat	Verteilen Sie die Root-CA über ein MDM an alle Geräte
Plötzlicher netzwerkweiter Ausfall für alle Unternehmensgeräte	Das RADIUS-Serverzertifikat oder das Intermediate-CA-Zertifikat ist abgelaufen	Implementieren Sie eine automatisierte Überwachung und Verlängerung; Warnmeldungen bei 90/60/30 Tagen
Gestohlenes Notebook kann weiterhin auf das Netzwerk zugreifen	Die CRL ist veraltet oder OCSP ist nicht konfiguriert	Wechseln Sie zu OCSP für eine Sperrungsprüfung in Echtzeit
Sporadische Authentifizierungsfehler	Zeitabweichung (Clock Skew) zwischen Client und RADIUS-Server	Stellen Sie sicher, dass alle Geräte die NTP-Zeitsynchronisation verwenden

Für ein tieferes Verständnis der 802.1X-Konfiguration und -Fehlerbehebung bietet der Leitfaden 802.1X Authentication: Securing Network Access on Modern Devices eine detaillierte, herstellerneutrale Konfigurationsanleitung.

ROI & geschäftliche Auswirkungen

Der Übergang zu einer PKI-gestützten EAP-TLS-Architektur liefert Betreibern von Veranstaltungsorten messbaren geschäftlichen Nutzen in mehrfacher Hinsicht.

Risikominderung und Compliance: Die Eliminierung der passwortbasierten Authentifizierung beseitigt den häufigsten Angriffsvektor für Netzwerkkompromittierungen. Dies reduziert direkt die Wahrscheinlichkeit kostspieliger Datenpannen und vereinfacht die Einhaltung von PCI DSS (erforderlich für die Zahlungsabwicklung), GDPR (für den Datenschutz) und branchenspezifischen Vorschriften. Für Veranstaltungsorte, die IoT- Sensors oder standortbasierte Wayfinding -Systeme einsetzen, ist ein kryptografisch gesichertes Netzwerk eine Grundvoraussetzung für vertrauenswürdige Datenintegrität.

Operative Effizienz: Die Automatisierung der Zertifikatsverteilung über MDM eliminiert den Betriebsaufwand für die Passwortverwaltung und reduziert IT-Helpdesk-Tickets im Zusammenhang mit der WiFi-Konnektivität. In Umgebungen mit hoher Fluktuation, wie Hotellerie und Einzelhandel, in denen die Einarbeitung und der Austritt von Mitarbeitern häufig stattfinden, bietet die automatisierte Zertifikatsausstellung und -sperrung im Vergleich zur Verwaltung gemeinsam genutzter Anmeldedaten erhebliche Zeiteinsparungen.

Basis für fortschrittliche Services: Ein sicheres, authentifiziertes Unternehmensnetzwerk ist das vertrauenswürdige Fundament, auf dem fortschrittliche operative Services aufgebaut werden. Ob beim Einsatz von WiFi Analytics für Besucherstrom-Analysen, Sensors für Belegungsdaten in Echtzeit oder Wayfinding für große Veranstaltungsorte – jede dieser Funktionen profitiert von den Integritätsgarantien, die eine PKI bietet.

Speziell für Betreiber im Bereich Hospitality stellt die Kombination aus einem sicheren Mitarbeiternetzwerk und einem gut gestalteten Gästeportal – wie in Modern Hospitality WiFi Solutions Your Guests Deserve beschrieben – die vollständige Enterprise-WiFi-Architektur dar. Für Transport -Knotenpunkte und große öffentliche Veranstaltungsorte gelten dieselben Prinzipien im großen Maßstab.

Schlüsseldefinitionen

Public Key Infrastructure (PKI)

Ein Framework aus Rollen, Richtlinien, Hardware, Software und Verfahren, das zur Erstellung, Verwaltung, Verteilung, Nutzung, Speicherung und zum Widerruf digitaler Zertifikate sowie zur Verwaltung der Public-Key-Verschlüsselung benötigt wird.

Die grundlegende Architektur, die vorhanden sein muss, bevor ein IT-Team eine sichere, zertifikatsbasierte WiFi-Authentifizierung mittels EAP-TLS bereitstellen kann.

Certificate Authority (CA)

Eine vertrauenswürdige Stelle, die digitale Zertifikate ausstellt, die Identität des Zertifikatsinhabers überprüft und diese Identität mittels einer kryptografischen Signatur an einen öffentlichen Schlüssel bindet.

Die zentrale Instanz in Ihrem Netzwerk, die als „Source of Truth“ für alle Geräte- und Serveridentitäten dient. Ohne eine vertrauenswürdige CA ist keine zertifikatsbasierte Authentifizierung möglich.

X.509-Zertifikat

Das in RFC 5280 definierte Standardformat für Public-Key-Zertifikate. Es enthält die Identität des Inhabers, den öffentlichen Schlüssel, die Identität des Ausstellers, die Gültigkeitsdauer und die digitale Signatur der CA.

Der eigentliche digitale Reisepass, der auf einem Laptop oder Server installiert ist und dessen Identität beim EAP-TLS-Handshake nachweist.

EAP-TLS (Extensible Authentication Protocol-Transport Layer Security)

Eine 802.1X-Authentifizierungsmethode, die eine gegenseitige zertifikatsbasierte Authentifizierung zwischen dem Client-Gerät (Supplicant) und dem Authentifizierungsserver (RADIUS) erfordert. Definiert in RFC 5216.

Die sicherste Methode zur Authentifizierung von Unternehmensgeräten in einem WiFi-Netzwerk. Sie macht Passwörter überflüssig und bietet beiden Parteien einen kryptografischen Identitätsnachweis.

Vertrauenskette (Trust Chain)

Eine hierarchische Abfolge von Zertifikaten zur Authentifizierung einer Entität, beginnend mit dem Endnutzerzertifikat (Leaf Certificate) und aufsteigend über die Intermediate CA bis zur Root CA.

Der Mechanismus, mit dem ein Laptop die Echtheit des Zertifikats eines RADIUS-Servers überprüft. Jedes Glied in der Kette wird validiert, bis eine vertrauenswürdige Root CA erreicht ist.

Certificate Revocation List (CRL)

Eine regelmäßig veröffentlichte Liste digitaler Zertifikate, die von der ausstellenden CA vor ihrem geplanten Ablaufdatum widerrufen wurden und denen nicht mehr vertraut werden sollte.

Ein Mechanismus zur Sperrung des Zugangs für verlorene oder gestohlene Geräte. CRLs werden zwischengespeichert und zeitgesteuert aktualisiert, was bedeutet, dass der Widerruf unter Umständen nicht sofort wirksam wird – eine Einschränkung, die durch OCSP behoben wird.

Online Certificate Status Protocol (OCSP)

Ein Internetprotokoll (RFC 6960) zur Abfrage des Echtzeit-Sperrstatus eines digitalen X.509-Zertifikats beim OCSP-Responder der CA.

Der bevorzugte Sperrmechanismus für Hochsicherheitsumgebungen. Er ermöglicht es dem RADIUS-Server, die Gültigkeit von Zertifikaten bei jedem Authentifizierungsversuch in Echtzeit zu überprüfen, was eine nahezu sofortige Durchsetzung von Sperren ermöglicht.

RADIUS (Remote Authentication Dial-In User Service)

Ein Netzwerkprotokoll, das eine zentrale AAA-Verwaltung (Authentication, Authorisation, and Accounting) für Benutzer und Geräte bietet, die sich mit einem Netzwerk verbinden.

Der zentrale Server in einer WiFi-Bereitstellung für Unternehmen, der Zertifikate validiert und die endgültige Entscheidung über die Zugangskontrolle trifft. Der RADIUS-Server ist das operative Herzstück einer EAP-TLS-Bereitstellung.

IEEE 802.1X

Ein IEEE-Standard für die portbasierte Netzwerkzugangskontrolle (PNAC), der einen Authentifizierungsmechanismus für Geräte bereitstellt, die eine Verbindung zu einem LAN oder WLAN herstellen möchten.

Der übergeordnete Rahmen, in dem EAP-TLS operiert. Das Verständnis von 802.1X ist unerlässlich, um Access Points und Switches so zu konfigurieren, dass sie eine zertifikatsbasierte Authentifizierung erzwingen.

Mobile Device Management (MDM)

Eine Softwareplattform, die von IT-Administratoren genutzt wird, um mobile Geräte und Laptops im gesamten Unternehmen aus der Ferne zu verwalten, zu konfigurieren und zu sichern.

Das unverzichtbare operative Werkzeug für die skalierbare Bereitstellung von Zertifikaten. MDM-Plattformen wie Microsoft Intune und Jamf automatisieren die Verteilung von Root-CA-Zertifikaten, Intermediate-CA-Zertifikaten und Client-Zertifikaten an alle verwalteten Geräte.

Ausgearbeitete Beispiele

Ein Luxushotel mit 500 Zimmern in London muss sein Mitarbeiter-WiFi-Netzwerk für Housekeeping-Tablets und Point-of-Sale (POS)-Terminals absichern. Derzeit wird ein einziger Pre-Shared Key (PSK) verwendet, der seit drei Jahren nicht mehr geändert wurde und allen festangestellten Mitarbeitern sowie Agenturkräften bekannt ist. Der IT-Leiter wurde beauftragt, vor dem nächsten PCI-DSS-Audit auf eine zertifikatsbasierte Architektur umzustellen. Wie sollte dies angegangen werden?

Phase 1 — Architektur-Design: Bereitstellung einer cloudbasierten Private PKI (z. B. Microsoft NDES über Intune oder ein dedizierter Cloud-PKI-Anbieter), die in die MDM-Plattform des Hotels integriert ist. Beziehen Sie ein RADIUS-Server-Zertifikat von einer Public CA wie DigiCert.

Phase 2 — Infrastruktur-Bereitstellung: Konfigurieren Sie den RADIUS-Server mit dem neuen Server-Zertifikat und aktivieren Sie EAP-TLS auf einer neuen, versteckten SSID, die für Mitarbeitergeräte vorgesehen ist. Konfigurieren Sie OCSP für die Echtzeit-Sperrprüfung.

Phase 3 — Geräte-Registrierung: Nutzen Sie die MDM-Plattform, um die Private Root CA, die Intermediate CA und eindeutige Client-Zertifikate auf alle Housekeeping-Tablets und POS-Terminals zu übertragen. Überprüfen Sie die erfolgreiche Zertifikatsinstallation bei einer Pilotgruppe von 20 Geräten vor dem vollständigen Rollout.

Phase 4 — Migration und Außerbetriebnahme: Migrieren Sie alle Geräte über die MDM-Richtlinie auf die neue EAP-TLS-SSID. Bestätigen Sie die Konnektivität auf allen Gerätetypen. Nehmen Sie das alte PSK-Netzwerk nach einer zweiwöchigen parallelen Betriebsphase außer Betrieb.

Phase 5 — Operative Übergabe: Dokumentieren Sie den Zertifikatslebenszyklus, die Sperrverfahren und die MDM-Richtlinien. Konfigurieren Sie automatisierte Ablaufwarnungen und planen Sie vierteljährliche PKI-Audits.

Kommentar des Prüfers: Dieser phasenweise Ansatz behebt die unmittelbare PCI-DSS-Compliance-Lücke durch die Eliminierung des gemeinsam genutzten PSK. Die Verwendung einer Private CA für Client-Geräte vermeidet gerätespezifische Zertifikatskosten in großem Maßstab – entscheidend in einer Hospitality-Umgebung mit hohen Gerätezahlen und hoher Mitarbeiterfluktuation. Die Verwendung einer Public CA für den RADIUS-Server stellt die Kompatibilität sicher, falls später BYOD eingeführt wird. Die parallele Betriebsphase ist unerlässlich, um Betriebsunterbrechungen im laufenden Hotelbetrieb zu vermeiden. Weitere Informationen zur Hospitality-WiFi-Architektur finden Sie im Leitfaden für moderne Hospitality-WiFi-Lösungen.

Eine nationale Einzelhandelskette führt EAP-TLS in 200 Filialen ein. Während der Pilotphase in fünf Filialen stellt das IT-Team fest, dass ein als gestohlen gemeldetes Laptop eines Filialleiters, dessen Zertifikat im PKI-System gesperrt wurde, sich noch bis zu 18 Stunden nach der Sperrung erfolgreich am Unternehmens-WiFi authentifizieren kann. Das Sicherheitsteam sieht darin ein unakzeptables Risiko, da das Gerät Zugriff auf Bestandsverwaltungssysteme haben könnte. Wie sollte dies gelöst werden?

Die Verzögerung von 18 Stunden wird dadurch verursacht, dass der RADIUS-Server auf einer gecachten, selten heruntergeladenen Certificate Revocation List (CRL) basiert. CRLs werden in der Regel nach einem festen Zeitplan (z. B. alle 24 Stunden) veröffentlicht und vom RADIUS-Server zwischengespeichert, sodass sich Sperrungen nicht in Echtzeit widerspiegeln.

Die Lösung besteht darin, den RADIUS-Server so zu konfigurieren, dass er das Online Certificate Status Protocol (OCSP) als primären Mechanismus zur Sperrprüfung verwendet. OCSP ermöglicht es dem RADIUS-Server, den OCSP-Responder der CA bei jedem EAP-TLS-Handshake in Echtzeit abzufragen und eine sofortige Rückmeldung wie 'gut', 'gesperrt' oder 'unbekannt' für das spezifische vorgelegte Zertifikat zu erhalten.

Konfigurationsschritte: (1) Stellen Sie sicher, dass die Private CA mit einem OCSP-Responder-Endpunkt konfiguriert ist. (2) Aktualisieren Sie die Konfiguration des RADIUS-Servers so, dass der OCSP-Endpunkt bei jedem Authentifizierungsversuch abgefragt wird. (3) Konfigurieren Sie, sofern unterstützt, OCSP Stapling, um Latenzen zu reduzieren. (4) Testen Sie die Konfiguration, indem Sie ein Zertifikat sperren und bestätigen, dass der RADIUS-Server den Zugriff innerhalb von 60 Sekunden verweigert.

Kommentar des Prüfers: Dieses Szenario verdeutlicht eine kritische operative Lücke, die bei ersten PKI-Bereitstellungen häufig auftritt. Das Ausstellen von Zertifikaten ist nur die halbe Miete – eine rechtzeitige Sperrung ist ebenso wichtig. In einer Einzelhandelsumgebung, in der Geräte Zugriff auf sensible Bestandsdaten oder Zahlungssysteme haben können, ist die Echtzeit-Sperrung via OCSP eine zwingende Kontrollmaßnahme. Der CRL-Ansatz ist für Umgebungen mit geringerem Risiko akzeptabel, in denen ein Sperrfenster von 18 bis 24 Stunden tolerierbar ist, sollte jedoch niemals der einzige Mechanismus für hochriskante Gerätekategorien sein.

Übungsfragen

Q1. Ihre Organisation migriert von PEAP-MSCHAPv2 (Benutzername und Passwort) zu EAP-TLS für das Unternehmens-WiFi. Das Netzwerk-Team schlägt vor, die bestehende Active Directory Certificate Services (AD CS)-Infrastruktur zu nutzen, um Zertifikate sowohl für die RADIUS-Server als auch für alle Unternehmens-Laptops auszustellen. Ein Teammitglied weist darauf hin, dass die Organisation auch 50 Laptops von externen Dienstleistern im Einsatz hat, die nicht domänengebunden sind. Was ist das primäre Kompatibilitätsrisiko und wie sollte es gelöst werden?

Hinweis: Überlegen Sie, wie nicht-domänengebundene Geräte die Identität des RADIUS-Servers validieren, wenn dieser ein Zertifikat vorlegt, das von Ihrer Private AD CS Root CA signiert wurde.

Musterlösung anzeigen

Das primäre Risiko besteht darin, dass die 50 nicht-domänengebundenen Laptops der externen Partner die private AD CS Root CA nicht in ihrem vertrauenswürdigen Zertifikatsspeicher haben. Wenn der RADIUS-Server während des EAP-TLS-Handshakes sein Server-Zertifikat vorlegt, erhalten diese Geräte die Fehlermeldung "Nicht vertrauenswürdiges Zertifikat" und die Verbindung schlägt fehl. Die empfohlene Lösung besteht darin, das RADIUS-Server-Zertifikat von einer Public CA (wie DigiCert oder Sectigo) anstelle der privaten AD CS zu beziehen. Public CA-Roots sind in den Vertrauensspeichern aller gängigen Betriebssysteme vorinstalliert, was die Kompatibilität sowohl mit domänengebundenen als auch mit nicht-domänengebundenen Geräten gewährleistet. Die private AD CS sollte ausschließlich für die Ausstellung von Client-Zertifikaten an verwaltete, domänengebundene Geräte beibehalten werden.

Q2. Bei einem Compliance-Audit für ein großes NHS-Krankenhaus stellt der Auditor fest, dass die Root CA als virtuelle Maschine im primären Rechenzentrum läuft und permanent mit dem internen Netzwerk des Krankenhauses verbunden ist. Der Auditor stuFt dies als kritischen Befund ein. Welche architektonische Änderung muss implementiert werden und warum stellt die aktuelle Konfiguration ein erhebliches Risiko dar?

Hinweis: Überlegen Sie, was mit jedem Zertifikat in der Organisation passieren würde, wenn der private Schlüssel der Root CA durch einen Ransomware-Angriff oder eine Insider-Bedrohung kompromittiert würde.

Musterlösung anzeigen

Die Root CA muss unverzüglich offline genommen und physisch vom Netzwerk getrennt (air-gapped) werden. Die aktuelle Konfiguration stellt ein kritisches Risiko dar, da der private Schlüssel der Root CA netzwerkbasierten Angriffen ausgesetzt ist, einschließlich Ransomware, Lateral Movement über ein kompromittiertes Domänenkonto oder Insider-Bedrohungen. Wenn der private Schlüssel der Root CA gestohlen oder zum Signieren bösartiger Zertifikate verwendet wird, ist die gesamte PKI-Infrastruktur – und damit jedes über Zertifikate authentifizierte System im Krankenhaus – kompromittiert. Eine Wiederherstellung würde den Widerruf der Root CA und die Neuausstellung jedes einzelnen Zertifikats in der Organisation erfordern, was ein katastrophales betriebliches Ereignis darstellt. Die korrekte Architektur erfordert, dass die Root CA nur dann eingeschaltet wird, wenn ein Intermediate-CA-Zertifikat signiert oder widerrufen wird, während die gesamte tägliche Ausstellung über eine Online-Intermediate-CA abgewickelt wird. Der private Schlüssel der Root CA sollte in einem Hardware-Sicherheitsmodul (HSM) gespeichert werden.

Q3. Ein großer Betreiber von Konferenzzentren möchte eine zertifikatsbasierte Authentifizierung sowohl für seine fest angestellten IT-Mitarbeiter als auch für die Tausenden von Ausstellern und Besuchern von Veranstaltungen einführen. Er bittet Sie, eine einzige PKI-Infrastruktur für beide Gruppen zu entwerfen. Was ist Ihre Empfehlung und warum?

Hinweis: Berücksichtigen Sie die betriebliche Machbarkeit der Verteilung von Zertifikaten an Tausende von nicht verwalteten, temporären Besuchern, die eine Veranstaltung eventuell nur für einen einzigen Tag besuchen.

Musterlösung anzeigen

Es ist dringend davon abzuraten, PKI und EAP-TLS für öffentliche Besucher und Aussteller zu verwenden. Die zertifikatsbasierte Authentifizierung erfordert die Installation eines Client-Zertifikats und oft eines Root-CA-Profils auf dem Endgerät, was bei nicht verwalteten, temporären Geräten betrieblich unmöglich ist und zu einer äußerst schlechten User Experience führt. EAP-TLS sollte strikt für feste IT-Mitarbeiter auf verwalteten Unternehmensgeräten reserviert sein, die im MDM-System der Organisation registriert sind. Für Aussteller und Besucher sollte eine Captive Portal-Lösung auf einer völlig separaten, isolierten SSID bereitgestellt werden. Diese Zwei-Netzwerk-Architektur – sicheres EAP-TLS für Mitarbeiter, Captive Portal für Gäste – ist der Industriestandard für Veranstaltungsorte und das von der Purple-Plattform unterstützte Modell.

Q4. Ein IT-Manager einer Einzelhandelskette hat EAP-TLS erfolgreich in allen 150 Stores implementiert. Sechs Monate später akzeptiert der RADIUS-Server in 12 Stores gleichzeitig keine Client-Verbindungen mehr. Eine Überprüfung zeigt, dass keine Zertifikatswiderrufe stattgefunden haben. Was ist die wahrscheinlichste Ursache und welches Prozessversagen hat dies ermöglicht?

Hinweis: Überlegen Sie, was alle 12 betroffenen Stores aus Zertifikatsperspektive gemeinsam haben könnten und welches Ereignis zu gleichzeitigen Ausfällen führen könnte.

Musterlösung anzeigen

Die wahrscheinlichste Ursache ist, dass das Intermediate-CA-Zertifikat – oder das RADIUS-Server-Zertifikat – abgelaufen ist. Wenn alle 12 Stores mit derselben Intermediate CA oder derselben Charge von RADIUS-Server-Zertifikaten konfiguriert wurden, die zur gleichen Zeit ausgestellt wurden, würden sie alle gleichzeitig ablaufen. Dies ist ein Fehler im Lifecycle-Management: Die Organisation hat keine automatisierte Überwachung des Zertifikatsablaufs und entsprechende Alarmierungen implementiert. Die Lösung erfordert die Erneuerung der abgelaufenen Zertifikate und die sofortige Implementierung einer automatisierten Überwachung mit Alarmen 90, 60 und 30 Tage vor dem Ablaufdatum für alle Zertifikate in der Hierarchie, einschließlich der Intermediate CA, des RADIUS-Server-Zertifikats und der Root CA.

Weiterlesen in dieser Reihe

So konfigurieren Sie SCEP für die automatisierte Zertifikatsregistrierung für Enterprise WiFi

Dieser Leitfaden erklärt, wie Sie SCEP (Simple Certificate Enrollment Protocol) für die automatisierte Zertifikatsregistrierung für Enterprise WiFi konfigurieren. Er deckt die gesamte Architektur von PKI und NDES bis hin zur MDM-Profilbereitstellung und RADIUS-Validierung ab. Er richtet sich an IT-Manager, Netzwerkarchitekten und CTOs in Hotels, Einzelhandelsketten, Stadien, Konferenzzentren und Organisationen des öffentlichen Sektors, die über Pre-Shared Keys hinausgehen und eine skalierbare, identitätsbasierte 802.1X EAP-TLS-Authentifizierung implementieren müssen. Die hardwareunabhängige Cloud-Overlay-Plattform von Purple lässt sich direkt in diese Architektur integrieren und bietet die Guest- und BYOD-WiFi-Ebene, die parallel zu Ihrem zertifikatsauthentifizierten Mitarbeiternetzwerk läuft.

The Enterprise Guide to SCEP: Deploying Simple Certificate Enrollment Protocol for Automated Campus WiFi Security

Dieser technische Leitfaden bietet einen definitiven Architektur-Entwurf und eine schrittweise Implementierungsstrategie für die Bereitstellung von WiFi-Zertifikaten in Unternehmen mittels SCEP. Er behandelt die entscheidenden Unterschiede zwischen SCEP und PKCS, die für den Erfolg erforderliche genaue Bereitstellungsreihenfolge sowie praxiserprobte Strategien zur Risikominderung für IT-Verantwortliche.

So implementieren Sie SCEP für die automatisierte WiFi-Zertifikatsregistrierung

Dieser Leitfaden erklärt, wie Sie SCEP (Simple Certificate Enrollment Protocol) für die automatisierte WiFi-Zertifikatsregistrierung in Unternehmensstandorten implementieren. Er deckt den gesamten architektonischen Entwurf ab – vom PKI-Design und der MDM-Integration bis hin zur obligatorischen dreistufigen Bereitstellungssequenz – und zeigt IT-Managern und Netzwerkarchitekten, wie sie gemeinsame Anmeldeinformationen eliminieren, das Lebenszyklusmanagement von Zertifikaten automatisieren und PCI DSS- und GDPR-Anforderungen in großem Maßstab erfüllen.