Sperrlisten-Zertifikat: Ein praktischer WiFi-Leitfaden

Ein Firmen-Laptop wird im Zug gestohlen. Der Helpdesk deaktiviert das Active Directory-Konto des Mitarbeiters, das Gerät verschwindet aus dem Anlagenregister, und alle gehen davon aus, dass das Risiko beseitigt wurde. Zwei Tage später taucht der Laptop immer noch auf der Unternehmens-SSID auf, weil sein 802.1X-Supplicant ein Client-Zertifikat besitzt, das noch nicht abgelaufen ist und das niemand gesperrt hat.

Genau diese Lücke soll ein Prozess mit einer Zertifikatssperrliste schließen. Der Ablauf eines Zertifikats setzt die äußere Grenze des Vertrauens, während der Widerruf das Vertrauen vorzeitig beendet, wenn ein Schlüssel kompromittiert wird, ein Gerät verloren geht oder ein Benutzer das Unternehmen verlässt. Für einen Enterprise-WiFi-Administrator ist die entscheidende Frage nicht, ob Zertifikate existieren. Es geht darum, ob RADIUS und die zugehörigen Netzwerkkontrollen schnell von einem gesperrten Zertifikat erfahren und ausfallsicher reagieren.

Der WiFi Zugriff, der nicht verschwinden wollte

Eine zertifikatsbasierte WiFi Bereitstellung sieht von außen oft sicher aus. Der Client verwendet EAP-TLS, der RADIUS-Dienst validiert die Zertifikatskette und es werden keine gemeinsam genutzten Passwörter unter den Mitarbeitern weitergegeben. Dieses Design hängt jedoch immer noch von einem funktionierenden Lebenszyklus ab. Die Ausstellung eines Zertifikats ist nur der Anfang. Sie müssen auch wissen, wer es besitzt, wann es abläuft und was passiert, wenn das Gerät oder der private Schlüssel nicht mehr vertrauenswürdig ist.

Im Beispiel mit dem gestohlenen Laptop stoppt das Entfernen des Kontos aus dem Active Directory zwar möglicherweise künftige Verzeichnis-Authentifizierungen, macht aber ein bereits auf dem Gerät installiertes Zertifikat nicht zwingend ungültig. Wenn der WiFi-Dienst dem Zertifikat allein aufgrund seiner Kette und seiner Gültigkeitsdaten vertraut, kann der Laptop weiterhin anscheinend gültige Anmeldedaten präsentieren. Das notAfter-Datum des Zertifikats besagt, dass es sich noch innerhalb seiner geplanten Lebensdauer befindet. Es besagt nicht, dass die ausstellende Organisation ihm immer noch vertrauen möchte.

Praktische Regel: Behandeln Sie den Ablauf von Zertifikaten und den Widerruf von Zertifikaten als getrennte Kontrollmechanismen. Der Ablauf ist ein geplantes Lifecycle-Management. Der Widerruf ist die Notbremse.

Das PKI-Modell des britischen öffentlichen Sektors macht diesen Unterschied deutlich. Eine Certificate Revocation List (Zertifikatswiderrufsliste) oder CRL ist eine signierte Liste von Seriennummern von Zertifikaten, die vor dem Ablaufdatum widerrufen wurden. Sie teilt den vertrauenden Parteien mit, dass diesen Zertifikaten nicht mehr vertraut werden sollte. Die Richtlinien der Public-Key-Infrastruktur im Vereinigten Königreich weisen CRLs ebenfalls als eine der gängigen Widerrufsmethoden aus und erwarten von Clients, dass sie prüfen, ob ein vorgelegtes Zertifikat auf der Liste der ausstellenden Zertifizierungsstelle steht.

Dies ist im WiFi wichtig, da Authentifizierungsentscheidungen am Netzwerkrand getroffen werden, oft über viele Controller, Access Points, RADIUS-Server und zwischengespeicherte Validierungsspeicher hinweg. Eine manuelle CRL-Aktualisierung kann eine Sicherheitslücke hinterlassen, während eine schlecht konzipierte Fail-Closed-Richtlinie zu einem Ausfall führen kann, wenn der CRL-Verteilungspunkt nicht verfügbar ist.

Das mentale Modell ist denkbar einfach: Die CA stellt Statusinformationen aus und signiert sie, die verifizierende Partei prüft diese, und das Netzwerk verweigert einem widerrufenen Zertifikat den Zugriff. Der Rest dieses Leitfadens befasst sich mit der Funktionsweise dieses Prozesses, den Unterschieden zwischen CRL und OCSP und der Frage, wie verzeichnisgestützte Zugriffskontrollen den Engpass bei der manuellen Sperrung weitgehend beseitigen können.

Was ein Sperrlistenzertifikat tatsächlich ist

Einfach ausgedrückt ist eine Certificate Revocation List eine offizielle Mitteilung einer Zertifizierungsstelle mit dem Inhalt „Diesen Zertifikaten nicht mehr vertrauen“. Sie identifiziert Zertifikate anhand ihrer Seriennummern, nicht anhand eines benutzerfreundlichen Gerätenamens oder der E-Mail-Adresse eines Mitarbeiters. Ein Client, der die Seriennummer des vorgelegten Zertifikats auf der entsprechenden Liste findet, muss dieses ablehnen, selbst wenn das Ablaufdatum des Zertifikats noch in der Zukunft liegt.

Die Definition im Vereinigten Königreich ist formal. Sie beschreibt eine CRL als eine signierte Liste von Zertifikatsseriennummern, die vor dem Ablaufdatum gesperrt wurden, sodass vertrauende Parteien diesen Zertifikaten nicht mehr vertrauen sollten. Die Signatur ist wichtig, da ein RADIUS-Server oder eine andere Validierungsstelle bestätigen muss, dass die Liste vom erwarteten Aussteller stammt und während der Übertragung nicht verändert wurde. Eine von einem Administrator gepflegte Blacklist in reinem Textformat bietet diese kryptografische Sicherheit nicht.

Drei Parteien machen den Prozess nützlich:

• Die Zertifizierungsstelle: Die CA oder ein autorisierter CRL-Aussteller erstellt die Liste und signiert sie mit einem privaten Schlüssel, der mit der ausstellenden Vertrauenshierarchie verknüpft ist.
• Die vertrauende Partei: Ein RADIUS-Server, Supplicant, Controller, Betriebssystem oder ein Verwaltungstool lädt die Liste herunter, validiert deren Signatur sowie Gültigkeitsinformationen und sucht anschließend nach der Seriennummer des Zertifikats.
• Der Zertifikatsinhaber: Die Person, das Gerät oder der Dienst, dessen Zertifikat gesperrt wurde. Seine Seriennummer verbleibt auf der Liste, damit Validierungsstellen es als nicht vertrauenswürdig identifizieren können.

Eine CRL ist normalerweise kein Zertifikat im gleichen Sinne wie ein Benutzer- oder Gerätezerifikat. Es handelt sich um ein signiertes PKI-Artefakt, das Aussteller-, Gültigkeits- und Veröffentlichungsinformationen enthält. Manchmal wird der Begriff „Sperrlistenzertifikat“ als Abkürzung für den Zertifikatswiderrufsmechanismus verwendet, aber das operativ geprüfte Objekt ist die signierte CRL.

Die vertrauende Partei fordert die CA in der Regel nicht auf, zu erklären, warum einem Benutzer der Zugriff verweigert werden sollte. Sie folgt den Sperrinformationen des Zertifikats, ruft die aktuelle CRL des Ausstellers ab, verifiziert die CRL und prüft die Seriennummer. Wenn eine Übereinstimmung vorliegt, ist das Zertifikat gesperrt. Wenn nicht, ist das Ergebnis immer noch durch die Aktualität der CRL und den eigenen Cache der vertrauenden Partei begrenzt.

Dieser letzte Punkt ist die Ursache für viele Vorfälle. Ein Zertifikat fehlt möglicherweise in einer alten, im Cache gespeicherten Liste und ist in einer neueren vorhanden. Die Entscheidung des Netzwerks hängt daher sowohl davon ab, was die CA veröffentlicht hat, als auch davon, wann der Authentifikator es zuletzt abgerufen hat.

Wie eine CRL hinter den Kulissen funktioniert

Ein CRL-Lebenszyklus folgt einer vorhersehbaren Kette von Ereignissen. Zuerst erstellt die CA eine Basisliste gemäß ihrer Zertifikatsrichtlinie. Sie signiert die Liste, fügt Veröffentlichungs- und Gültigkeitsfelder hinzu und stellt sie über einen Verteilungspunkt zur Verfügung. Ausgestellte Zertifikate verweisen üblicherweise über die Erweiterung "CRL Distribution Points" auf diese Speicherorte, sodass eine Validierungsstelle erkennen kann, woher die Statusinformationen stammen.

Wenn ein Administrator ein Gerätezertifikat sperrt, protokolliert die CA dessen Seriennummer und den Grund für die Sperrung. Das Zertifikat wird nicht unbedingt sofort im Cache jeder vertrauenden Partei angezeigt. Die nächste veröffentlichte CRL muss den Eintrag enthalten, und jeder RADIUS-Server oder Controller muss eine aktuelle Kopie abrufen, bevor er die richtige Entscheidung treffen kann.

Einige PKI-Umgebungen verwenden auch Delta-CRLs. Eine Delta-CRL enthält die Änderungen seit einer Basis-CRL, was den Übertragungs- und Verarbeitungsaufwand verringern kann, wenn die vollständige Liste groß ist. Diese Effizienz enthebt Sie jedoch nicht der Notwendigkeit, die Basisliste zu verwalten, Signaturen zu validieren, die Aktualität zu verfolgen oder sicherzustellen, dass jede Netzwerkkomponente das gewählte Veröffentlichungsmodell versteht.

Das Aktualitätsfenster

Die Richtlinien im Vereinigten Königreich bieten nützliche Anhaltspunkte für die Ausbreitung. Die CVCA-Praxiserklärung der britischen Regierung verlangt, dass CRLs höchstens alle 90 Tage ausgestellt werden und dass ein widerrufenes Zertifikat innerhalb von 72 Stunden nach dem Widerruf in der entsprechenden CRL erscheint. Diese Grenzwerte sind in der UK national certificate policy beschrieben.

Andere Richtlinien im Vereinigten Königreich nutzen unterschiedliche Service-Erwartungen. Das HM Land Registry legt fest, dass seine Sperrliste für gesperrte und suspendierte Zertifikate mindestens einmal pro Tag aktualisiert werden muss, während die Zertifizierungsrichtlinie der University of York eine maximale Latenz von 10 Tagen zwischen Sperrung und CRL-Ausstellung vorsieht. Diese Beispiele, einschließlich der HMPO Country Signing Certificate Authority Veröffentlichungsstelle, zeigen, warum ein Administrator die tatsächliche Richtlinie der ausstellenden CA lesen muss, anstatt davon auszugehen, dass sich jede CRL identisch verhält.

Zum Zeitpunkt der Authentifizierung prüft der RADIUS-Server die Seriennummer des Zertifikats anhand seiner lokal verfügbaren CRL. Er prüft außerdem, ob die CRL innerhalb ihrer Gültigkeitsdauer liegt, ob die Signaturkette zum erwarteten Aussteller führt und ob der Verteilungspunkt erreichbar ist, wenn eine Aktualisierung ansteht. Der Server speichert das Ergebnis dann entsprechend seiner Implementierung und dem Wert nextUpdate der CRL im Cache.

Dies ergibt eine praktische Risikogleichung ohne komplizierte Mathematik: Die Sperrlatenz umfasst die CA-Veröffentlichungszeit, die Verteilungsverzögerung, die Cache-Dauer und die Authentifizierungshäufigkeit. Eine Richtlinie kann schnell veröffentlichen, aber ein getrennter oder veralteter RADIUS-Cache kann die Durchsetzung dennoch verzögern.

CRL vs. OCSP und warum es für WiFi wichtig ist

CRL und OCSP lösen dasselbe grundlegende Problem auf unterschiedliche Weise. Eine CRL stellt dem Validator eine signierte Liste widerrufener Seriennummern zur Verfügung. OCSP fragt bei einem autorisierten Responder den Status eines einzelnen Zertifikats genau zum Zeitpunkt der Überprüfung ab.

Für einen Enterprise WiFi Administrator wirkt sich die Entscheidung auf mehr als nur die PKI-Eleganz aus. Sie verändert das Verhalten eines Controllers in einem überlasteten WAN, die Anforderungen an die CA-Infrastruktur und die Frage, ob ein Authentifizierungsversuch abgeschlossen werden kann, wenn ein Responder oder Verteilungspunkt nicht erreichbar ist.

Kriterium	CRL	OCSP
Aktualität	Periodisch. Ein neu gesperrtes Zertifikat wartet auf die Veröffentlichung und die Aktualisierung durch den Client.	Eine Abfrage pro Zertifikat kann einen aktuelleren Status liefern, sofern der Responder erreichbar ist.
Infrastrukturlast	Clients laden eine Liste herunter und verarbeiten diese. Dies kann bei wiederholten Prüfungen in einer verwalteten Umgebung effizient sein, kann jedoch Verteilungstraffic verursachen.	Der Responder verarbeitet einzelne Statusanfragen. Dies vermeidet den Download der vollständigen Liste, erhöht jedoch das Anfragevolumen.
Datenschutz	Die vertrauende Partei erhält eine Liste und muss der CA nicht jede einzelne Zertifikatsprüfung offenlegen.	Eine direkte Abfrage kann dem Responder offenlegen, welches Zertifikat gerade überprüft wird.
Ausfallverhalten	Eine unerreichbare oder abgelaufene CRL kann eine zuverlässige Statusprüfung verhindern. Lokale Caches funktionieren möglicherweise bis zu ihrer Aktualitätsgrenze weiter.	Ein unerreichbarer Responder beeinträchtigt die einzelne Statusabfrage. Das konfigurierte Soft-Fail- oder Hard-Fail-Verhalten bestimmt das Ergebnis für das WiFi.

Ein Controller, der einen großen Campus versorgt, bevorzugt möglicherweise eine lokal zwischengespeicherte CRL, da er viele Zertifikatsseriennummern prüfen kann, ohne für jede Authentifizierung eine separate Anfrage zu senden. Dieses Modell funktioniert gut, wenn die Verteilungspunkte erreichbar sind, Aktualisierungen überwacht werden und die RADIUS-Richtlinie eine abgelaufene Liste bewusst handhabt.

OCSP kann sich für ein Design eignen, bei dem der Betreiber eine Antwort pro Zertifikat benötigt und die Abhängigkeit von einem Responder akzeptiert. Es kann die Notwendigkeit verringern, eine vollständige Liste zu übertragen, führt jedoch während der Authentifizierung eine Live-Netzwerkabhängigkeit ein. Stapling kann die Responder-Interaktion bei einigen Protokollen an eine andere Stelle verlagern, dennoch benötigt das WiFi-Design immer noch eine klare Lösung für nicht verfügbare oder veraltete Statusdaten.

Die Richtlinien aus Großbritannien sind hier hilfreich, da sie CRL nicht als einzige Methode darstellen. Die britische Politik beschreibt CRLs als einen der gängigen Sperrmechanismen, während Richtlinien im Justizsektor sie als primären Offline-Mechanismus behandeln und die Verfügbarkeitsanforderungen für Sperrdienste in der PKI-Offenlegungserklärung hervorheben.

Für verwaltete 802.1X-Geräte ist CRL in der Regel praktisch für die regelmäßige Batch-Validierung, insbesondere wenn die Flotte über eine zuverlässige interne Verteilung verfügt. OCSP ist vorzuziehen, wenn eine höhere Aktualität des Status unerlässlich ist und die Verfügbarkeit des Responders entsprechend ausgelegt ist. Hochsicherheitsnetzwerke nutzen möglicherweise beide Verfahren, jedoch nur, wenn das Fallback-Verhalten dokumentiert und getestet ist, anstatt es einfach vorauszusetzen.

Sperrung in der Praxis in einem Purple WiFi Netzwerk

Der betriebliche Unterschied zeigt sich, wenn der WiFi-Zugriff an ein Live-Identitätsverzeichnis statt an eine manuell gepflegte Zertifikatsliste gebunden ist. Eine Verzeichnisintegration kann den aktuellen Kontostatus des Benutzers zum Teil der Authentifizierungsentscheidung machen. So wird das Deaktivieren eines Kontos zu einem Ereignis der Zugriffssteuerung und nicht zu einem Ticket, das später manuell in eine CA-Sperrung übersetzt werden muss.

Ein typischer Ablauf sieht wie folgt aus:

1. Das Verzeichnis erfasst den Identitätsstatus. Ein Konto wird in Active Directory, Microsoft Entra ID oder Google Workspace erstellt, geändert, gesperrt oder deaktiviert.
2. Der WiFi Identitätsdienst empfängt die Änderung. Der Dienst ordnet den Verzeichnisstatus der Authentifizierungsrichtlinie für das Unternehmen zu.
3. Die nächste Authentifizierung wird anhand dieses Status bewertet. Eine deaktivierte Identität erfüllt die Zugriffsregel nicht mehr, selbst wenn sich ein zuvor ausgestelltes Zertifikat noch innerhalb seiner Gültigkeitsdauer befindet.
4. Das Netzwerk verweigert den Zugriff. Die RADIUS-Entscheidung verhindert, dass eine neue 802.1X-Sitzung unter der inaktiven Identität autorisiert wird.

Dieses Modell behebt eine Schwachstelle des reinen CRL-Betriebs. Eine CRL hängt von der CA-Veröffentlichung, den Verteilungspunkten, Cache-Aktualisierungen und Prüfungen der vertrauenden Partei ab. Die verzeichnisgestützte Durchsetzung macht das Identitätssystem zur betrieblichen Single Source of Truth für den Kontostatus. Dadurch müssen Administratoren nicht mehr jede mit einem ausscheidenden Benutzer verknüpfte Zertifikatsseriennummer manuell heraussuchen.

Betrieblicher Unterschied: Eine CRL beantwortet die Frage, ob ein Zertifikat widerrufen wurde. Die verzeichnisbasierte Authentifizierung kann beantworten, ob die Identität aktuell zur Nutzung des Netzwerks berechtigt ist.

Purple bietet verwaltete RADIUS- und zertifikatsbasierte Enterprise-WiFi-Steuerungen mit Verzeichnisintegrationen wie Microsoft Entra ID und Google Workspace. Das RADIUS-as-a-Service-Angebot ist dort relevant, wo ein Unternehmen den Identitätsstatus mit der 802.1X-Authentifizierung verknüpfen möchte, ohne jede lokale RADIUS- und Sperrkomponente selbst warten zu müssen.

Dies führt nicht dazu, dass die Arbeit am PKI-Lebenszyklus verschwindet. Zertifikate erfordern weiterhin Ausstellung, Erneuerung, Trust-Chain-Management und Sperrprüfungen, wo die Architektur dies verlangt. Es beseitigt jedoch einen manuellen Engpass im Offboarding-Prozess. Der Service Desk kann die Identität über den etablierten Directory-Workflow deaktivieren, während die Netzwerk-Authentifizierungsschicht diesen Status bei der nächsten Zugriffsentscheidung anwendet.

Best Practices für den Betrieb von Enterprise WiFi

Ein zuverlässiges Widerrufsdesign kombiniert kryptografische Kontrollen mit gewöhnlicher betrieblicher Disziplin. Beginnen Sie mit der Lebensdauer des Zertifikats. Für verwaltete WiFi-Geräte ist eine Zertifikatslebensdauer von 12 bis 24 Monaten eine gängige betriebliche Referenz in den bereitgestellten Bereitstellungsrichtlinien, aber die richtige Wahl hängt vom Gerätebesitz, der Erneuerungsfähigkeit und dem Schaden ab, den ein offengelegter privater Schlüssel verursachen könnte. Zertifikate für Gast-Sponsoren sollten im Allgemeinen eine kürzere Lebensdauer haben, da sich ihr Zugriffskontext häufiger ändert.

Bauen Sie die Erneuerung in den Lebenszyklus der Geräte ein

Verwenden Sie SCEP, eine MDM-Plattform oder einen anderen automatisierten Registrierungspfad, um Zertifikate zu verlängern, bevor sie ablaufen. Eine manuelle Verlängerung funktioniert während einer Testphase, wird jedoch in einer verteilten Infrastruktur fehleranfällig. Testen Sie die Verlängerung auf Laptops im Energiesparmodus, Remote-Geräten, neu aufgesetzten Geräten und Geräten, die sich in letzter Zeit nicht mit dem Unternehmensnetzwerk verbunden haben.

Überwachen Sie die CRL-Verteilungspunkte von denselben Netzwerkpfaden aus, die von RADIUS und Controllern verwendet werden. Prüfen Sie Erreichbarkeit, Signaturgültigkeit, Ausstelleridentität und nextUpdate, nicht nur, ob eine Webanfrage Inhalte zurückgibt. Eine erreichbare, aber abgelaufene CRL ist dennoch eine fehlgeschlagene Sperrkontrolle.

Halten Sie die RADIUS-Seite sauber

Zertifikate für RADIUS-Server benötigen eine aktuelle Gültigkeit, eine vertrauenswürdige Ausstellungskette und einen Erneuerungsprozess, der nicht von einem Wartungsfenster in letzter Minute abhängt. Überprüfen Sie die Vertrauensspeicher auf Servern, Controllern und verwalteten Clients, damit ein altes CA-Zertifikat nicht zu inkonsistenten Entscheidungen an verschiedenen Standorten führt.

Dokumentieren Sie das Runbook für den Widerruf in einer Sprache, die ein Bereitschaftstechniker leicht nachvollziehen kann:

• Anmeldedaten identifizieren: Erfassen Sie Benutzer, Gerät, Zertifikatsseriennummer und ausstellende CA.
• Identität deaktivieren: Führen Sie die genehmigte Offboarding-Aktion im Verzeichnis oder der HR-Abteilung durch.
• Bei Bedarf sperren: Aktualisieren Sie den CA-Status und bestätigen Sie die Veröffentlichung.
• Vertrauende Parteien aktualisieren: Erzwingen oder planen Sie den CRL-Abruf, sofern dies unterstützt wird.
• Verweigerung testen: Versuchen Sie eine Authentifizierung mit den betroffenen Anmeldedaten und protokollieren Sie das Ergebnis.

Stimmen Sie HR-Trigger mit Verzeichnisänderungen ab. Wenn der Service Desk auf ein separates PKI-Ticket warten muss, vertraut das Netzwerk möglicherweise weiterhin einer Identität, die das Unternehmen bereits als inaktiv markiert hat. Automatische Bereitstellung und Verlängerung reduzieren diese Diskrepanz, während ein dokumentierter manueller Pfad für gestohlene Geräte und vermutete Kompromittierungen von Schlüsseln weiterhin wichtig bleibt.

Prüfen Sie für den passwortlosen Mitarbeiterzugang, wie sich diese Kontrollen in eine WPA-Enterprise Bereitstellung einfügen, einschließlich Zertifikatsregistrierung, RADIUS-Validierung und der Zuständigkeit für das Offboarding.

Fehlerbehebung bei häufigen Widerrufsproblemen

Die meisten CRL-Probleme lassen sich in drei Kategorien einteilen: Der Validator verfügt über veraltete Informationen, er kann den richtigen Veröffentlichungspunkt nicht finden oder der Widerrufsspeicher ist schwer zu betreiben. Diagnostizieren Sie den Entscheidungspfad, anstatt sofort mit der Neuausstellung von Zertifikaten zu beginnen.

Ein veralteter lokaler Cache

Ein RADIUS-Server oder Controller hält möglicherweise noch eine CRL vor, die vor dem Widerruf erstellt wurde. Überprüfen Sie die Felder thisUpdate und nextUpdate der CRL, validieren Sie deren Signatur anhand der ausstellenden CA und prüfen Sie die zwischengespeicherte Kopie auf dem Authentifikator. Vergleichen Sie die vom Client übermittelte Seriennummer mit den Einträgen in der neu veröffentlichten CRL.

Die sofortige Lösung besteht darin, eine CRL-Aktualisierung zu erzwingen, sofern die Plattform dies unterstützt, und anschließend einen Authentifizierungstest mit dem betroffenen Zertifikat zu wiederholen. Wenn der Cache weiterhin veraltete Daten zurückgibt, überprüfen Sie das Proxy-Verhalten, das Caching an den Verteilungspunkten und die Aktualisierungsrichtlinie des Validators.

Ein fehlender Verteilungspunkt

Lesen Sie die CDP- und AIA-Erweiterungen des ausgestellten Zertifikats. Der CDP teilt der vertrauenden Partei mit, wo sie Sperrinformationen findet, während die AIA helfen kann, die für die Kettenvalidierung erforderlichen Ausstellerinformationen zu identifizieren. Bestätigen Sie, dass die URL korrekt ist, aus dem RADIUS-Netzwerk erreichbar ist und eine vom erwarteten Aussteller signierte CRL bereitstellt.

Wenn die CA-Vorlage den falschen Speicherort enthält, korrigieren Sie die Vorlage und stellen Sie Ersatzzertifikate aus. Die bloße Aktualisierung des Endpunkts repariert keine Zertifikate, die bereits einen unbrauchbaren Verteilungspunkt enthalten.

Ein unhandlicher Sperrspeicher

Alte Einträge können die Verwaltung verkomplizieren und den Verarbeitungsaufwand erhöhen. Bereinigen Sie Einträge nur gemäß der Aufbewahrungsrichtlinie der CA und erst, nachdem die entsprechende Zertifikatslebensdauer und die Audit-Anforderungen berücksichtigt wurden. Entfernen Sie eine Seriennummer niemals nur deshalb, weil das Ticket für den Vorfall geschlossen ist.

Richtlinienbeispiele aus Großbritannien zeigen, warum „aktuell“ lokal definiert werden muss. Einige britische Behörden verlangen tägliche Aktualisierungen, während die nationale CVCA-Richtlinie eine Veröffentlichung innerhalb von 72 Stunden für ein gesperrtes Zertifikat vorschreibt und einen maximalen Ausstellungszeitraum von 90 Tagen festlegt. Betrachten Sie diese als Richtlinien-Baselines, nicht als Erlaubnis, veraltete Unternehmensdaten zu akzeptieren.

Ein Tool zur Zertifikatsanalyse kann bei der Überprüfung von Aussteller, Gültigkeit, CDP und Kettendetails helfen. Der SSL-Zertifikatsprüfer von Purple ist eine Option zur Überprüfung des Zertifikatsstatus, während eine verzeichnisgestützte Durchsetzung verhindern kann, dass man sich beim Offboarding von Benutzern ausschließlich auf eine verzögerte CRL-Aktualisierung verlässt.

In dieser Woche alles zusammenführen

Machen Sie den Widerruf zu einer zugewiesenen Aufgabe und nicht zu einem bloßen Richtlinienabschnitt. Planen Sie diese Maßnahmen für das nächste Änderungsfenster ein und weisen Sie jeder Aufgabe einen namentlich genannten Verantwortlichen zu.

• PKI-Team, prüfen Sie die Zertifikatspfade: Erfassen Sie jede WiFi-Client-Zertifikatsvorlage, die ausstellende CA, CDP und RADIUS-Vertrauensstellung. Stellen Sie sicher, dass jeder Verteilungspunkt von jedem Authentifizierungsstandort aus erreichbar ist.
• PKI- und Endgeräte-Teams, setzen Sie eine vertretbare Gültigkeitsdauer: Verkürzen Sie die Gültigkeit von WiFi-Client-Zertifikaten auf 12 Monate oder weniger, sofern der Erneuerungsprozess der Geräte dies unterstützt. Die kürzere Gültigkeitsdauer verringert die Abhängigkeit von Notfall-Sperrungen, allerdings nur, wenn die Erneuerung automatisiert und getestet ist.
• Endgeräte-Team, automatisieren Sie die Erneuerung: Nutzen Sie MDM oder SCEP, um Zertifikate ohne Benutzereingriff zu registrieren und zu erneuern. Testen Sie den Prozess nach einer Neuinstallation des Geräts, einer längeren Offline-Phase und einem Benutzerwechsel.
• Service-Desk- und Identity-Team, verknüpfen Sie das Offboarding mit der Zugriffssperre: Sorgen Sie dafür, dass der HR- oder Service-Desk-Status "Inaktiv" direkt in die Verzeichnissteuerung einfließt, die für die WiFi-Authentifizierung verwendet wird. Überprüfen Sie, ob eine deaktivierte Identität keine neue 802.1X-Sitzung aufbauen kann.
• Netzwerk-Team, überwachen Sie Sperrabhängigkeiten: Richten Sie Alarme für nicht verfügbare Verteilungspunkte, abgelaufene CRLs, ungültige Signaturen und fehlgeschlagene Statusprüfungen ein. Abonnieren Sie Benachrichtigungen über CA-Änderungen, damit eine geänderte Veröffentlichung nicht unbemerkt die Authentifizierung beeinträchtigt.

Messen Sie im folgenden Überprüfungszeitraum zwei Ergebnisse. Erfassen Sie erstens die Latenzzeit zwischen einem Deaktivierungsereignis im Verzeichnis und dem Beenden oder Verweigern einer neuen WiFi-Sitzung. Messen Sie zweitens, wie viele RADIUS-Authentifizierungen eine erfolgreiche CRL-Prüfung abgeschlossen haben, anstatt über einen Soft-Fail-Pfad fortzufahren. Diese Messungen zeigen Ihnen, ob das Design unter Druck funktioniert, und nicht nur, ob die Zertifikate in einer Tabellenkalkulation korrekt aussehen.

Wenn Ihr Team den manuellen PKI-Verwaltungsaufwand reduzieren und gleichzeitig identitätsbasiertes Enterprise-WiFi beibehalten möchte, kann Purple verwaltete Authentifizierung auf Zertifikatsebene, verzeichnisbasierte Zugriffsentscheidungen und RADIUS-Dienste bereitstellen, die Sperrprüfungen unterstützen. Besuchen Sie Purple, um zu prüfen, wie dieser Ansatz in Ihre Arbeitsabläufe für das WiFi-Offboarding und den Zertifikatslebenszyklus passt.